[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-AUCTeX] font locking in doctex-mode: textbf{x}^^A

From: Ralf Angeli
Subject: Re: [Bug-AUCTeX] font locking in doctex-mode: textbf{x}^^A
Date: Sun, 15 Apr 2007 15:28:04 +0200
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.96 (gnu/linux)

* Andreas Matthias (2007-04-13) writes:

> Font locking stumbles in doctex-mode if the closing brace of
> \textbf, \textit, etc. is directly followed by `^^A'.
> In the following example everything up to the closing brace
> of `Oops}' is mistaken for the argument of \textbf:
> %   \textbf{x}^^A
> %
> \oops% Oops}
> \hmm

That's a tough one.  Here is the analysis: During font locking the
function `font-latex-doctex-^^a' is called when "^^A" is matched.
This function terminates the %-style comment by putting a
`syntax-table' text property with the value ">" (comment end) onto the
character just before "^^A" which happens to be the closing brace in
the example.  Now, brace matching is done with `scan-sexps' and during
font locking `parse-sexp-lookup-properties' is set to t.  That means,
since the closing brace has a `syntax-table' property overruling it's
normal syntax it won't be found when `scan-sexps' is called.

I'm currently not sure how to deal with this since we cannot put two
'syntax-table' properties -- one for terminating the %-style comment
and one for opening the ^^A-style comment -- onto the same character.
My only idea at the moment would be to set
`parse-sexp-lookup-properties' to nil while
`font-latex-find-matching-close' is being executed.  Paren matching
in TeX buffers will likely not rely on `syntax-table' properties, so
it should have no negative side effects, but one never knows ...

Any other ideas?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]