From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Date: Wed, 25 Oct 2017 03:24:58 +0300 Message-ID: <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1508891170 26753 195.159.176.226 (25 Oct 2017 00:26:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Oct 2017 00:26:10 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 Cc: 28814@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 25 02:26:06 2017 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 1e79WF-0006Cc-MG for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Oct 2017 02:26:03 +0200 Original-Received: from localhost ([::1]:46024 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e79WN-00064k-23 for geb-bug-gnu-emacs@m.gmane.org; Tue, 24 Oct 2017 20:26:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44347) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e79WH-00063y-I3 for bug-gnu-emacs@gnu.org; Tue, 24 Oct 2017 20:26:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e79WE-0007Ox-7j for bug-gnu-emacs@gnu.org; Tue, 24 Oct 2017 20:26:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51748) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e79WE-0007Op-2U for bug-gnu-emacs@gnu.org; Tue, 24 Oct 2017 20:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e79WD-0004Si-Rj for bug-gnu-emacs@gnu.org; Tue, 24 Oct 2017 20:26:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Oct 2017 00:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28814 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150889110817079 (code B ref 28814); Wed, 25 Oct 2017 00:26:01 +0000 Original-Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 00:25:08 +0000 Original-Received: from localhost ([127.0.0.1]:60429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e79VM-0004RP-Ah for submit@debbugs.gnu.org; Tue, 24 Oct 2017 20:25:08 -0400 Original-Received: from mail-wr0-f170.google.com ([209.85.128.170]:47459) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e79VK-0004Qs-Jm for 28814@debbugs.gnu.org; Tue, 24 Oct 2017 20:25:07 -0400 Original-Received: by mail-wr0-f170.google.com with SMTP id y39so22329297wrd.4 for <28814@debbugs.gnu.org>; Tue, 24 Oct 2017 17:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3FazXF+9RRTP54enKRP0xLOW+4IljCtAaz7oUssrCxY=; b=kAMOmrB/wpyQJZRuv+lvL+6vvrDibp0nhQYjXjlerOYFxCqhJtgbru0+gOfBNs0qRk JtjXLfGVRq8ylzOjDb5jIX4W6vAlNJs6w9jPSS9VxFkGFM7mL+Vfyzoe1FRx5H1kF2Y4 /e1Xz6ZMuTYvONl3QTsx11wmR5eXErQwRABcRbs/YfHjJrPccShPhgj+wt6Bmz2TFxjS Iu4471mefwPYmSZR6U3PCtExuc4qnyW+i13QelrUfXbbY099o9MSzPAbnOPFKAdljSob PLLjAAVJxxxJSMhwfeHJjT0Bt36Yo/4L/xKArY+f5K65ztrcYr3TEZKIvZWkVyQSHAeM xp8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3FazXF+9RRTP54enKRP0xLOW+4IljCtAaz7oUssrCxY=; b=Snq/9jIybesaZNhICum55eLjybnHWRGRciSLY9fVE27KsFmqwRmMmZPlttXmzy7wk5 a26/ygqbOyMvayn+zc6h9DJc1SoRxHNJ3qKFPHr+dcsYWg8L8eih6/PqN4ECqpv5QRF8 Ny6isJJUmFrPbYBtCyDJJzGD60wmwkYrKz0saIHfQ4CINWQhkdu/b8RWhqguF1W3k3Fu q0s91ZWzS2lOvhOIl3H+8EoXeodIDUUxc8MLpJZD3/GhX3e64nNmzjlFjaLP2Dy5vuMb fywZhANmwrrVll9OgeMmT75wJYY9vb8SowkVmGVbEwbxM1ECuQJw7n87Gy6mjGqUH2Nk 2hYg== X-Gm-Message-State: AMCzsaUYspKJeNcDVSU8tfl54kL0fcQJ9g1vL/x7gNN+/sdN2OEFfU6D rbE2qVC8NrvFmCBTP1/2sM8= X-Google-Smtp-Source: ABhQp+R1K4Y/Hdy07H2Y4586FRVSsKvQB1tsdU/YA9IlJYJ0g3XBUvInc/Tx7cv8Y5GzOMXouRP3uQ== X-Received: by 10.223.139.82 with SMTP id v18mr307628wra.55.1508891100943; Tue, 24 Oct 2017 17:25:00 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id j2sm1819105wrj.82.2017.10.24.17.24.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 17:25:00 -0700 (PDT) In-Reply-To: <87fua91vis.fsf@gmail.com> Content-Language: en-US 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:138941 Archived-At: On 10/23/17 11:03 PM, João Távora wrote: > I read the discussion you pointed me to me by Dmitry in > http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01235.html. > > Eli, If I understand your concerns there, then the first and third > patches I proposed shouldn't in any way interfere with your use of > *xref*-related facilities. If anything, they should improve it. Overall, I don't have strong objections, so if Eli is fine with the new behavior all around, I don't mind getting them in (with maybe a few modifications), and hopefully we'll reach some better solutions by the next release. For some more context though: previously, I've tried to make it seem "like xref buffer was never there" after the user performed the navigation, in other respects too: - As we recall, the xref buffer was buried after the user performed the navigation. - The window configuration was fully restored to the one before the xref buffer was shown (with some checks like making sure the user didn't change the configuration manually thereafter), and then the navigation was performed. After that, using the "originally intended" window or frame was much easier. - All buffers that were opened just to show the xref locations were cleaned up (closed) after the navigation was performed. ...But in the end, all this stuff worked not reliably/fast/intuitively enough, and I came to the conclusion that it's not a good choice when we have an *xref* buffer that stays around for a long time. So it was removed. Now to your patches. > * 0003-Allow-split-window-sensibly-to-split-threshold-in-fu.patch > > This extends the exception granted by split-window-sensibly to > single-window frames whose dimensions are below those of splitting > thresholds to consider multi-window frames where all but one window is > dedicated. If there are other non-dedicated windows, will one of them be used (that would seem fine)? > In practice, it fixes the case where > > C-x 4 . xref-backend-definitions RET n > > would surprisingly pop-up a new frame if the original frame was already > small to start with. > > This fix to window.el appears very sound to me, but if it is not desired > for whatever reason, a more localized fix in xref.el is also possible. A fix in xref.el sounds more prudent to me, but someone else would have to comment on window.el. > * 0004-Don-t-quit-xref-window-on-RET-only-on-C-u-RET.patch > > This fixes the "disappearing *xref* problem", by bringing back the > default behaviour of not quitting the *xref* window on RET, although > allowing for that if the user types C-u RET instead. I have to wonder if we have other commands that quit the current window when called with a prefix. Particularly commands bound to RET.