GNU bug report logs - #192
regexp does not work as documented

Previous Next

Package: emacs;

Reported by: Bruno Haible <bruno <at> clisp.org>

Date: Tue, 6 May 2008 03:35:03 UTC

Severity: normal

Tags: unreproducible

Done: Andrew Hyatt <ahyatt <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: David Koppelman <koppel <at> ece.lsu.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: martin rudalics <rudalics <at> gmx.at>, Chong Yidong <cyd <at> stupidchicken.com>,
        192 <at> debbugs.gnu.org, Bruno Haible <bruno <at> clisp.org>,
        emacs-devel <at> gnu.org
Subject: bug#192: regexp does not work as documented
Date: Mon, 12 May 2008 12:04:43 -0500
> a multiline region spanning 0..400.  Before fontifying, you need
> to unfontify.  The region 100..200 can be completely unfontified, but

Hadn't thought about that. I don't want things to get too elaborate but
it would be nice to have guaranteed behavior below some multi-line size
and not risk slow behavior.

One possibility is to retain the code as it is, except have
extend-region-multiline extend to some maximum size (say, 100 lines)
with the expectation that the larger region would be used for deferred
fontification (I guess jit-lock does that). The only difference with
current operation is that the font-lock-multiline property is ignored
both ensuring proper matches (when the property is not present but a
pattern would match) and avoiding huge sized regions.

Now, if we wanted really large multi-line matches we could unfontify the
larger region but use a window+margin sized region (accounting for all
buffers visiting the file) for the regular patterns and then mark the
other parts of the larger region as unfontified. This would force
re-applying the multi-line patterns on buffer motion, though
we could cache the match data to avoid re-seaching.




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

>> 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):
>
> I do not understand how you propose to solve the main problem:
> Let's say you want to fontify a line spanning chars 100..200 and
> a multiline region spanning 0..400.  Before fontifying, you need
> to unfontify.  The region 100..200 can be completely unfontified, but
> what about 0..99 and 201..400?  You can't unfontify them completely
> since you don't want to refontify them completely either, so you'd need
> to figure out which part of the fontification comes from the
> multiline keywords.
>
> Also, the order between keywords is important, so unless you force all
> multiline keywords to go at the very end, you'd also need to remove (on
> the 0..99 and 201..400 regions) the fontification coming from small
> keywords that were placed after multiline keywords and reapply
> it afterwards?
>
>
>         Stefan




This bug report was last modified 9 years and 147 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.