[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?
--
Ralf