all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Keith David Bershatsky <esq@lawlist.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: update_window:  w->desired_matrix is a partial representation.
Date: Thu, 17 Jan 2019 10:08:40 -0800	[thread overview]
Message-ID: <m25zuntavr.wl%esq@lawlist.com> (raw)

Thank you, Eli, for reviewing and responding to this particular thread.

VPOS 6 of the desired_matrix is _not_ enabled_p.  Thus, update_window_line is not called on that particular VPOS.

The cache of fake cursors contains relevant coordinates (x, y, hpos, vpos), which are needed for erasing and/or redrawing.  Let us assume that before redisplay, VPOS 5 has a floating BAR_CURSOR (which uses the X and HPOS of the last glyph of the row as a sort of anchor to draw/erase it).

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 floating BAR_CURSOR also gets pushed down.

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

There may not necessarily be a need to remove the BAR_CURSOR at this time.  However, the cached coordinates are now invalid for the floating BAR_CURSOR because Y and VPOS have changed.  When it comes time to remove the BAR_CURSOR at some point in the future, the attempted removal will fail because said removal uses outdated coordinates.

For all lines that get pushed downwards, the fake cursors may not need to be removed at this point in time.  However, the Y and VPOS of all fake cursors in the cache that have VPOS 6+ need to be updated.  And, the last row of the cache that was at the bottom of the screen may no longer exist because it was pushed down beyond the bottom of the screen -- so we need to delete that last row from the cache.

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

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"?

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

> Date: [01-17-2019 05:56:18] <17 Jan 2019 15:56:18 +0200>
> From: Eli Zaretskii <eliz@gnu.org>
> To: Keith David Bershatsky <esq@lawlist.com>
> CC: emacs-devel@gnu.org
> Subject: Re: update_window:  w->desired_matrix is a partial representation.
> 
> * * * 
> >
> > ERRONEOUS EXPECTATION:  I expected VPOS 6 of w->desired_matrix to be the line containing a visible line number 6, _not_ the subsequent line that contains "Every good by deserves fudge."
> 
> When you examine glyph rows of a glyph matrix, pay attention to the
> enabled_p flag of each row: a row whose enabled_p flag is reset does
> not really reflect the desired contents of the screen, but some random
> garbage.
> 
> If you are saying that row whose VPOS is 6 has its enabled_p flag set,
> and its contents is not what eventually appears on the screen, then
> I'd need a precise recipe, preferably without source-level changes to
> the current code, to reproduce the situation.  In general, redisplay
> in this case can update the screen via a method that scrolls the text
> on the glass directly, so you might not see that if you are not
> looking in the right place.  But that's just a hunch.
> 
> More generally, I don't think a display feature that relies on the
> contents of the desired matrix is a good idea, because the desired
> matrix is a tool for the display engine to update the screen, and is
> not supposed to convey the entire contents of a window, nor even
> describe reliably what will be actually updated.  Why did you need to
> rely on the desired matrix for your feature?
> 
> > QUESTION #1:  From within update_window, is it possible to programmatically access the glyph_row containing the visible line number 6?
> 
> You can look at glyph_matrix->rows[6], but the result is reliable only
> if the enabled_p flag of that row is set.
> 
> > QUESTION #2:  From within update_window, is it possible to programmatically test to see whether VPOS 6 and all subsequent screen lines have been pushed downwards to make room for the new VPOS 5?
> 
> You'd need to compare with the current_matrix for that.  But why would
> you need to know a thing like that?  Your code shouldn't care how
> exactly the display engine decided to update the screen.



             reply	other threads:[~2019-01-17 18:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-17 18:08 Keith David Bershatsky [this message]
2019-01-19  9:16 ` update_window: w->desired_matrix is a partial representation Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2019-01-19 23:03 Keith David Bershatsky
2019-01-17  8:05 Keith David Bershatsky
2019-01-17 13:56 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m25zuntavr.wl%esq@lawlist.com \
    --to=esq@lawlist.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.