From: David Koppelman <koppel@ece.lsu.edu>
To: Chong Yidong <cyd@stupidchicken.com>
Cc: 192@emacsbugs.donarmstrong.com, Bruno Haible <bruno@clisp.org>,
emacs-devel@gnu.org
Subject: bug#192: regexp does not work as documented
Date: Sun, 11 May 2008 10:36:49 -0500 [thread overview]
Message-ID: <yg57ie0df8u.fsf__5440.493024844$1210528611$gmane$org@nested.ece.lsu.edu> (raw)
In-Reply-To: <87abiwoqzd.fsf@stupidchicken.com> (Chong Yidong's message of "Sun, 11 May 2008 10:27:50 -0400")
I agree pretty much with everything Chong Yidong writes.
I rather not bother the user with an additional question if I don't
have to, the alternative would be a warning.
My latest plan is to do what Chong Yidong suggests, setting up text
properties so that font-lock DTRT, though it doesn't seem as hard as he
suggests (I'm still in the naive enthusiasm stage). I tried adding the
font-lock-multiline property to the face property list passed to font
lock and that did the trick, even with the font-lock-multiline variable
nil. I rather do that than turn on font-lock-multiline because I'm
assuming that font-lock-multiline is set to nil in most cases for a good
reason.
Rather than perfectly distinguishing multi-line from single line
patterns guessing would be good enough for hi-lock. I'm using the
following regexp,
"\\(\n.\\|\\\\W[*+]\\|\\\\[SC].[*+]\\|\\[\\^[^]]+\\][+*]\\)", which
hopefully isn't too far from covering a large majority of interactively
entered patterns.
I actually thought about properly parsing the regexp, but the effort to
do that could be spent on making multi-line patterns work properly, at
least if they don't span too many lines.
One more thing, multi-line regexp matches don't work properly even with
font-lock-multiline t when jit-lock is being used in a buffer without
syntactic fontification and using the default setting of
jit-lock-contextually, setting it to t gets multi-line fontification to
work.
I plan to play around a bit more and come up with something,
maybe today, maybe early this week.
Chong Yidong <cyd@stupidchicken.com> writes:
> Ideally, highlight-regexp should work automagically, instead of forcing
> users to do something extra to make their multi-line regexp work
> properly. The right way to do this is probably for hi-lock-mode to
> process the buffer initially, setting up text properties to make
> font-lock DTRT even for multi-line expressions. But that's a big job.
>
> As for making hi-lock-mode detect whether or not a regexp is multi-line,
> isn't that a computationally non-trivial problem?
>
> Maybe making hi-lock-mode turn on font-lock-multiline, while not
> foolproof, works often enough to be satisfactory.
next prev parent reply other threads:[~2008-05-11 15:36 UTC|newest]
Thread overview: 50+ 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 ` David Koppelman
2008-05-10 20:13 ` bug#192: " David Koppelman
2008-05-10 20:13 ` David Koppelman
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 ` Stefan Monnier
2008-05-11 19:09 ` bug#192: " David Koppelman
2008-05-11 19:09 ` David Koppelman
2008-05-12 1:28 ` bug#192: " Stefan Monnier
2008-05-12 1:28 ` Stefan Monnier
2008-05-12 15:03 ` bug#192: " David Koppelman
2008-05-12 15:03 ` David Koppelman
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-11 18:44 ` Stefan Monnier
2008-05-11 15:36 ` David Koppelman [this message]
2008-05-11 18:44 ` Stefan Monnier
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 ` Stefan Monnier
2008-05-12 15:55 ` bug#192: " Thomas Lord
2008-05-12 15:55 ` Thomas Lord
2008-05-12 16:18 ` bug#192: " tomas
2008-05-12 16:18 ` tomas
2008-05-12 13:43 ` bug#192: " Stefan Monnier
2008-05-12 3:30 ` Thomas Lord
2008-05-11 14:27 ` Chong Yidong
2008-05-11 7:40 ` martin rudalics
2008-05-10 19:18 ` 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
2015-12-29 17:48 ` bug#192: " Bruno Haible
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='yg57ie0df8u.fsf__5440.493024844$1210528611$gmane$org@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 \
/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.