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: [Emacs-diffs] emacs-26 f274cbd: Avoid reordering of output in 'shr-insert-document' Date: Sun, 17 Dec 2017 17:44:43 +0200 Message-ID: <83a7yhqrys.fsf@gnu.org> References: <20171216141055.30854.67661@vcs0.savannah.gnu.org> <20171216141056.8391A24612@vcs0.savannah.gnu.org> <83bmiyslq7.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1513525376 7228 195.159.176.226 (17 Dec 2017 15:42:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 17 Dec 2017 15:42:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 17 16:42:51 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eQb5X-0001dt-Iw for ged-emacs-devel@m.gmane.org; Sun, 17 Dec 2017 16:42:51 +0100 Original-Received: from localhost ([::1]:54649 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQb7V-0006YD-Rp for ged-emacs-devel@m.gmane.org; Sun, 17 Dec 2017 10:44:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35173) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQb7N-0006Y7-Ql for emacs-devel@gnu.org; Sun, 17 Dec 2017 10:44:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQb7K-0002zf-Hj for emacs-devel@gnu.org; Sun, 17 Dec 2017 10:44:45 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49601) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQb7K-0002yE-Dn; Sun, 17 Dec 2017 10:44:42 -0500 Original-Received: from [176.228.60.248] (port=4322 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eQb7G-0004Wy-Kg; Sun, 17 Dec 2017 10:44:39 -0500 In-reply-to: (message from Stefan Monnier on Sat, 16 Dec 2017 17:23:02 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:221173 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Sat, 16 Dec 2017 17:23:02 -0500 > > >> Is it possible to fix the problem in shr-pixel-column (since, according > >> to the comment above, the problems comes from there)? > > No, because the value of point to preserve is from the buffer which > > was current before with-temp-buffer. > > But when we enter shr-pixel-column, that buffer's point is still the > right one, and when we leave shr-pixel-column it isn't any more, so > somehow shr-pixel-column manages to "find" that buffer in order to > modify it and hence we should also be able to similarly find that buffer > and restore its point. > > I mean, from a purely theoretical point of view, it *can* be > solved there. What I don't understand is where practical aspects end up > getting it the way. Purely theoretically, you could always do something like (with-current-buffer (window-buffer) (point)) to get at the value of point at entry into shr-pixel-column, and then a similar gork before exiting. But is that a good idea? It will slow down shr-pixel-column, which is already one of the hottest spots in shr.el's rendering. I don't think Lars will want to talk to me after that... What actually happens here is that save-window-excursion gets run afoul by the preceding with-temp-buffer, and ends up saving the wrong value of point. Specifically, save_window_save has this snippet: if (BUFFERP (w->contents)) { /* Save w's value of point in the window configuration. If w is the selected window, then get the value of point from the buffer; pointm is garbage in the selected window. */ if (EQ (window, selected_window)) p->pointm = build_marker (XBUFFER (w->contents), BUF_PT (XBUFFER (w->contents)), BUF_PT_BYTE (XBUFFER (w->contents))); else p->pointm = Fcopy_marker (w->pointm, Qnil); In the scenario we have in this case, it decides to use w->pointm, whereas the correct value is in BUF_PT. Maybe Martin will have an idea for how to fix the logic there, although it already sounds quite fragile to me, enough so to be afraid of making any changes there on the release branch. But maybe for master we could find a solution that is reliable enough. Maybe. On the release branch, I see no cake left to eat.