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

Previous Next

Full log

View this message in rfc822 format

From: David Koppelman <koppel <at> ece.lsu.edu>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: martin rudalics <rudalics <at> gmx.at>, 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: Sun, 11 May 2008 10:36:49 -0500

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 <at> 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.

Previous Next

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