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.
Date: Thu, 17 Jan 2019 15:56:18 +0200 [thread overview]
Message-ID: <83ef9bcrr1.fsf@gnu.org> (raw)
In-Reply-To: <m2k1j3zp2v.wl%esq@lawlist.com> (message from Keith David Bershatsky on Thu, 17 Jan 2019 00:05:28 -0800)
> Date: Thu, 17 Jan 2019 00:05:28 -0800
> From: Keith David Bershatsky <esq@lawlist.com>
>
> * The word-wrapped line in the first step increases in length from 4 screen lines to 5 screen lines; followed by a hard return; followed by miscellaneous lines.
>
> 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 ....
>
> RESULT:
>
> * All subsequent screen lines get pushed down one row to make room for the new row (VPOS 5) that was inserted by the undo.
>
> * update_window_line reports that VPOS lines 1 to 5 are changed_p.
>
> * If we dump_glyph_row for each line of w->desired_matrix from within update_window, we observe that the empty line between the first 6 screen lines (including the header-line) and the subsequent miscellaneous lines is _not_ present. VPOS 6 is "Every good by deserves fudge."
>
> 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.
next prev parent reply other threads:[~2019-01-17 13:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-17 8:05 update_window: w->desired_matrix is a partial representation Keith David Bershatsky
2019-01-17 13:56 ` Eli Zaretskii [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-01-17 18:08 Keith David Bershatsky
2019-01-19 9:16 ` Eli Zaretskii
2019-01-19 23:03 Keith David Bershatsky
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83ef9bcrr1.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=esq@lawlist.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).