* Shreevatsa R. (2007-02-25) writes:
> I looked at that thread, and as I understand it, the issue is:
>
> * latex-mode defines \( and \) (and the others) as escaped, so
> according to the syntax table of latex-mode, they are simply quoted
> characters and don't correspond to each other.
Yes.
> * scan_lists (used by show-paren-mode, forward-sexp, etc.) regards
> them as start/end of sexps despite the fact that they are escaped and
> ought to have no syntactic meaning.
>
> So it is a bug, in some sense, with scan_lists, that it is trying to
> match them, as you say.
Yes. But there is an additional bug in Show Paren mode because it
doesn't check if a character with paren syntax is escaped when it
starts the search for the matching one.
> But from the LaTeX point of view, I think \( and \) and \[ and \],
> aren't just escaped characters (maybe \{ and \} are). They have a role
> in the syntax and if they don't match, LaTeX will complain... so it
> useful and desirable to have sexp- and paren matching work on them. Is
> it possible to redefine them appropriately, or does "\" have to escape
> its next character universally or not at all?
A character has a certain syntax set in the syntax table throughout
the whole region where the syntax table is active. I don't know of
any mechanism to override that syntax according to the context of the
character. And I doubt it would be the right thing to do.
What might be a possibility would be to extend Show Paren mode in way
that it can work with regexps as well (similar to how font locking
works). That could be worth a feature request on emacs-devel. I'm
not sure if something like that would be feasible and sensible for
`scan_lists' or `forward-sexp' for that matter as well.
> This will not entirely solve the problem -- the bug with scan_lists
> will still cause show-paren-mode to crib on \{ and \} -- but I think
> it would be the right thing to do, if possible.
Personally I'd value a fix for the currently observable mismatch
problem higher.
--
Ralf
_______________________________________________
bug-auctex mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-auctex
