From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] emacs-26 f274cbd: Avoid reordering of output in 'shr-insert-document' Date: Sat, 16 Dec 2017 17:23:02 -0500 Message-ID: References: <20171216141055.30854.67661@vcs0.savannah.gnu.org> <20171216141056.8391A24612@vcs0.savannah.gnu.org> <83bmiyslq7.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1513462877 8125 195.159.176.226 (16 Dec 2017 22:21:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 16 Dec 2017 22:21:17 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 16 23:21:12 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 1eQKpU-0001rW-Df for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 23:21:12 +0100 Original-Received: from localhost ([::1]:52359 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQKrS-0007Ej-8h for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 17:23:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQKrM-0007Ea-KV for emacs-devel@gnu.org; Sat, 16 Dec 2017 17:23:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQKrL-00055G-MC for emacs-devel@gnu.org; Sat, 16 Dec 2017 17:23:08 -0500 Original-Received: from pmta31.teksavvy.com ([76.10.157.38]:46427) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1eQKrH-00053w-VQ; Sat, 16 Dec 2017 17:23:04 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GZDwBknDVa/zyu+M5dHAEBAQQBAQoBA?= =?us-ascii?q?YM+gVqJRYYHjhMBgjMBlwCCAR2FIgQCAoR/RBQBAQEBAQEBAQEDaCiFJQZWIxA?= =?us-ascii?q?LNBIUGA0kij2qcYpkAQEBBwIBJYNuiHmFBoVvIAWTL5ANi3CVQIdvlmiBSzYjg?= =?us-ascii?q?U8yGggwgmaDB4FsI4poAQEB?= X-IPAS-Result: =?us-ascii?q?A2GZDwBknDVa/zyu+M5dHAEBAQQBAQoBAYM+gVqJRYYHjhM?= =?us-ascii?q?BgjMBlwCCAR2FIgQCAoR/RBQBAQEBAQEBAQEDaCiFJQZWIxALNBIUGA0kij2qc?= =?us-ascii?q?YpkAQEBBwIBJYNuiHmFBoVvIAWTL5ANi3CVQIdvlmiBSzYjgU8yGggwgmaDB4F?= =?us-ascii?q?sI4poAQEB?= X-IronPort-AV: E=Sophos;i="5.45,412,1508817600"; d="scan'208";a="14049151" Original-Received: from 206-248-174-60.dsl.teksavvy.com (HELO pastel.home) ([206.248.174.60]) by smtp.teksavvy.com with ESMTP; 16 Dec 2017 17:23:02 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id C75D360770; Sat, 16 Dec 2017 17:23:02 -0500 (EST) In-Reply-To: <83bmiyslq7.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 16 Dec 2017 18:04:16 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.38 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:221152 Archived-At: >> > + ;; Save and restore point across with-temp-buffer, since >> > + ;; shr-pixel-column uses save-window-excursion, which can reset >> > + ;; point to 1. >> > + (let ((pt (point))) >> > + (with-temp-buffer >> > + (insert string) >> > + (shr-pixel-column)) >> > + (goto-char pt)))) >> 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. Stefan