What are the downsides of changing the syntax class of quotes in text-mode and backslash in AUCTeX?

Question

It bothered me that sexp navigation commands didn't treat a quoted string as a single expression in text-mode. This is because the quote character " is in the punctuation syntax class in the text-mode syntax table. I decided to make it a string delimiter:

(modify-syntax-entry ?\" "\"" text-mode-syntax-table)

Similarly, I wanted sexp navigation commands in AUCTeX buffers to treat the initial backslash in a macro as part of the macro (as happens in the built-in latex-mode), so I changed the class of \ to expression prefix:

(modify-syntax-entry ?\\ "'" LaTeX-mode-syntax-table)

Now, I've been told that modifying syntax tables is "dangerous" and can have "far-reaching unintended consequences", but I've been using those for months and so far I haven't noticed any consequences other than improved sexp navigation.

So my question is: what can actually go wrong? A good answer would be a specific example of some text and some commands that have different outcomes with and without the syntax class change, where the outcome with the change is clearly inferior in some way. Is there any actual danger or is this just an abstract fear some people have?

Answer 1

I'm relatively inexperienced with writing and modifying major modes, but I've messed around a little. I can't give a definitive answer as to why this happened, but I had some unexpected behavior while working on a major mode for a language in which comments can be initiated with #n (case-insensitive) and, notably, must be terminated with a semicolon. If a semicolon is omitted the comment runs through subsequent lines with the comment ending only once a semicolon is found. To get the desired highlighting behavior, I modified the syntax table like this:

(modify-syntax-entry ?# ". 1" st) ; sets comments to start with:
(modify-syntax-entry ?n ". 2" st) ;   #n or
(modify-syntax-entry ?N ". 2" st) ;   #N
(modify-syntax-entry ?\; ">" st)  ; and run until terminated by a semicolon!

This turned out to have some weird and unexpected consequences when leveraging regular expressions for setting font lock keywords later. In particular, it seemed like the letter "n" was no longer matched by "\w". This, in turn, would cause "font-lock-variable-name-face" matches to begin mid-word on the letter "n", so this assignment:

#var strange 10;

would get highlighted as if the variable name was "nge" with "stra" getting the the default face:

The only way I could get things to work properly, while continuing to use modify-syntax-entry this way, was to avoid "\w" in regular expressions instead using "[a-zA-Z0-9_]" which still worked.

Again I'm no expert at lisp or major modes -- and I certainly might've been doing something really stupid with my font lock keywords -- but that's at least one scenario where messing with modify-syntax-entry was dangerous, leading to clearly worse behavior.