From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Keith David Bershatsky Newsgroups: gmane.emacs.devel Subject: Re: update_window: w->desired_matrix is a partial representation. Date: Thu, 17 Jan 2019 10:08:40 -0800 Message-ID: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1547748411 31742 195.159.176.226 (17 Jan 2019 18:06:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 17 Jan 2019 18:06:51 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 17 19:06:47 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 1gkC3w-00084t-UF for ged-emacs-devel@m.gmane.org; Thu, 17 Jan 2019 19:06:45 +0100 Original-Received: from localhost ([127.0.0.1]:49344 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkC63-0005hl-8U for ged-emacs-devel@m.gmane.org; Thu, 17 Jan 2019 13:08:55 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51624) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkC5t-0005gi-4T for emacs-devel@gnu.org; Thu, 17 Jan 2019 13:08:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gkC5r-00054G-Sn for emacs-devel@gnu.org; Thu, 17 Jan 2019 13:08:45 -0500 Original-Received: from gateway21.websitewelcome.com ([192.185.45.228]:34348) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gkC5r-000525-EE for emacs-devel@gnu.org; Thu, 17 Jan 2019 13:08:43 -0500 Original-Received: from cm11.websitewelcome.com (cm11.websitewelcome.com [100.42.49.5]) by gateway21.websitewelcome.com (Postfix) with ESMTP id 2D883400D853E for ; Thu, 17 Jan 2019 12:08:42 -0600 (CST) Original-Received: from gator3053.hostgator.com ([50.87.144.69]) by cmsmtp with SMTP id kC5pgkpqkdnCekC5qgp5gK; Thu, 17 Jan 2019 12:08:42 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lawlist.com ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Cc :To:From:Message-ID:Date:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=tLkW216o2FsnC5Z9tbkv87l+tBTWJxt3jvoVsALtmy8=; b=iBG9Ej2ZUFvcxLY4AWYtOdk5e8 PkkV9yMRo+ruqGo+thKPt9O5f2ofxKEbL1sbZyLkxklHSOEZ18sXSutBgvNSl5fe1AujBA5D6xj6d mUHBB8Ln3xQgVX3uOH0/nAhB+pqKgngA7TN8ZyT8T99fa4yl6/q0oMVq7mF+mcihzb0KnG7ejALel O2DgX/Uq0j16vGJ81jLAAp/EVcwHbfs0HQonGaEpYg1PGmwWsd9wtPCpWVolVLZ0VfP3h25PxaQTN +u3MGuDd5SFkRVui/KJuP664zx4cgofZ1xmFS4PQIp5Dw8/LRgVDFA74eNI80IrDrI1ZaADwDMqbZ BDrZ2s3A==; Original-Received: from cpe-45-48-239-195.socal.res.rr.com ([45.48.239.195]:49636 helo=server.local) by gator3053.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.91) (envelope-from ) id 1gkC5p-001uvY-Eb; Thu, 17 Jan 2019 12:08:41 -0600 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3053.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lawlist.com X-BWhitelist: no X-Source-IP: 45.48.239.195 X-Source-L: No X-Exim-ID: 1gkC5p-001uvY-Eb X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: cpe-45-48-239-195.socal.res.rr.com (server.local) [45.48.239.195]:49636 X-Source-Auth: lawlist X-Email-Count: 1 X-Source-Cap: bGF3bGlzdDtsYXdsaXN0O2dhdG9yMzA1My5ob3N0Z2F0b3IuY29t X-Local-Domain: yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 192.185.45.228 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:232434 Archived-At: Thank you, Eli, for reviewing and responding to this particular thread. VPOS 6 of the desired_matrix is _not_ enabled_p. Thus, update_window_lin= e 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 bef= ore redisplay, VPOS 5 has a floating BAR_CURSOR (which uses the X and HPO= S of the last glyph of the row as a sort of anchor to draw/erase it). 0. My header-line format. 1. 12345=E2=A4=B8 2. 67890=E2=A4=B8 3. 12345=E2=A4=B8 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=E2=A4=B8 2. 56789=E2=A4=B8 3. 01234=E2=A4=B8 4. 56789=E2=A4=B8 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_C= URSOR 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 b= ecause 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 c= ursors 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 cach= e. - The portion of each row that remains the same, do not need the fake cu= rsors to be redrawn (except wherever overlaps occur when rif->write_glyph= s gets called) -- instead, just the cache of fake cursors gets updated fo= r that section of the row that remains the same. - Subsequent to each call of rif->write_glyphs, the fake cursors get red= rawn for the length of what got rewritten by rif->write_glyphs and the ca= che 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 ju= st the portion that got erased -- the cache is updated for the entire len= gth between the end of the row and the right window edge (assumes no righ= t margin). If the above-described plan of attack sounds prudent/efficient, then perh= aps the appropriate place to update VPOS 6+ of the cache in this situatio= n 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 > To: Keith David Bershatsky > CC: emacs-devel@gnu.org > Subject: Re: update_window: w->desired_matrix is a partial representat= ion. >=20 > * * *=20 > > > > ERRONEOUS EXPECTATION: I expected VPOS 6 of w->desired_matrix to be = the line containing a visible line number 6, _not_ the subsequent line th= at contains "Every good by deserves fudge." >=20 > 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. >=20 > 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. >=20 > 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? >=20 > > QUESTION #1: From within update_window, is it possible to programmat= ically access the glyph_row containing the visible line number 6? >=20 > You can look at glyph_matrix->rows[6], but the result is reliable only > if the enabled_p flag of that row is set. >=20 > > QUESTION #2: From within update_window, is it possible to programmat= ically test to see whether VPOS 6 and all subsequent screen lines have be= en pushed downwards to make room for the new VPOS 5? >=20 > 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.