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


Message #20 received at 192 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Bruno Haible <bruno <at> clisp.org>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, emacs-devel <at> gnu.org,
        koppel <at> ece.lsu.edu, 192 <at> debbugs.gnu.org
Subject: Re: regexp does not work as documented
Date: Tue, 06 May 2008 14:12:45 +0200
> Can someone help me find a workaround, then? If not, I would have to give up
> maintaining po-mode as part of GNU gettext. Said function is central in
> Emacs po-mode (everything else relies on it), and if multi-line regular
> expressions don't work, I don't know how this function could be rewritten.

Don't worry, Stefan will find the solution.  First of all you will
probably have to

(setq font-lock-multiline t)

in the respective buffer.  This will _not_ always DTRT after a buffer
modification, as, for example, in

AAAA

CCCC

BBBB

where AAAA stands for some old text previously matched by your regexp,
CCCC for some new text inserted (or old text removed), and BBBB for some
text which, after the change, is now matched by the regexp (or not
matched any more): In this case BBBB will be wrongly highlighted now.
Alan uses the notorious

`font-lock-extend-jit-lock-region-after-change'

function to handle this, but it's not immediately clear how to apply
this here.  If everything else fails you will have to refontify till
`window-end' (I prefer using a timer for such refontifications).





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.