-- Ville Skyttä <ville.skytta(a)xemacs.org> spake thusly:
On Thu, 2002-05-02 at 19:55, Reid Rivenburgh wrote:
> > it occurs quite frequently to me that opening parentheses are
> > still highlighted although the cursor has already moved from
> > behind the closing parentheses. of course this confuses the
> > highlighting completely in a programming mode. i attach a picture
> > of the screen for illustration
>
> I also have seen this. I use Expression highlighting, so it's
> especially obnoxious when it happens, turning the whole region
> permanently green. Unfortunately, I have no idea what triggers it,
> sorry.... It is rare, though.
Me too. Pretty annoying and hard to reproduce...
I see this relatively frequently. It seems to happen whenever there's
an error in pre-command-hook. (I don't know whether anything else will
produce the behavior.) XEmacs sets the hook to nil, which breaks
anything which relies on it, including paren-mode (which uses
paren-nuke-extent in the pre-command-hook to clear highlighting).
I can only offer a method to reproduce on my system, but since I use a
non-standard package (cua-mode from I don't know where, hacked to work
with XEmacs and zmacs-regions), it won't work for everyone. cua-mode
will replace any highlighted region when a key is pressed. This
interacts poorly with XEmacs' auto-revert feature. Steps to reproduce
are:
1. Open a file.
2. Touch the file on disk (M-! touch <filename> RET)
3. Highlight a region.
4. Hit a key.
5. In response to the "<filename> changed on disk" message,
hit "r" (revert).
6. XEmacs reverts the file, then returns a file-supersession
error to CUA-pre-hook. Since this error is not caught, XEmacs
sets pre-command-hook to nil.
The method I use to reset paren mode is:
M-x paren-set-mode RET
-- repeat four times to cycle through OFF
or sometimes:
M-: (paren-set-mode -1) RET
M-: (paren-set-mode 'paren) RET
-- use another symbol if you prefer a different mode
Unfortunately, this doesn't fix any stale highlights in the buffer, so
I usually do a revert-buffer (C-x C-v RET).
Of course, this is all a workaround for the real problem, which is that
XEmacs isn't selective about clearing the pre-command-hook. Shouldn't
it just blow away the entry that caused a problem, rather than all of
them?