From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#31695: bug-gnu-emacs@gnu.org Date: Tue, 05 Jun 2018 15:36:48 +0200 Message-ID: <5B1691F0.3070704@gmx.at> References: <20180603.101706.47071122.enometh@meer.net> <5B13DD66.1080809@gmx.at> <83h8mjddvk.fsf@gnu.org> <83tvqibjmv.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1528205784 24211 195.159.176.226 (5 Jun 2018 13:36:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 5 Jun 2018 13:36:24 +0000 (UTC) Cc: enometh@meer.net, 31695@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 05 15:36:19 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1fQC8H-00069J-Pd for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Jun 2018 15:36:18 +0200 Original-Received: from localhost ([::1]:46793 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fQCAO-0001na-TM for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Jun 2018 09:38:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57745) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fQCA2-0001f3-Nn for bug-gnu-emacs@gnu.org; Tue, 05 Jun 2018 09:38:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fQC9y-0007QJ-Q8 for bug-gnu-emacs@gnu.org; Tue, 05 Jun 2018 09:38:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54845) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fQC9y-0007Q1-MP for bug-gnu-emacs@gnu.org; Tue, 05 Jun 2018 09:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fQC9y-0002GM-AP for bug-gnu-emacs@gnu.org; Tue, 05 Jun 2018 09:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Jun 2018 13:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31695 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 31695-submit@debbugs.gnu.org id=B31695.15282058318628 (code B ref 31695); Tue, 05 Jun 2018 13:38:02 +0000 Original-Received: (at 31695) by debbugs.gnu.org; 5 Jun 2018 13:37:11 +0000 Original-Received: from localhost ([127.0.0.1]:34506 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQC99-0002F5-7E for submit@debbugs.gnu.org; Tue, 05 Jun 2018 09:37:11 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:59793) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQC98-0002Et-Av for 31695@debbugs.gnu.org; Tue, 05 Jun 2018 09:37:10 -0400 Original-Received: from [192.168.1.100] ([212.95.5.147]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MLj5z-1fPvA10I31-000sBu; Tue, 05 Jun 2018 15:36:58 +0200 In-Reply-To: <83tvqibjmv.fsf@gnu.org> X-Provags-ID: V03:K1:BQ0y5oGNg2SBvp2CoTMD7pHV5fn1MHjJsDLdRyeR1zgCEaF7kNx Mn7FPzX0fTGCwRxftszTHl2SgT1Guu/k8XZ9S/luIYP8u8vUoLcgwSS0wWXemSgCI5J+zTD R8SSnyVlCerrhQsctXL1Amt60I9wDCjG2xoUd1hisvZG3u/QUP3mGvbNDUMvBAAbQOtVfPT +0ft6nqHsIFDMBxD4ZwCg== X-UI-Out-Filterresults: notjunk:1;V01:K0:XfMwGXtNja8=:cAEFFcMCIAEzF1TOeC38vJ YG0dGgLTxdzlHHfX6QBInTTV7VpFmYwkx/6su7N/x36HO0q7j/5YoiwN97BSn2KxK9MDSqGfs 2nm22Am7ou42S3SwL/C4qi3ZYML2LDfuB7QJrYoI6nJxq29Ra2Aong482sgp9lC5WE8Q2BB+1 wpSJtgIRlmpYLnZ2gtp/vilVbXaKuQPO+aEVm4448JEASEwU+xgOsEnfJB3mtGz5RITeF3/OT lPKot6U1g0wuLwET0wka8G/aWaSIEmZg0bR5R6BzcP52wz4+ecj0AwLWyGW73/6GMZ9TnD+Lg tOkR/UsVgcMtjNPimIH9VTTdmPf5YDdoZk3A58QEhpIK70fIbvU7pRfgK/cIFlqWfaZAlzXgk PjOQ5WC/fRZBZhQKnNVKQd2hUWsnoUeioSA33RYcG1K2ZiHR1ptil/WeGq3b/5Ff8Psz5CkUB nrP25fjTgUpPpQpy03Cx2TM0OA21IBXxi5paQiab0my5wEjPRMvo0eHnl9oXVqnk8YnExMrky t1sya3uKhB072Zo5Z3K/K8QKWD/tRKAbYb6X6KRelp/OhG+Uv7cVdQILfa8PaRe5LnAKa5FXX wLT73ElqiEa/+2oYS20aS9lgyvC3knFJCgMoZqe3mJcqA6E5n/aMpm7SGP6auq3Omm6SSrWkD NiWBSA58FBHUJ9BEniTCALSDZXA4srrIo9M8Xlgf5PvET4/SavKnXw7t7mcv555WQ1c5HHV2a usUQjmA85S2gQ3hMdLqCuuyOgnODeGOZSCCQDBtELQRsATjRqial7qYfWVJmFS2yP2vkOvhb X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:147008 Archived-At: > I took a look, but as expected, got lost among twisted little > passages, all alike. It looks like the problem might be with the > insane dance we perform when entering recursive edit in the > minibuffer, where we save and restore the window configuration of the > selected frame, and also of the frame that serves as the minibuffer > frame for the selected frame. This is indeed a very troublesome aspect because we restore the current buffer (which is per se not related to window configurations) twice. Basically, it should suffice to save/restore selected frame and current buffer around saving/restoring the configuration of the minibuffer frame, but I'm afraid that this might lead to subtle changes that would go undetected for another six years. The real problem is described in this comment /* BUF_PT (XBUFFER (new_current_buffer)) gives us the position of point in new_current_buffer as of the last time this buffer was used. This can be non-deterministic since it can be changed by things like jit-lock by mere temporary selection of some random window that happens to show this buffer. So if possible we want this arbitrary choice of "which point" to be the one from the to-be-selected-window so as to prevent this window's cursor from being copied from another window. */ and indeed my change which causes the current bug executes old_point = BUF_PT (XBUFFER (new_current_buffer)); and later does if (!EQ (XWINDOW (data->current_window)->contents, new_current_buffer)) Fgoto_char (make_number (old_point)); where old_point is BUF_PT obtained from the other frame showing NEWS - the one at BOB. And it does this when restoring the configuration of the minibuffer frame. When restoring the NEWS frame the wrong setting is already cast. Replacing the last two lines with if (!EQ (XWINDOW (selected_window)->contents, new_current_buffer)) Fgoto_char (make_number (old_point)); fixes both the present bug and the behavior from Bug#12208 so if I do not find a better solution I intend to use that. IMHO the idea behind new_current_buffer = data->f_current_buffer; is inherently botched when restoring a frame where that buffer appears on another frame. > Another potential culprit is > select_window_1, which added the call to set_point_from_marker at its > end, something that wasn't there in Emacs 24.2. This might be related but I have not found any impact yet. > In any case, the immediate cause of the problem is that when redisplay > is entered the offending window is selected and has its point set at > BOB. So redisplays redraws it accordingly. > > Btw, note that if you modify the recipe to do it from frame $a, the > problem doesn't happen. Which seems to imply that this is somehow > related to the order in which redisplay redraws frames. I think. I'm quite sure this is the case. To make it happen from $a you have to set the window point of $b first, then in $a choose another window point and then start the minibuffer rigmarole. martin