bug#192: regexp does not work as documented

[David Koppelman <koppel@ece.lsu.edu>]

> I guess I simply do not understand what you propose.  Any improvement in
> the multiline handling is welcome, but beware: this is not an easy area.

I'm proposing that font-lock divide keywords into two or three
classes, ordinary, multi-line, and maybe mega-line, matches for
multi-line and mega-line keywords would be over much larger
regions. Here is how it might work with two classes (keep in mind that
I don't yet have a thorough understanding of font-lock and jit-lock):

  Multi-line keywords are explicitly identified as such, perhaps
  through keyword syntax or the way they are given to font-lock (say,
  using font-lock-multiline-keywords). Explicit identification avoids
  performance problems from keywords that, though technically
  multi-line, rarely span more than a few lines.

  Functions such as font-lock-default-fontify-region would find two
  sets of extended regions, ordinary and multi, running functions on
  two hooks for this purpose. The multi-line hook might extend the
  region based on the size of the largest supported match rather than
  using the multline property. The multiline property might still be
  useful for non-deferred handling of existing matches.

  Functions such as font-lock-fontify-keywords-region would be passed
  both extended regions and use the region appropriate for each
  keyword they process. The large region is only used on the few
  multi-line patterns that need it.

Here I'm assuming that a mode might have hundreds of single-line (or
two-line) keywords and only a few multi-line keywords, and the
multi-line keywords might span no more than hundreds of lines. We
could guarantee that matches for such patterns are perfect (using a
line-count-limit variable).

If there were a third class, mega-line, it would have its own text
property and region-extension hook.


Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> A better solution would be to have font-lock use multi-line extended
>> regions selectively. Perhaps a hint in the current keyword syntax
>> (say, explicitly applying the font-lock-multiline property), or a
>> separate method for providing multi-line keywords to font-lock.
>
> I don't understand the difference between the above and the application
> of font-lock-multiline properties which you seem to have tried and rejected.
>
> I don't necessarily disagree with your rejection of font-lock-multiline:
> it can have disastrous effect indeed if the multiline region becomes large.
>
>> Such keywords would get the multi-line extended regions, the other
>> just the whole-line extensions (or whatever the hooks do).
>> Is this something the font-lock maintainers would consider?
>
> I guess I simply do not understand what you propose.  Any improvement in
> the multiline handling is welcome, but beware: this is not an easy area.
>