Re: update_window: w->desired_matrix is a partial representation.

[Keith David Bershatsky]

>> The cache of fake cursors contains relevant coordinates (x, y, hpos, vpos), 
>> which are needed for erasing and/or redrawing.

> Why do you cache screen coordinates and not the buffer positions?  If the 
> screen contents around some cursor don't change, you don't need to redraw the 
> cursor, so you don't need the coordinates.  And if the screen does change, 
> more often than not the coordinates will be inaccurate anyway, and need to be 
> recomputed anew.  So why cache them?

As far as I am aware, screen coordinates of a previously laid fake cursor 
cannot always be extrapolated from a particular buffer position.

Surgical removal of a particular GLYPH or GLYPHLESS fake cursor at the 
appropriate time in the near to far distant future necessitates that its screen 
coordinates be either known (cached) or ascertainable.  Removal is needed for a 
variety of reasons; e.g., PT has moved; the minor-mode for fake cursors has 
been turned off; etc.

Redrawing fake cursors (without the need to recalculate coordinates) can most 
likely be reduced to a handful of situations; e.g., Emacs fixed an overlap and 
erased an adjacent fake cursor in the process.

In the following example, the GLYPHLESS cursor floats in thin air to the right 
of buffer position 25 on VPOS 5.  [The illustration uses a few spaces before 
the | character so that we can create the illusion in this thread of a floating 
BAR_CURSOR.  In Emacs, however, the row ends immediately after the line number 
and there are no extra spaces filling the gap between the invisible space at 
the end of the glyph row (which has no buffer position) and the floating 
BAR_CURSOR.]

0.  My header-line format.
1.  12345⤸
2.  67890⤸
3.  12345⤸
4.  67890
5.     |
6.  Every good boy deserves fudge.
7.  Once upon a time there lived a ....

When the "!" gets inserted into VPOS 1 and pushes lines 6+ downwards, the 
GLYPHLESS cursor is now floating in thin air to the right of buffer position 26 
on VPOS 6.

0.  My header-line format.
1.  12!34⤸
2.  56789⤸
3.  01234⤸
4.  56789⤸
5.  0
6.     |
7.  Every good boy deserves fudge.
8.  Once upon a time there lived a ....

Fake cursors are presently used for two main purposes:

1.  A fake cursor at a specified buffer position; e.g., to use in conjunction 
with Magnar's multiple-cursors library.  Instead of using a visual overlay such 
as a solid rectangle to indicate the presence of a fake cursor, Emacs can now 
draw a BAR_CURSOR or any other cursor-type and color.

2.  A horizontal ruler, and one or two vertical rulers spanning the 
length/height of the window.  The horizontal/vertical rulers are comprised of 
GLYPH and GLYPHLESS fake cursors.  One of the vertical rulers track the cursor 
position, and the other creates a visible fill column indicator.

    2A.  As to GLYPH cursor, Emacs draws the cursor rectangle (e.g, BAR_CURSOR 
/ HBAR_CURSOR) on top of an existing character glyph, and then overwrites the 
existing character glyph with another imprint.  This is what gives the 
character with a cursor a bold appearance.

    2B.  As to a GLYPHLESS cursor, Emacs only draws the cursor rectangle in 
thin air.  These are used along or to intersect a STRETCH glyph such as a tab, 
and also where no glyph exists.


>> I have a working draft that uses the existing function update_text_area 
>> (within dispnew.c) to track changes to each VPOS, and does the following:
>
>> -  All cached fake cursors for the changed VPOS are deleted from the cache.
>
>> -  The portion of each row that remains the same, do not need the fake 
>> cursors to be redrawn (except wherever overlaps occur when rif->write_glyphs 
>> gets called) -- instead, just the cache of fake cursors gets updated for 
>> that section of the row that remains the same.
>
>> -  Subsequent to each call of rif->write_glyphs, the fake cursors get 
>> redrawn for the length of what got rewritten by rif->write_glyphs and the 
>> cache gets updated accordingly.
>
>> -  As to the relevant section from the end of the row to the x-limit that 
>> gets cleared with rif->clear_end_of_line, fake cursors are redrawn on just 
>> the portion that got erased -- the cache is updated for the entire length 
>> between the end of the row and the right window edge (assumes no right 
>> margin).

> This design assumes that update_window_line will be called for each screen 
> line where you have a cursor and whose contents change in some way.  There's 
> nothing in the display engine that makes sure this assumption is true, since 
> the display engine doesn't really know anything about your fake cursors, does 
> it?  For example, the display engine could decide to use some optimization 
> based on the buffer text, which would invalidate your assumption.

> Did you consider the alternative of calculating the screen coordinates of the 
> cursors like we do for the single "normal" cursor?  That is done in 
> set_cursor_from_row, which is called from display_line and from several 
> redisplay optimizations that avoid calling display_line.  You could call at 
> the same places your function that recalculates the coordinates of your 
> cursors, if any, in that screen line, and then store the calculated 
> coordinates in the window structure, like we do with the "normal" cursor.

I appreciate you letting me know that Emacs may update the window text in areas 
other than update_window_line; e.g., due to an existing optimization.  I will 
need to work on tracking all of them down and chisel-away at dealing with each 
one.

set_cursor_from_row loops through the glyph row containing point.  When fake 
cursors are initially calculated and whenever a significant buffer change 
occurs (e.g., when PT moves), Emacs loops through all enabled rows of the 
current matrix, and loops through each glyph row looking for a particular 
buffer position and/or relative x coordinate.  Because this is somewhat 
cumbersome for Emacs to do every command loop, I am working on ideas to 
optimize the need to recalculate and draw/erase the fake cursors -- i.e., have 
Emacs do the bare minimum based upon areas of the window that have changed 
since the previous command loop.

>> If the above-described plan of attack sounds prudent/efficient, then perhaps 
>> the appropriate place to update VPOS 6+ of the cache in this situation is 
>> wherever redisplay "scrolls the text on the glass directly"?

> See try_window_id.  Search for "Scroll the display" to see how it bypasses 
> update_window for the screen lines it scrolls.  Directly above that you will 
> find code that updates the cursor accordingly.

> If you decide to keep your current design, you should augment it so that any 
> future changes that introduce additional bypasses, such as the ones in 
> try_window_id, will be supported by fake cursors with minimum changes.

AWESOME!  Thank you for pinpointing the exact location where redisplay "scrolls 
the text on the glass directly".  Greatly appreciated!