From: David Koppelman <koppel@ece.lsu.edu>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: martin rudalics <rudalics@gmx.at>,
Chong Yidong <cyd@stupidchicken.com>,
192@emacsbugs.donarmstrong.com, Bruno Haible <bruno@clisp.org>,
emacs-devel@gnu.org
Subject: Re: regexp does not work as documented
Date: Mon, 12 May 2008 10:03:52 -0500 [thread overview]
Message-ID: <yg5d4nra7jb.fsf@nested.ece.lsu.edu> (raw)
In-Reply-To: <jwvr6c8pbd6.fsf-monnier+emacsbugreports@gnu.org> (Stefan Monnier's message of "Sun, 11 May 2008 21:28:18 -0400")
> 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.
>
next prev parent reply other threads:[~2008-05-12 15:03 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-06 4:20 regexp does not work as documented Chong Yidong
2008-05-06 11:35 ` Bruno Haible
2008-05-06 12:12 ` martin rudalics
2008-05-10 19:18 ` bug#192: " David Koppelman
2008-05-10 19:18 ` David Koppelman
2008-05-10 20:13 ` David Koppelman
2008-05-11 7:40 ` bug#192: " martin rudalics
2008-05-11 7:40 ` martin rudalics
2008-05-11 14:27 ` Chong Yidong
2008-05-11 15:36 ` David Koppelman
2008-05-11 18:44 ` bug#192: " Stefan Monnier
2008-05-11 18:44 ` Stefan Monnier
2008-05-11 19:09 ` bug#192: " David Koppelman
2008-05-11 19:09 ` David Koppelman
2008-05-12 1:28 ` Stefan Monnier
2008-05-12 15:03 ` bug#192: " David Koppelman
2008-05-12 15:03 ` David Koppelman [this message]
2008-05-12 16:29 ` Stefan Monnier
2008-05-12 17:04 ` David Koppelman
2008-05-12 17:04 ` bug#192: " David Koppelman
2008-05-12 16:29 ` Stefan Monnier
2008-05-12 1:28 ` Stefan Monnier
2008-05-11 15:36 ` David Koppelman
2008-05-11 18:44 ` Stefan Monnier
2008-05-11 20:03 ` bug#192: " Thomas Lord
2008-05-11 20:03 ` Thomas Lord
2008-05-12 1:43 ` bug#192: " Stefan Monnier
2008-05-12 1:43 ` Stefan Monnier
2008-05-12 3:30 ` Thomas Lord
2008-05-12 13:43 ` bug#192: " Stefan Monnier
2008-05-12 13:43 ` Stefan Monnier
2008-05-12 15:55 ` bug#192: " Thomas Lord
2008-05-12 15:55 ` Thomas Lord
2008-05-12 16:18 ` tomas
2008-05-12 16:18 ` bug#192: " tomas
2008-05-12 3:30 ` Thomas Lord
2008-05-11 18:44 ` Stefan Monnier
2008-05-11 14:27 ` Chong Yidong
2008-05-10 20:13 ` David Koppelman
2008-05-06 15:35 ` Stefan Monnier
2008-05-06 21:29 ` Bruno Haible
2008-05-10 20:04 ` Bruno Haible
2008-05-10 20:04 ` bug#192: " Bruno Haible
2008-05-06 15:00 ` David Koppelman
2008-05-06 21:35 ` Bruno Haible
2008-05-07 1:04 ` Stefan Monnier
2008-05-07 1:08 ` Auto-discovery of multi-line font-lock regexps Stefan Monnier
2008-05-07 3:46 ` Chong Yidong
2008-05-07 4:21 ` Stefan Monnier
-- strict thread matches above, loose matches on Subject: below --
2008-05-06 1:30 regexp does not work as documented Bruno Haible
2008-05-06 14:15 ` Johan Bockgård
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yg5d4nra7jb.fsf@nested.ece.lsu.edu \
--to=koppel@ece.lsu.edu \
--cc=192@emacsbugs.donarmstrong.com \
--cc=bruno@clisp.org \
--cc=cyd@stupidchicken.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.