Re: [Bug-AUCTeX] 11.83; Paren matching in AUCTeX

[Ralf Angeli]

* 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