From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: update_window: w->desired_matrix is a partial representation. Date: Thu, 17 Jan 2019 15:56:18 +0200 Message-ID: <83ef9bcrr1.fsf@gnu.org> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1547733290 20715 195.159.176.226 (17 Jan 2019 13:54:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 17 Jan 2019 13:54:50 +0000 (UTC) Cc: emacs-devel@gnu.org To: Keith David Bershatsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 17 14:54:45 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gk885-0005I5-Di for ged-emacs-devel@m.gmane.org; Thu, 17 Jan 2019 14:54:45 +0100 Original-Received: from localhost ([127.0.0.1]:45071 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gk8AC-0004Bq-Gc for ged-emacs-devel@m.gmane.org; Thu, 17 Jan 2019 08:56:56 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gk89u-00049D-LH for emacs-devel@gnu.org; Thu, 17 Jan 2019 08:56:39 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58882) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gk89r-0006J9-2m; Thu, 17 Jan 2019 08:56:38 -0500 Original-Received: from [176.228.60.248] (port=2325 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gk89g-0007BB-De; Thu, 17 Jan 2019 08:56:27 -0500 In-reply-to: (message from Keith David Bershatsky on Thu, 17 Jan 2019 00:05:28 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:232425 Archived-At: > Date: Thu, 17 Jan 2019 00:05:28 -0800 > From: Keith David Bershatsky > > * 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.