[Top][All Lists]

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

[AUCTeX-devel] Multiline font locking

From: Ralf Angeli
Subject: [AUCTeX-devel] Multiline font locking
Date: Fri, 09 Dec 2005 12:29:08 +0100
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

Now that's a mess.

What font-lock and we are doing right now is this: Find the start of a
multiline construct---let's use text in quotation marks as an
example---and search for its end by means of a function.  The search
is limited to the position given as the END argument of
`font-lock-fontify-region' and friends.  If we don't find a closing
quotation mark, we return a match from the opening quote to the limit.

That means after typing an opening quote, usually the rest of the
buffer gets colored until the closing quote is typed.  What I don't
like about this is that it forces me to type the closing quotation
mark as soon as possible after the opening one because I don't like
this excessive coloring.

As already mentioned in other messages about font locking problems, I
think it would be nice if coloring would only happen after the
construct is typed completely.  In our example this means after typing
the opening quotation mark nothing happens and only after inserting
the closing quote the whole string would be fontified.

That's nice in theory and works as long as we are not dealing with
long multiline constructs (or fontification by chunks does not fontify
a multiline construct from the start).

Multiline fontification as provided by font-lock currently works like
this: With jit-lock fontification is done in chunks.  When a chunk is
treated and an opening quote is found, search for a closing one till
the end of the chunk (as already explained above).  So far no problem.
If the chunk starts within a multiline construct, font-lock looks back
one character if it finds a `font-lock-multiline' text property.  If
it does it searches for the start of this multiline fontification and
sets the start of the region to fontify to this point.

This has several consequences:

If a multiline construct is fontified and it does not end before the
chunk ends, fontification has to be applied till the end of the chunk.
Otherwise font locking routines won't find the `font-lock-multiline'
text properties when looking back from the start of the following

If fontification starts within a multiline construct e.g. because one
jumped to a location with `goto-line', a preceding text property will
not be found if font-lock hasn't found the start of the construct yet.
The visible area or chunk will be fontified nevertheless.  Now if
fontification goes on (e.g. because of stealth font locking) it will
eventually find the start of the multiline construct but it will never
be fontified till its end because there is an area in the multiline
construct which already was fontified (there are `fontified' text
properties set to t).  With our example this can result in the start
of the quoted text being colored but the rest staying uncolored.

A third consequence is that there is excessive fontification in long
multiline constructs.  Suppose our quoted text extends several
hundreds of lines and starts right at the top of a file.  You open the
file and start scrolling downwards.  The first chung is being fontfied
from the start of the file till the end of the chunk.  You scroll a
page further.  font-lock now tries to fontify the next chunk.  Before
the start of the chunk it detects a multiline text property and
searches for the start of the construct.  It sets the beginning of the
region to be fontified to this start.  Now it has to fontify two
chunks.  The more you scroll down the more has to be fontified (over
and over again).  That means every time you scroll one page further
Emacs will have to work more and scrolling becomes painfully slow
after just a few pages.

I am not sure how realistic a scenario of a multiline construct with
several hundreds of lines is, but this might explain slow-downs if
erroneous opening quotes are detected.

I had two ideas how to improve the situation from inside font-latex.
One was to let the function which searches for the closing quote jump
to the end of the region with the multiline text properties just like
the font-lock function jumped to its start before.  Unfortunately
font-lock removes all text properties before it (re-)fontifies a
region, so the respective information is lost.  Another idea was to
pass the start of the unfontified region (that means the original
start of the chunk to be fontified) to respective functions so that
they can jump to that position directly but of course this would
require a change in font-lock.el.  And after all this would not fix
the problems with partly fontified but unrecognized multiline
constructs as described above.

Currently I believe that chunk-based fontification is incompatible
with multiline constructs.  Those will have to be fontified starting
from the top of a buffer.  This could probably be achieved by
disabling jit-lock but I am not sure what this would mean for the time
it takes to open a file and how this behaves during editing.  What,
for example, would happen if you had an opening quote at the start of
the buffer and inserted the closing one several hundred lines below?
Especially if we want to support fontification which is only applied
once a multiline construct is being closed.  Maybe the starting point
would have to be marked or cached in some way.

Interesting problems ... (c:


reply via email to

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