From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) 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 08:43:57 +0100 Message-ID: <87y3nzu0xu.fsf@gmail.com> References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> 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 1508917518 18785 195.159.176.226 (25 Oct 2017 07:45:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Oct 2017 07:45:18 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) Cc: 28814@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 25 09:45:09 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 1e7GNA-0003kV-Qg for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Oct 2017 09:45:09 +0200 Original-Received: from localhost ([::1]:47007 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e7GNI-0007tr-9a for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Oct 2017 03:45:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e7GNA-0007tY-7E for bug-gnu-emacs@gnu.org; Wed, 25 Oct 2017 03:45:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e7GN5-0008DV-2g for bug-gnu-emacs@gnu.org; Wed, 25 Oct 2017 03:45:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51942) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e7GN4-0008DP-V6 for bug-gnu-emacs@gnu.org; Wed, 25 Oct 2017 03:45:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e7GN4-0003Iu-Iu for bug-gnu-emacs@gnu.org; Wed, 25 Oct 2017 03:45:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Oct 2017 07:45:02 +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.150891744812609 (code B ref 28814); Wed, 25 Oct 2017 07:45:02 +0000 Original-Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 07:44:08 +0000 Original-Received: from localhost ([127.0.0.1]:60623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7GMC-0003HI-3f for submit@debbugs.gnu.org; Wed, 25 Oct 2017 03:44:08 -0400 Original-Received: from mail-wm0-f45.google.com ([74.125.82.45]:54784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7GMB-0003H7-1T for 28814@debbugs.gnu.org; Wed, 25 Oct 2017 03:44:07 -0400 Original-Received: by mail-wm0-f45.google.com with SMTP id r68so10614wmr.3 for <28814@debbugs.gnu.org>; Wed, 25 Oct 2017 00:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=R436Vh/x09Hiiia11ffoDXDyPCcBtbH04danHiC0RW0=; b=Hpbj6YJNUmNw/YPHGcBtxRfEA2qedWZZsDdVsIXRwUq94bYggcnV7AfqjJ4Y6IG/4H sMF+wHsDy+GGQwYSnlWlIpGvJN4XiAGr7rrETz6iv0TS2lXybve03bqN85rKio0goyKo 7Emj8VPhVSqE75zu/Ae20F+l1oVmgIJAgcB2ZmXEnj5502lCtzi9SH8uT7lXg/s73aeI r3AHKZ7Z5uuZHYiktlMolpmlNgkiPpXJ3BNvKo3l4QuF5jiNjYD+dep42YXHcg0dvJld veJkIhdReTzRxcLcDTerx/W9swa53qlzkwA5lTqUKtlR3wMMA6ODiizJ+/4SECLAvwrN D+hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=R436Vh/x09Hiiia11ffoDXDyPCcBtbH04danHiC0RW0=; b=dje2J5ZN3PPDxIggCO/n3F17YIs+PcSrFUg6/xQw0E90/FwUMsuhHqph6gZyZiKxO/ IUz1e78D37NmO0pLqi1dU2ezRvf4sPJ88cmU2b5kJuSbvuUTw6Jr2eMa4qgE3FQAUZDl kPCT5aCjDTuGObUSK2QmA8PfPDNuvaLDV06AZlWIgcl6odo9rGFQ3SUBT4wwCjiuhcfC Zo3WJjJzS587gEIkoD3f2ZopJAQXcp0JHJqm9ImWD3ms/r0Vwv0AA7ccRH+R9kzGCPps bOBIdE1zyEqlDfJyIWWwtvlU7Ni6QxCj6aI3ves9pQ7vRB79cxRpcEGqg8XhMUSkXdEU CUkg== X-Gm-Message-State: AMCzsaV25hw9hD60S0a8ql808dvqnoE6Kut05EUpmK+EI9pg6G7+NSbB KFbwAlXNsb+vOKYBccd8fNs= X-Google-Smtp-Source: ABhQp+QKFp/tc3OO6vF94EYZHbhf0bz2HkzWHwuuJ6hv4iAUEfLzDwOuUsa4p1H2xEs5R1IOvfbTOQ== X-Received: by 10.28.57.4 with SMTP id g4mr730963wma.92.1508917441124; Wed, 25 Oct 2017 00:44:01 -0700 (PDT) Original-Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id j27sm1676206wrd.42.2017.10.25.00.43.59 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 25 Oct 2017 00:44:00 -0700 (PDT) In-Reply-To: <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> (Dmitry Gutov's message of "Wed, 25 Oct 2017 03:24:58 +0300") 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:138948 Archived-At: Dmitry Gutov writes: > OK, but is it the correct thing to do? The thresholds are there for a > reason, and having a window that's only a few lines tall (which could > happen in some example) will hardly be more helpful than showing it in > a different window, even if the user expected xref to use the "other > window". Well, I don=E2=80=99t think it=E2=80=99s that bad if a tiny window pops up,= considering: 1. The user *did* type C-x 4 . , meaning he specifically requested "a different window", so that=E2=80=99s life. Tiny windows can pop up via the existing exception in split-window-sensibly, too. 2. I assume we want to stand by Eli=E2=80=99s wish that the *xref* buffer s= hould stay visible (and anyway the user has a failsafe C-u RET command that buries it and should improve the situation). > This stuff is difficult, and personally I don't like either of the > easily reachable solutions. We=E2=80=99re talking about the edge cases here. Would you like a solution = where the user=E2=80=99s intention (1) is disregarded in extreme cases (and thus = the original window is considered even if the user did C-x 4 .) >> I see and I will try to answer. I proposed two patches previously: >> >> * a first one to fix the non-determinism of window popping/selecting >> behaviour; >> * a second one to make the *xref* buffer less obstrusive. >> * (now there is the third one that fixes the frame-popping glitch) >> >> IIUC it is the second one that clashes with "the dissapearing *xref* >> problem" that I have yet to read up on. If we don't come up with a >> solution for that, I would be OK with a solution that leaves it unsolved >> but adds some customization point (hook) for the user to put this >> behaviour in. >=20 >Indeed, but there's also a matter of consistency, and of making the >overall design work in a predictable fashion. More in the follow-up >email. Any of the two alternatives are more predictable than what we have now. A gain in predictability. > 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. I see, there=E2=80=99s prior art here. You approach is much more ambitious = than mine and given the hairiness of window code, it=E2=80=99s no wonder it didn= =E2=80=99t work well, if you will excuse the hindsight 20/20 :-) My approach is less ambitious but works well and predictably for these (more than) common cases: The case where I *do want* my current window (and only that one) to get clobbered. M-. symbol-with-multiple-definitions RET n [0 or more times] p [0 or more times] RET [the final decision, or C-u RET to ditch the *xref* buffer] And also the case where I *don=E2=80=99t want* my window to get clobbered, = and don=E2=80=99t care about the other ones. C-x 4 . symbol-with-multiple-definitions RET n [0 or more times] p [0 or more times] RET [the final decision, or C-u RET to ditch the *xref* buffer] If it helps, this itch didn=E2=80=99t pop out of thin air: as you know, xre= f.el is lifted from SLIME=E2=80=99s UI. SLY, my fork of SLIME, does the same, an= d a user complained about SLY=E2=80=99s use of popup windows in a way that fina= lly convinced me. See https://github.com/joaotavora/sly/issues/121 >> * 0003-Allow-split-window-sensibly-to-split-threshold-in-fu.patch > If there are other non-dedicated windows, will one of them be used > (that would seem fine)? Yes, of course, in keeping with the current spirit that splitting a small window is a last resort before popping a frame. > I have to wonder if we have other commands that quit the current > window when called with a prefix. Particularly commands bound to RET. I see, it=E2=80=99s a bit odd indeed, but I had no idea of any kind of rule= or policy in that direction. Anyway, In the thread you pointed me to, there was talk of an =E2=80=99a=E2= =80=99 command but I never saw it. It was some hypothetical xref-quit-and-goto-xref. I=E2=80=99m perfectly fine with implementing that instead. Of course my priority goes towards RET doing xref-quit-and-goto-xref and something else doing xref-goto-xref. If that default isn=E2=80=99t changed,= I=E2=80=99ll probably to that remap in my init file.. Jo=C3=A3o