Re: Fontification Problems with alltt

* Jan T. Kim (2005-03-07) writes:

> Ok -- I have compiled Emacs 22.0.50.1 from CVS. Thus far, I have not
> been able to trigger the bug again, but this may not mean much, as I
> don't know a reliable way to trigger it. Here are some potentially
> relevant observations, though. The fontification does get inversed
> (i.e. it's not just "bleeding out of the alltt environment",
> everything is brown outside and content inside alltt is multicoloured,
> depending on commands) if
>
>     *  the alltt environment is empty
>
>     * \begin{alltt} is followed by a backslash and a newline.
>
> Both these effects also occur with the 21.3 version, although sometimes
> very slowly (which is why I haven't noticed this pattern before -- the
> CVS version seems to be substantially faster) and are usually reversed
> upon adding stuff.

In the case the environment is empty, the fontification code places
syntax properties for marking the start and end of the verbatim
content onto the same point in the buffer and this confuses the rest
of the code.  In the case of a backslash at the end of the first line,
the escape syntax of the backslash overrides the syntax property
marking the start of the verbatim content.

These constellations usually are non-permanent, so it should not be a
problem if Emacs updates the display reliably.  Obviously Emacs 21
does not get this right fast/reliable enough.  I don't think we can do
much about it by changing something in AUCTeX.

> Now, assuming for the moment that upgrading to 22.0.50.1 fixes the
> problem: Does that mean that this upgrade is the only way to get
> AUCTeX working correctly? Can you give me any recommendations on how
> to work this? Any recommendations?

You can force an update of fontification with `M-x
font-lock-fontify-buffer RET'.  In case the wrong fontification
happens often to you, you can bind `font-lock-fontify-buffer' to a
keyboard shortcut.

-- 
Ralf