emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Partial highlighting of wrapped overlay


From: Chong Yidong
Subject: Re: Partial highlighting of wrapped overlay
Date: Sun, 9 Jan 2005 09:56:55 -0500 (EST)
User-agent: SquirrelMail/1.4.3a

Hi,

I've looked into the item "Partial highlighting of wrapped overlay"
described in FOR-RELEASE (which, by the way, is erroneously listed twice.)

AFAICT, the problem is this: when a 'display string continues over more
than one glyph_row, the value of end.pos.charpos for that glyph_row will
be stuck at the starting charpos of the overlay. This is because the
redisplay engine never draws the characters underneath that overlay, to
which the intervening charpos values correspond.

Unfortunately, at xdisp.c:21475 note_mouse_highlight calls
fast_find_position, which calls row_containing_pos, which loses because it
relies on row->end.pos.charpos to find a row corresponding to a given
charpos. That's why only the last line of the overlay is highlighted.

There are several possible ways to handle this, but I don't know which is
best.

1. There is an old version of fast_find_position, #define'd out at
xdisp.c:20632, which does not call row_containing_position. Reverting it
causes to bug to go away. However, according to the comments, the newer
version is "more correct in the presence of hscrolling" (no details
given.)

2. Alter fast_find_position to detect when multiple rows have the same
end.pos.charpos. This will probably require changing its argument list (to
tell it whether use the first or last such row.) This may be safe since,
as it turns out, note_mouse_highlight is the ONLY function that calls
fast_find_position.

3. Rework redisplay to update end.pos.charpos by looking at the text
underneath the 'display overlay. No idea how to do this.

4. Don't do anything. The documentation could say to avoid using overlays
with 'display + 'mouse-highlight that wrap across lines (would anyone want
to?) Anyway, this "bug" appears in Emacs 21.3, so it's not a regression.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]