From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: 26.0.90; When *xref* window is needed, original window-switching intent is lost 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: Fri, 13 Oct 2017 16:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 28814 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 28814@debbugs.gnu.org, dgutov@yandex.ru X-Debbugs-Original-To: bug-gnu-emacs@gnu.org, dgutov@yandex.ru Received: via spool by submit@debbugs.gnu.org id=B.150791088020837 (code B ref -1); Fri, 13 Oct 2017 16:08:02 +0000 Received: (at submit) by debbugs.gnu.org; 13 Oct 2017 16:08:00 +0000 Received: from localhost ([127.0.0.1]:38287 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e32VB-0005Pz-GV for submit@debbugs.gnu.org; Fri, 13 Oct 2017 12:07:57 -0400 Received: from eggs.gnu.org ([208.118.235.92]:45984) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e32V9-0005Pj-0j for submit@debbugs.gnu.org; Fri, 13 Oct 2017 12:07:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e32V2-00025d-7X for submit@debbugs.gnu.org; Fri, 13 Oct 2017 12:07:49 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:55741) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e32V2-00025U-1S for submit@debbugs.gnu.org; Fri, 13 Oct 2017 12:07:48 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e32V0-0005IZ-01 for bug-gnu-emacs@gnu.org; Fri, 13 Oct 2017 12:07:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e32Uw-00023b-Q6 for bug-gnu-emacs@gnu.org; Fri, 13 Oct 2017 12:07:45 -0400 Received: from mail-wr0-x22a.google.com ([2a00:1450:400c:c0c::22a]:56532) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e32Uw-00022o-Cy for bug-gnu-emacs@gnu.org; Fri, 13 Oct 2017 12:07:42 -0400 Received: by mail-wr0-x22a.google.com with SMTP id r79so1395857wrb.13 for ; Fri, 13 Oct 2017 09:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=hUml4e8VmZkFLaI0DuMwzEiipXP8F2WjyjHswnXKxoM=; b=WGBQUg87ow3tKT6jqlCc9E4V1YB010Dn/W+L7ByBPeyijnWUojqHsQo9aoadWjep7J Po9umFRgWHnYrm6V7kj4w05zmlJdzRg2bWfqLorjdqSFf5+1we4v1QqntHqD9chvEIqn +R1M4moskAaD4uSftzzPIera8kgpHLaBQolH+uCJaf9y5fIdzDxYgEC5qs9U3X7DI0bB s5jOoCaTGZBEwbhJzjSQQhB/UwokuYQMtqbWrbkm4UL4CNj3vRWfIo2sQAzhOs/Si4WB YtvR1cUsx90S7iJr8vosG/RAJv2l+fUcRKkjmBAtE6jbYGMqaKWL9/5MJXeWrt12kS5Y RJKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=hUml4e8VmZkFLaI0DuMwzEiipXP8F2WjyjHswnXKxoM=; b=rNI7AiwM0gplG4SwMGS8vyc+rYFzlzIpZZklWNDpdNATZn+eh08syCXIdtxyIzrmfT rXhkkrzftYaXVjWogmPRnoy+DJbmiktpfBceK8+8wpIWeKUpoUGOVw0YZ/aDROgjFRfC l+gvYQ8D3hzAkyvHf30oj5go7lkc9990hj+D8PQ93LpKOHrFbBV8RCH/gBsXQDinfIGH LCkq83OhkxBoGN9DRjVesgRw22RAcCpa0xkK006A+vJQMforFrYZ4kkZhl00MOXsE8bk RLB/WnjdPQbNscx02g9dL7dzSW98xEr/elOSIaV59WqvHxatitMtq6t1Jx6kUZRRqXtX 176A== X-Gm-Message-State: AMCzsaW8P6vmy4pNh/pkJVUVUr2bu/NBsfasVhCZkSL8PIlXNc2asaGt 3DCxhPSr1nfQpVnEUYbOS9Y= X-Google-Smtp-Source: AOwi7QBFrhGJ4Nm61kegV7MF81faXHr+qQqWxbX5VDJXOPHGByJPnY5kPifSNtpfCDD3Pp4XFO16+g== X-Received: by 10.223.151.143 with SMTP id s15mr2062285wrb.7.1507910860006; Fri, 13 Oct 2017 09:07:40 -0700 (PDT) Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id r44sm1658045wrb.37.2017.10.13.09.07.38 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 13 Oct 2017 09:07:38 -0700 (PDT) From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) Date: Fri, 13 Oct 2017 17:07:36 +0100 Message-ID: <87infjm3p3.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dmitry, maintainters, Here are two patches to fix what I believe is a small but annoying bug in xref.el. I'll try to explain as clearly as possible: As you know, if the user presses 'M-.' in a single-ref definition, he/she is transported to a new buffer. But there are other situations: when xref-find-definitions finds more than one definition, a list is shown in an *xref* buffer, normally in a new window. When the user selects an "xref" with xref-goto-xref, a buffer and window switch happen. Anyway, so far so good. The problem is there is also 'C-x 4 .' and 'C-x 5 .' for xref-find-definitions-other-window and xref-find-definitions-other-frame respectively. These work just fine when an *xref* buffer isn't needed, but when it is, the original intent of using another window or frame will be lost when the user eventually selects a definition. It shouldn't be so, in my opinion. The first patch I attach (0001-Honor-window....patch) fixes this bug. I hope it is readable enough but I can explain how it works in detail. I also attach a second patch (0002-Quit-the....patch), that does not really fix a bug, but changes the behavior of xref-goto-xref to something much nicer: it quits the *xref* window before going to the reference. This brings a nice result: As always 'M-.' switches buffers if there is only one definition. Now, if there is more than one, the final state after selecting one of these definitions is the same as if there had only been one in the first place. I think this makes sense because it preserves the expectations of the user who probably wants M-. to behave as predictably as possible. Here's hoping you're not really confused by this report, Jo=C3=A3o --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Honor-window-switching-intents-in-xref-find-definiti.patch >From 1cba860d6a2c45e0fa690065b2bf4e6658e87628 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Fri, 13 Oct 2017 15:13:14 +0100 Subject: [PATCH 1/2] Honor window-switching intents in xref-find-definitions When there is more than one xref to jump to, and an *xref* window appears to help the user choose, the original intent to open a definition another window or frame is remembered when the choice to go to or show a reference is finally made. * lisp/progmodes/xref.el (xref--show-pos-in-buf): Rewrite. (xref--original-window-intent): New variable. (xref--original-window): Rename from xref--window and move up here for clarity. (xref--show-pos-in-buf): Rewrite. Don't take SELECT arg here. (xref--show-location): Handle window selection decision here. (xref--window): Rename to xref--original-window. (xref-show-location-at-point): Don't attempt window management here. (xref--show-xrefs): Ensure display-action intent is saved. --- lisp/progmodes/xref.el | 73 +++++++++++++++++++++++++++++++++++--------------- 1 file changed, 52 insertions(+), 21 deletions(-) diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 80cdcb3f18..768fa15a6b 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -449,43 +449,72 @@ xref--with-dedicated-window (when xref-w (set-window-dedicated-p xref-w xref-w-dedicated))))) -(defun xref--show-pos-in-buf (pos buf select) - (let ((xref-buf (current-buffer)) - win) +(defvar-local xref--original-window-intent nil + "Original window-switching intent before xref buffer creation.") + +(defvar-local xref--original-window nil + "The original window this xref buffer was created from.") + +(defun xref--show-pos-in-buf (pos buf) + "Goto and display position POS of buffer BUF in a window. +Honour `xref--original-window-intent', run `xref-after-jump-hook' +and finally return the window." + (let* ((xref-buf (current-buffer)) + (pop-up-frames + (or (eq xref--original-window-intent 'frame) + pop-up-frames)) + (action + (cond ((memq + xref--original-window-intent + '(window frame)) + t) + ((and + (window-live-p xref--original-window) + (or (not (window-dedicated-p xref--original-window)) + (eq (window-buffer xref--original-window) buf))) + `(,(lambda (buf _alist) + (set-window-buffer xref--original-window buf) + xref--original-window)))))) (with-selected-window - (xref--with-dedicated-window - (display-buffer buf)) + (with-selected-window + ;; Just before `display-buffer', place ourselves in the + ;; original window to suggest preserving it. Of course, if + ;; user has deleted the original window, all bets are off, + ;; just use the selected one. + (or (and (window-live-p xref--original-window) + xref--original-window) + (selected-window)) + (display-buffer buf action)) (xref--goto-char pos) (run-hooks 'xref-after-jump-hook) (let ((buf (current-buffer))) - (setq win (selected-window)) (with-current-buffer xref-buf - (setq-local other-window-scroll-buffer buf)))) - (when select - (select-window win)))) + (setq-local other-window-scroll-buffer buf))) + (selected-window)))) (defun xref--show-location (location &optional select) (condition-case err (let* ((marker (xref-location-marker location)) (buf (marker-buffer marker))) - (xref--show-pos-in-buf marker buf select)) + (cond (select + (select-window (xref--show-pos-in-buf marker buf))) + (t + (save-selected-window + (xref--with-dedicated-window + (let (;; save-selected-window doesn't resist frame + ;; raises + (display-buffer-overriding-action + '(nil . ((inhibit-switch-frame . t))))) + (xref--show-pos-in-buf marker buf))))))) (user-error (message (error-message-string err))))) -(defvar-local xref--window nil - "The original window this xref buffer was created from.") - (defun xref-show-location-at-point () "Display the source of xref at point in the appropriate window, if any." (interactive) (let* ((xref (xref--item-at-point)) (xref--current-item xref)) (when xref - ;; Try to avoid the window the current xref buffer was - ;; originally created from. - (if (window-live-p xref--window) - (with-selected-window xref--window - (xref--show-location (xref-item-location xref))) - (xref--show-location (xref-item-location xref)))))) + (xref--show-location (xref-item-location xref))))) (defun xref-next-line () "Move to the next xref and display its source in the appropriate window." @@ -727,7 +756,8 @@ xref--show-xref-buffer (xref--xref-buffer-mode) (pop-to-buffer (current-buffer)) (goto-char (point-min)) - (setq xref--window (assoc-default 'window alist)) + (setq xref--original-window (assoc-default 'window alist) + xref--original-window-intent (assoc-default 'display-action alist)) (current-buffer))))) @@ -754,7 +784,8 @@ xref--show-xrefs (t (xref-push-marker-stack) (funcall xref-show-xrefs-function xrefs - `((window . ,(selected-window))))))) + `((window . ,(selected-window)) + (display-action . ,display-action)))))) (defun xref--prompt-p (command) (or (eq xref-prompt-for-identifier t) -- 2.11.0 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0002-Quit-the-xref-window-if-user-decides-to-go-to-a-ref.patch >From 228cb812197bd68b2fb6eccc60d7956675a728f3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Fri, 13 Oct 2017 16:37:47 +0100 Subject: [PATCH 2/2] Quit the *xref* window if user decides to go to a ref * lisp/progmodes/xref.el (xref--show-location): When SELECT is t, quit window. --- lisp/progmodes/xref.el | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 768fa15a6b..3a5e9e53ed 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -495,9 +495,12 @@ xref--show-pos-in-buf (defun xref--show-location (location &optional select) (condition-case err (let* ((marker (xref-location-marker location)) - (buf (marker-buffer marker))) + (buf (marker-buffer marker)) + (xref-buffer (current-buffer))) (cond (select - (select-window (xref--show-pos-in-buf marker buf))) + (quit-window nil nil) + (with-current-buffer xref-buffer + (select-window (xref--show-pos-in-buf marker buf)))) (t (save-selected-window (xref--with-dedicated-window -- 2.11.0 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 14 19:47:48 2017 Received: (at control) by debbugs.gnu.org; 14 Oct 2017 23:47:48 +0000 Received: from localhost ([127.0.0.1]:40743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3W9j-0001Xz-4b for submit@debbugs.gnu.org; Sat, 14 Oct 2017 19:47:48 -0400 Received: from mail-io0-f172.google.com ([209.85.223.172]:50843) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3W9h-0001Xk-2l for control@debbugs.gnu.org; Sat, 14 Oct 2017 19:47:45 -0400 Received: by mail-io0-f172.google.com with SMTP id 97so12507613iok.7 for ; Sat, 14 Oct 2017 16:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:subject:date:message-id:mime-version; bh=jQfww8J8eUG+NIYCvjK7KrrAHl3A7dbnE+dylSPZxDA=; b=Z2kbT8EiC/BTAdAsb6tp1uCdod+z3neUowiBGhSIJ/kGyKhz+Jl4nDlY4Iul8b97Eb IiuzKYppdD/8iyaYcwBHhFa86BBoMI8gYbffbVjqKhijoe1F7vi91hMcxicEux8ddF3t 7JiJyaHmnjuHEItbV3Ls+9K+l5YJQizpgERTaZGmzT73jPPknndq5lCpFmbymfH1CAh3 bV9b4yD7eBGF5Ricg70H+r6Z6lAqYU/WTI4QtBgHypma+dp6/327f6rEkgAcd010nXFq Zs4mEnAe/OI4UcAVO0A2xhR1O/dPRlz9IhrG0eoqfF7wWM+DGyhB8iX3ftKWLGYHOKAy /jnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:subject:date:message-id :mime-version; bh=jQfww8J8eUG+NIYCvjK7KrrAHl3A7dbnE+dylSPZxDA=; b=eGMi+ZO5pyJeLesLLu/x6sOrmGNoqWL5e5THdtJaSltdNSg9gHRsXJaCYucyt4ajLq NONtwRti4X3jPD6CSd4HoQqeBdBiARekodaASgZwbsg1AF0Ro6QZjw3R8VEeSNJ+Thg3 LMSu3yC5sY9DzRA/UKg3bH+HR1jIYvLSbAFTKlaC0Ox6DizBc8WQjDA+19jveJlQ1r4h 9RaglApYE0ug9e85UKeNLtXpyUjJbpriww95LhTsi02GRtsouMhnJQrt+zr4lt9VLpCe dC6yNWKa/3ngI6w/AJEbGRIW36I6LPLaRpcN9TVjnYKrCBjtedwB+GBVzOHw5hwHVWIS vVXw== X-Gm-Message-State: AMCzsaXS4tdUIb4rn9c3NmPIxYU0Hwkyx+8E/deZmgfUq5rHAOPP4OI6 b+GDwKzUwxsPnNX3FzzdaXlzGg== X-Google-Smtp-Source: ABhQp+TwedGGz+Getmbt+qoPdow7SvxijDCMvU9kcYobw6a7ThLUR8rjCdaom1gS4nEJis06Yi30+w== X-Received: by 10.107.35.148 with SMTP id j142mr2431126ioj.241.1508024859407; Sat, 14 Oct 2017 16:47:39 -0700 (PDT) Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id z8sm2169829itc.22.2017.10.14.16.47.38 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 14 Oct 2017 16:47:38 -0700 (PDT) From: Noam Postavsky To: control@debbugs.gnu.org Subject: control message for bug #28814 Date: Sat, 14 Oct 2017 19:47:37 -0400 Message-ID: <87376l9tra.fsf@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) tags 28814 + patch quit From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: Acknowledgement (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: =?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: Mon, 16 Oct 2017 17:59: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 To: 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150817672929129 (code B ref 28814); Mon, 16 Oct 2017 17:59:01 +0000 Received: (at 28814) by debbugs.gnu.org; 16 Oct 2017 17:58:49 +0000 Received: from localhost ([127.0.0.1]:44195 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e49f6-0007Zk-UV for submit@debbugs.gnu.org; Mon, 16 Oct 2017 13:58:49 -0400 Received: from mail-qk0-f179.google.com ([209.85.220.179]:55719) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e49f5-0007ZZ-PC for 28814@debbugs.gnu.org; Mon, 16 Oct 2017 13:58:47 -0400 Received: by mail-qk0-f179.google.com with SMTP id x82so13926714qkb.12 for <28814@debbugs.gnu.org>; Mon, 16 Oct 2017 10:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=r5BF29BG3mPttERWmWZP28ewrrFiO5/4aMe1xGJi/jg=; b=LpTVZ0xZqBNYCVa+5b7q18Kkl/pZzZNpcj3i06R4ZYOu7XGKCr+HHBsaeKl3MjCUrS gDIR7yf69JUKY20KLjpwbl385Ar+8Rw58zlYRjMhfNEjnfkPIIQasaI2mcms05mcnxDc fRkRF4AE3rJz9i9jKS4SaCi1jUz7MhRRl/GZZ32Zo4QlcwSAN01MRPKKkNYMqy2kk8co b0XXvyE7GAAf9mcZC1nYIY/unRErKM3qmFY6uc5tToCbMqkB8RTXGCPUqJZn15I1M9Qy TsLzUMMYYceqQgcAjYoCF1rmtjKGGrOVPgZtsFgNxC047m3ZFEb5i8nR7lrsVwS/yGNZ kjNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=r5BF29BG3mPttERWmWZP28ewrrFiO5/4aMe1xGJi/jg=; b=MiLAoNpavYTvLIwuFGvzxKGH7i9ara5OMslllZtYDwIY04TUGMN79gbsYTK3x2W+xC mzeXXdQ/B4tX27hbkBSzwEvNkMR53AO0/RmadhvV5MAR0Pz/z88ucncyTbB06DUNbaGp kA0mum3iZ1bO20V1IT053lyXFvkE/q3fGr7V45ZdDZv/MHoARDquGOcRLElNknuXtpgc WjoHA0/hZRBolPFwVjUJ9KSkR9HwQIdJUiK00lpYz/bZUjVCG//vbb9ef9XYbnxsIyu7 HNV+CaqnwL0oW70iav3p0qmuljaSpYwkrw9l3H0k/14TQcRALM8UJqc5zFjwimAwMBLE wYtQ== X-Gm-Message-State: AMCzsaUcFi4lVXKBC+oMwZC9U2nKyQArT46H3NtqjpuP3n9ec4+JvUEU R0d+COlnFt+dDHk5sJONr5fee7/QbBjpiJueKs0Il+Qg X-Google-Smtp-Source: ABhQp+TQdfzz+TpvUEwXBjY5z8JER2aT2I79jwkReY/RQ0OMl+h+KsEtz++TCjt4ZxErKDKP+XUlzrABIQsJri+xt0Q= X-Received: by 10.55.167.22 with SMTP id q22mr1960194qke.234.1508176722089; Mon, 16 Oct 2017 10:58:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.145.228 with HTTP; Mon, 16 Oct 2017 10:58:21 -0700 (PDT) In-Reply-To: References: <87infjm3p3.fsf@gmail.com> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 16 Oct 2017 18:58:21 +0100 Message-ID: Content-Type: multipart/alternative; boundary="001a114fbc8cc75bed055badc131" X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) --001a114fbc8cc75bed055badc131 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable tags 28814 patch On Fri, Oct 13, 2017 at 5:08 PM, GNU bug Tracking System < help-debbugs@gnu.org> wrote: > Thank you for filing a new bug report with debbugs.gnu.org. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > bug-gnu-emacs@gnu.org > > If you wish to submit further information on this problem, please > send it to 28814@debbugs.gnu.org. > > Please do not send mail to help-debbugs@gnu.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 28814: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D28814 > GNU Bug Tracking System > Contact help-debbugs@gnu.org with problems > --=20 Jo=C3=A3o T=C3=A1vora --001a114fbc8cc75bed055badc131 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
tags 28814 patch

On F= ri, Oct 13, 2017 at 5:08 PM, GNU bug Tracking System <= help-debbugs@gnu.= org> wrote:
Thank you for f= iling a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
=C2=A0bug-gnu-emacs@gnu.org
If you wish to submit further information on this problem, please
send it to 28814@debbugs.gnu.org.

Please do not send mail to help-deb= bugs@gnu.org unless you wish
to report a problem with the Bug-tracking system.

--
28814: http://debbugs.gnu.org/cgi/bugreport= .cgi?bug=3D28814
GNU Bug Tracking System
Contact help-debbugs@gnu.org wi= th problems



--
Jo=C3= =A3o T=C3=A1vora
--001a114fbc8cc75bed055badc131-- From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) 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: Fri, 20 Oct 2017 09:14: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 To: 28814@debbugs.gnu.org Cc: dgutov@yandex.ru X-Debbugs-Original-To: help-debbugs@gnu.org (GNU bug Tracking System) X-Debbugs-Original-Cc: 28814@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150849083414652 (code B ref 28814); Fri, 20 Oct 2017 09:14:01 +0000 Received: (at 28814) by debbugs.gnu.org; 20 Oct 2017 09:13:54 +0000 Received: from localhost ([127.0.0.1]:51098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e5TNK-0003oG-7J for submit@debbugs.gnu.org; Fri, 20 Oct 2017 05:13:54 -0400 Received: from mail-wm0-f45.google.com ([74.125.82.45]:44449) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e5TNI-0003o1-6g for 28814@debbugs.gnu.org; Fri, 20 Oct 2017 05:13:52 -0400 Received: by mail-wm0-f45.google.com with SMTP id 196so18763598wma.1 for <28814@debbugs.gnu.org>; Fri, 20 Oct 2017 02:13:52 -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; bh=65zxZVmQ6COLMU6aSDHy4n7oOabF8r+9DmwdC5YWNgg=; b=nzelxcujYEPxNzGdVI9ZMGo6tIzCpFgwflhBE4hVCGbK3dijL8/bKE7nYxAnWO9lvQ FNjav6iZj3qv2yHiPHp0nwq3htfQl7SwTMVucgxrv1kD02j6c+LOBR5RyfKKkkxxJrea 76Yyrc8nn71MvaWtV89Hb1Cs0gl1gaKRpuAG4TqlW141kspimZ4cS+T9zXScId0mBJIv 8JjjPiQ8GYmx866nPQHgTu0E66gWQU3gjRHVIDggS+5jKS2zLQ8ZelURDN8BOShf0cVo Blw9RYD3SLO6llbqGqOKbiZByVP7b87O03e7QZdvmHpmR1Q9n0yJ7MDzSotNoa7qByK/ UB6A== 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; bh=65zxZVmQ6COLMU6aSDHy4n7oOabF8r+9DmwdC5YWNgg=; b=H2Y/VqDlvO7r98i2R6YEZnavNLPW6i4bLQncz58eMZlKQGqf6lMQ26ojcvaSwNvDH6 UJJZDQu5YbSyRBKlkA1+wJIL5EWcNFDmEy1HuAkcVgLqLSh1GK5FqU9bwpD1xexN+IFC Msd6iCNG2sNNSAJutqSeFCvwKSUDpkwXDCdvz+/M9jg/xGRUVIyqwWR7+pEOqN9Z7EpG qXYQgVIM9eSsvQBQcWIq6YA5HRUCa0TP2ghXuodIzYvj/Lm4PT3bWBlmsN81lSwsPhmn xdSis0k8mKExTUQ0ItTSxVC+N6MWK/FNvD/wQ4yu2sCG7IuMXtm8/gsq3RAO0UyABVGF sa8w== X-Gm-Message-State: AMCzsaXLutJcc1FW26oqdKV4L7v3ObSGS7YYV1UwnoLA2E8NPNJ9/xQ1 wGyKal7Kf19OIsZPnvhbuT0= X-Google-Smtp-Source: ABhQp+TtuoxVo2O0Txp/2FhvdswZtUsyemsrGHgBFKKPrIMIzOPr7qp5C9HHo2hwKqndRYLCYbT2qA== X-Received: by 10.28.16.209 with SMTP id 200mr1068247wmq.35.1508490826600; Fri, 20 Oct 2017 02:13:46 -0700 (PDT) Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id 67sm1211202wmw.22.2017.10.20.02.13.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 20 Oct 2017 02:13:45 -0700 (PDT) From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) References: <87infjm3p3.fsf@gmail.com> Date: Fri, 20 Oct 2017 10:13:43 +0100 In-Reply-To: (GNU bug Tracking System's message of "Fri, 13 Oct 2017 16:08:02 +0000") Message-ID: <871slyi3lk.fsf_-_@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ping, Hoping someone can take a look at this bug I reported a week ago. Here are two very simple Emacs -Q recipes that demonstrate it. emacs -Q C-x 3 [split-window-right] C-x 2 [split-window-below] M-. xref-backend-definitions RET [xref-find-definitions] C-n [next-line] RET [xref-goto-xref] Expected the definition to be found in the original window where I pressed M-. but instead it was found in another. Another case: emacs -Q C-x 4 . xref-backend-definitions RET [xref-find-definitions-other-window] C-n RET Expected the definition to be found in some other window, different from the one I pressed M-. on. Instead went to the same one. Also, in both situations, expected the window configuration to be the same as if I had searched for, say xref-backend-functions. This is fixed by the patches that I reattach after minor tweaks. The general idea is to have the *xref*, whose sudden appearance is hard to predict, obtrude as little as possible on the user's window configuration. Jo=C3=A3o --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Honor-window-switching-intents-in-xref-find-definiti.patch >From 1b760816ac8886313996c635ee1cf696b937c20e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Fri, 13 Oct 2017 15:13:14 +0100 Subject: [PATCH 1/2] Honor window-switching intents in xref-find-definitions When there is more than one xref to jump to, and an *xref* window appears to help the user choose, the original intent to open a definition another window or frame is remembered when the choice to go to or show a reference is finally made. * lisp/progmodes/xref.el (xref--show-pos-in-buf): Rewrite. (xref--original-window-intent): New variable. (xref--original-window): Rename from xref--window and move up here for clarity. (xref--show-pos-in-buf): Rewrite. Don't take SELECT arg here. (xref--show-location): Handle window selection decision here. (xref--window): Rename to xref--original-window. (xref-show-location-at-point): Don't attempt window management here. (xref--show-xrefs): Ensure display-action intent is saved. --- lisp/progmodes/xref.el | 69 +++++++++++++++++++++++++++++++++++--------------- 1 file changed, 48 insertions(+), 21 deletions(-) diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 80cdcb3f18..c3e7982205 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -449,43 +449,68 @@ xref--with-dedicated-window (when xref-w (set-window-dedicated-p xref-w xref-w-dedicated))))) -(defun xref--show-pos-in-buf (pos buf select) - (let ((xref-buf (current-buffer)) - win) +(defvar-local xref--original-window-intent nil + "Original window-switching intent before xref buffer creation.") + +(defvar-local xref--original-window nil + "The original window this xref buffer was created from.") + +(defun xref--show-pos-in-buf (pos buf) + "Goto and display position POS of buffer BUF in a window. +Honour `xref--original-window-intent', run `xref-after-jump-hook' +and finally return the window." + (let* ((xref-buf (current-buffer)) + (pop-up-frames + (or (eq xref--original-window-intent 'frame) + pop-up-frames)) + (action + (cond ((memq + xref--original-window-intent + '(window frame)) + t) + ((and + (window-live-p xref--original-window) + (or (not (window-dedicated-p xref--original-window)) + (eq (window-buffer xref--original-window) buf))) + `(,(lambda (buf _alist) + (set-window-buffer xref--original-window buf) + xref--original-window)))))) (with-selected-window - (xref--with-dedicated-window - (display-buffer buf)) + (with-selected-window + ;; Just before `display-buffer', place ourselves in the + ;; original window to suggest preserving it. Of course, if + ;; user has deleted the original window, all bets are off, + ;; just use the selected one. + (or (and (window-live-p xref--original-window) + xref--original-window) + (selected-window)) + (display-buffer buf action)) (xref--goto-char pos) (run-hooks 'xref-after-jump-hook) (let ((buf (current-buffer))) - (setq win (selected-window)) (with-current-buffer xref-buf - (setq-local other-window-scroll-buffer buf)))) - (when select - (select-window win)))) + (setq-local other-window-scroll-buffer buf))) + (selected-window)))) (defun xref--show-location (location &optional select) (condition-case err (let* ((marker (xref-location-marker location)) (buf (marker-buffer marker))) - (xref--show-pos-in-buf marker buf select)) + (cond (select + (select-window (xref--show-pos-in-buf marker buf))) + (t + (save-selected-window + (xref--with-dedicated-window + (xref--show-pos-in-buf marker buf)))))) (user-error (message (error-message-string err))))) -(defvar-local xref--window nil - "The original window this xref buffer was created from.") - (defun xref-show-location-at-point () "Display the source of xref at point in the appropriate window, if any." (interactive) (let* ((xref (xref--item-at-point)) (xref--current-item xref)) (when xref - ;; Try to avoid the window the current xref buffer was - ;; originally created from. - (if (window-live-p xref--window) - (with-selected-window xref--window - (xref--show-location (xref-item-location xref))) - (xref--show-location (xref-item-location xref)))))) + (xref--show-location (xref-item-location xref))))) (defun xref-next-line () "Move to the next xref and display its source in the appropriate window." @@ -727,7 +752,8 @@ xref--show-xref-buffer (xref--xref-buffer-mode) (pop-to-buffer (current-buffer)) (goto-char (point-min)) - (setq xref--window (assoc-default 'window alist)) + (setq xref--original-window (assoc-default 'window alist) + xref--original-window-intent (assoc-default 'display-action alist)) (current-buffer))))) @@ -754,7 +780,8 @@ xref--show-xrefs (t (xref-push-marker-stack) (funcall xref-show-xrefs-function xrefs - `((window . ,(selected-window))))))) + `((window . ,(selected-window)) + (display-action . ,display-action)))))) (defun xref--prompt-p (command) (or (eq xref-prompt-for-identifier t) -- 2.14.2 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0002-Quit-the-xref-window-if-user-decides-to-go-to-a-ref.patch >From 9feaf473479dcd8edcf2c0bb14044995abb5eeb0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Fri, 13 Oct 2017 16:37:47 +0100 Subject: [PATCH 2/2] Quit the *xref* window if user decides to go to a ref The idea is to have this window, whose sudden appearance is hard to predict, obtrude as little as possible on the user's window configuration. * lisp/progmodes/xref.el (xref--show-location): When SELECT is t, quit window. --- lisp/progmodes/xref.el | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index c3e7982205..cf9e027ba0 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -495,9 +495,12 @@ xref--show-pos-in-buf (defun xref--show-location (location &optional select) (condition-case err (let* ((marker (xref-location-marker location)) - (buf (marker-buffer marker))) + (buf (marker-buffer marker)) + (xref-buffer (current-buffer))) (cond (select - (select-window (xref--show-pos-in-buf marker buf))) + (quit-window nil nil) + (with-current-buffer xref-buffer + (select-window (xref--show-pos-in-buf marker buf)))) (t (save-selected-window (xref--with-dedicated-window -- 2.14.2 --=-=-= Content-Type: text/plain help-debbugs@gnu.org (GNU bug Tracking System) writes: > Thank you for filing a new bug report with debbugs.gnu.org. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > bug-gnu-emacs@gnu.org > > If you wish to submit further information on this problem, please > send it to 28814@debbugs.gnu.org. > > Please do not send mail to help-debbugs@gnu.org unless you wish > to report a problem with the Bug-tracking system. --=-=-=-- From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 20 Oct 2017 10:40: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 To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150849595623466 (code B ref 28814); Fri, 20 Oct 2017 10:40:02 +0000 Received: (at 28814) by debbugs.gnu.org; 20 Oct 2017 10:39:16 +0000 Received: from localhost ([127.0.0.1]:51174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e5Uhv-00066P-N3 for submit@debbugs.gnu.org; Fri, 20 Oct 2017 06:39:15 -0400 Received: from mail-wm0-f45.google.com ([74.125.82.45]:52816) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e5Uhu-00066D-8h for 28814@debbugs.gnu.org; Fri, 20 Oct 2017 06:39:14 -0400 Received: by mail-wm0-f45.google.com with SMTP id k4so21600120wmc.1 for <28814@debbugs.gnu.org>; Fri, 20 Oct 2017 03:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zEfARyA4GVwqlt8y6M/08U35V1MxG8XCMGzLW/qDuNw=; b=cgnYb0t0Y4n2YPIP95picqxjtaK1SRufiiKkB4WMLBprbibi0A7eGQvXFrS8KY2FhF 0P6ouQ670W9oyr3ItwfBjHnpS4BiXrmmT2XmxUJktrdGE4DDeB5KY6zq4+C4Jgqjq/DT FGJfZzFTilGLZb18BdKgtlldKWX2vzwDiI4ZDn9SU+hWu4rciRJWFPCyFrU/v2BgfddR qV1fVkzw5+jKWKhXe82Jj91h9yLq13Kq60YdE2mCuSNF3D6XNODyRE8vgUSoD0XWqGod LdvBm/7u+rClLTzMcEzn7E7QcUUgg4zvE7Ipw0yOpIJSTNoBXRabzdjG66FSq7Lwu2PT IDJw== 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:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zEfARyA4GVwqlt8y6M/08U35V1MxG8XCMGzLW/qDuNw=; b=czTz1Qt0K8ouy/OO4PkqsSvm23MHHOW0srcsVnd0puBebz1ifGICOyLPV+N/cNDHyl eNkscXL2n8BU0sdCKiDBtSkCouk0lOyM/XeFnEgk4OLNc4gwE5ujABs5Bryff9tsVRq6 A882GwTZGVQtHY6AuKVkoV0VTbaAhx4i9NPTslt/sAEzhajqtJNwKNUjhyLKXuSMXST9 pwM2Ut4TywmKpJ9aUPR7txGkaLIYsbl4sLOs6rCuBJVhPo18iUAzNWcnnS1mir2/aQut uYMGK3MQtgQyy3wDQKaHBThxU/JYdkbB9pzj+oIfPuCdNPqIzKCyLgP2XTK6Clte/Raw 1G1Q== X-Gm-Message-State: AMCzsaX9UJMg7seuxeP5De0EDxkvJ7Ew0Br2tVKUGe+CR2akOzuMhAj/ Zom253xXUSvRACmD9S8djtJ0aUZ1 X-Google-Smtp-Source: ABhQp+SAqnCQ4BZFPHYRiS9H/bFAfD53U5kUYhIp55wCOSK54VBVba0pVZtoPhsSEZKYESYfvuy8OA== X-Received: by 10.80.175.66 with SMTP id g60mr5986505edd.283.1508495948101; Fri, 20 Oct 2017 03:39:08 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id s6sm1007541edd.23.2017.10.20.03.39.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Oct 2017 03:39:06 -0700 (PDT) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> From: Dmitry Gutov Message-ID: Date: Fri, 20 Oct 2017 13:39:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <871slyi3lk.fsf_-_@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) Hi Joao, On 10/20/17 12:13 PM, João Távora wrote: > Hoping someone can take a look at this bug I reported a week ago. Sorry for the late reply. I'll look at it this weekend. From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Oct 2017 02:07: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 To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150872440823433 (code B ref 28814); Mon, 23 Oct 2017 02:07:02 +0000 Received: (at 28814) by debbugs.gnu.org; 23 Oct 2017 02:06:48 +0000 Received: from localhost ([127.0.0.1]:56434 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e6S8e-00065t-7a for submit@debbugs.gnu.org; Sun, 22 Oct 2017 22:06:48 -0400 Received: from mail-wr0-f171.google.com ([209.85.128.171]:48774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e6S8c-00065d-EM for 28814@debbugs.gnu.org; Sun, 22 Oct 2017 22:06:46 -0400 Received: by mail-wr0-f171.google.com with SMTP id 15so1972471wrb.5 for <28814@debbugs.gnu.org>; Sun, 22 Oct 2017 19:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SY90l+a7/SbB7MccjJmmx/ecndomD0hfgkr6HJRJX9o=; b=Et3pQmhnwFWxaHvkWf+oC59l0vd3xSPQ49wr4yL43MwMAARbtb7DK2gxssd9LEs5ED PXkdk+0Ox9soNmSAsre/4CMFA+5Ta2LwrZkqL0a4Rshb/k5VUNshyLyEwNpOA9Ffgywp CgF/1eDkC/YQ/rx/BUH8eqPBpFER0Jbwh3yl0DY7VLj47dx39zHBBvyLZIQ8w0zMG/zk iw12A4brlct2g4gEijv/QLJ7jsGPiLTjfr52GqjIqrY/icH7e3a469jmoAkjsKPa9K3b dhvGqtkWutt684nr5pfBHLH/DrecrQaHx1QosT7dAKKgI49SSDcjG56jlmTnGzQ9wyCt 00zQ== 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:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SY90l+a7/SbB7MccjJmmx/ecndomD0hfgkr6HJRJX9o=; b=XrhMRpYZ6TyEmHAJKzddbP2Lb8Trnw/vP0zxhjPm2reQyFh2Alq36XR+2vpu9de4/9 wpyfLkJtr3zD2GwXDxIRV2rKDOyk0zAHz+k+eFoeyVnYiBc5BNkAfJOjXQnuGM7xLhcf desJu+x3K9AYj9exPCISIhBjYhKSu6XalEsHNHkdlitZsJi+xDx0hovLGVgxLYhJmohf 3L995w/Fyvsv1lyNIbW9lJC2I9wGqmVsqN/otczZGfeOSuMtUUjdnqShnvmRtV2t8Yzz OVIzI2yl4MjVzK1XUqwvvZgGqPyiK483Y5DWWQg0/hUD5lZRvstCdA25DHyNh9m48Qxx 82QQ== X-Gm-Message-State: AMCzsaWnjWB7ruBedMZbcoMeNmhLBFCNdTCgH/Of7KY66Td3nlZmH8Ai yaFDPeG+CGLS6WeZqewHC07RBg5v X-Google-Smtp-Source: ABhQp+T97OlYqejOtN43xCD/vwjoJiiz5WM18IOcIkVVjh8s3EA3bDA+kdRXaFa6ZKwbJ8h6nmX7eA== X-Received: by 10.223.171.69 with SMTP id r5mr9901447wrc.112.1508724400591; Sun, 22 Oct 2017 19:06:40 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id u52sm9004701wrb.68.2017.10.22.19.06.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Oct 2017 19:06:39 -0700 (PDT) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> From: Dmitry Gutov Message-ID: Date: Mon, 23 Oct 2017 05:06:37 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <871slyi3lk.fsf_-_@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) Hi Joao, On 10/20/17 12:13 PM, João Távora wrote: > Hoping someone can take a look at this bug I reported a week ago. Here > are two very simple Emacs -Q recipes that demonstrate it. You are working on something that I agree is a real problem, but doing this would effectively revert commit 5698947ff9335cf150c73cca257a5e7e5951b045, which was based on a previous discussion (see the link in the commit message), and in particular, would bring back "disappearing *xref* buffer problem", as Eli put it. The essence of the problem is that xref buffers try to serve two related but distinct purposes that the user might be aiming at: - Pick a result from the list and jump to it, forgetting the rest (basically providing a completion interface). - Iterate through results and do something with each of them in turn. Even for xref-find-definitions, we can't rule out the purpose #2. Again, also see the previous discussion. I have a rough idea on how to fix the situation, but nothing even close to an implementation. > emacs -Q > C-x 3 [split-window-right] > C-x 2 [split-window-below] > M-. xref-backend-definitions RET [xref-find-definitions] > C-n [next-line] > RET [xref-goto-xref] > > Expected the definition to be found in the original window where I > pressed M-. but instead it was found in another. Another case: > > emacs -Q > C-x 4 . xref-backend-definitions RET [xref-find-definitions-other-window] > C-n > RET > > Expected the definition to be found in some other window, different from > the one I pressed M-. on. Instead went to the same one. With your patches applied, this example pops a new frame for me if I press 'n' instead of 'C-n'. This is not hugely important in the light of the larger problems above, but demonstrated difficulties with window management when we try to pretend that the xref buffer "was never there". > Also, in both > situations, expected the window configuration to be the same as if I had > searched for, say xref-backend-functions. > > This is fixed by the patches that I reattach after minor tweaks. The > general idea is to have the *xref*, whose sudden appearance is hard to > predict, obtrude as little as possible on the user's window > configuration. If we don't bring back the "disappearing *xref* buffer problem", *xref* has to stay obtrusive. Do you think the rest of your patch will make sense with that change? From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) 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: Mon, 23 Oct 2017 08:24: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 To: Dmitry Gutov Cc: 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.15087469972149 (code B ref 28814); Mon, 23 Oct 2017 08:24:01 +0000 Received: (at 28814) by debbugs.gnu.org; 23 Oct 2017 08:23:17 +0000 Received: from localhost ([127.0.0.1]:56591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e6Y0z-0000Ya-33 for submit@debbugs.gnu.org; Mon, 23 Oct 2017 04:23:17 -0400 Received: from mail-wm0-f45.google.com ([74.125.82.45]:56167) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e6Y0y-0000YM-0S for 28814@debbugs.gnu.org; Mon, 23 Oct 2017 04:23:16 -0400 Received: by mail-wm0-f45.google.com with SMTP id u138so8127491wmu.4 for <28814@debbugs.gnu.org>; Mon, 23 Oct 2017 01:23:15 -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; bh=72Qu1lAwjPqMVGsFdmftYH5jYQJJ3mVR9yU/g+x+njo=; b=mbzEuohrBKHgO9wynBWBiaT7SujMtIZTjXsYdnWbBjeD0SALtVwuUtEMP6oHsE6hTf c6qsV0PFVGCfE7wczXfIrG1lPJW5QhtGMpi2zFpSRYZWNk+XZRv9hzqayCjxTeUYgihd HNN4XumuH9fyHR5vnnRUHNj7Ax1uAqyIxifk0NPlNO618ILbwGLpB3EtMrXicez2u5jM 4sV9gBXF3fMWLIKAMefw0H1LETbeHwEAh6Dbn6k8g4Tt4facur0TwjDiT/aZw/6SvxqS WaxvaQ9/WtiFBwkGx47+4ft54TGs89HzFndXpaTRUWau+yhbKoBgn3NL+l8qzTcMLDH8 bFwA== 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; bh=72Qu1lAwjPqMVGsFdmftYH5jYQJJ3mVR9yU/g+x+njo=; b=ShSCoWzheREcilasbS/M8UVTGrjA7WCCfAp81i/OGZ3npqTpyhiINyh394ZW8iFF/0 Ugze3HN3EIKmwVJeOvHj/eQvx8ml5KiHZF0CxDEJLJrECt5KDDMQor3WHCE3584v9TAd AeM8NjhvicRIT5LOsC3V8CKxm/txkLOMzIvCW3waOjQSYO2WeA3WTy6rFNo3H++59xFM 9vQxx5RyVxkHkijkPcv0t0+oagofyVa6jHTAjz8lRs61M3Mq/VF8PfxgQmvJa5CSH28w +xY00+UvqVKy3IZ9IVXVzipBhgir9PQZGDtpoMeVAa7TXPfK/G+u7Vq38CArfXlVeGxN EjOw== X-Gm-Message-State: AMCzsaVVt2Ht9BDlU8cSNU8jLtNDpyi9ByUaVmhJRnxQ9pZxoNoTbAWO lEtnY+mJnv9IdN3anuMPcYE4/kwB X-Google-Smtp-Source: ABhQp+Q9LEeT3czXkSb/g17NILX516a5QJP/tUj5mEx7RQ1rtivqurCz0QgnfShM+70ZjnqYdcekuQ== X-Received: by 10.28.17.7 with SMTP id 7mr4427921wmr.66.1508746989844; Mon, 23 Oct 2017 01:23:09 -0700 (PDT) Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id o11sm5320151wrg.5.2017.10.23.01.23.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 23 Oct 2017 01:23:08 -0700 (PDT) From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> Date: Mon, 23 Oct 2017 09:23:05 +0100 In-Reply-To: (Dmitry Gutov's message of "Mon, 23 Oct 2017 05:06:37 +0300") Message-ID: <87lgk22ryu.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dmitry Gutov writes: > You are working on something that I agree is a real problem, but doing > this would effectively revert commit > 5698947ff9335cf150c73cca257a5e7e5951b045, which was based on a > previous discussion (see the link in the commit message), and in > particular, would bring back "disappearing *xref* buffer problem", as > Eli put it. > [...] > > I have a rough idea on how to fix the situation, but nothing even > close to an implementation. > Thanks for the pointer. After I read that discussion I will probably ask you about that. >> emacs -Q >> C-x 3 [split-window-right] >> C-x 2 [split-window-below] >> M-. xref-backend-definitions RET [xref-find-definitions] >> C-n [next-line] >> RET [xref-goto-xref] >> >> Expected the definition to be found in the original window where I >> pressed M-. but instead it was found in another. Another case: >> >> emacs -Q >> C-x 4 . xref-backend-definitions RET [xref-find-definitions-other-wi= ndow] >> C-n >> RET >> >> Expected the definition to be found in some other window, different from >> the one I pressed M-. on. Instead went to the same one. > > With your patches applied, this example pops a new frame for me if I > press 'n' instead of 'C-n'. This is not hugely important in the light > of the larger problems above, but demonstrated difficulties with > window management when we try to pretend that the xref buffer "was > never there". You are absolutely right (and you don't have to tell me how hairy window-management code is). This particular problem, which I had also noticed, slipped through. I have a fix attached as a patch.=20 The cause of this problem is that split-window-sensibly refuses to split a window whose dimensions are below those of split-height-threshold and split-width-threshold. The reason you don't see frames popping up every time you do C-x 4 b on a small frame is that this function contains a safety net for these cases: if the window to be split is the only one available in the frame, it disregards the dimension threshholds and splits anyway. The attached window.el patch is a correct way to generalize this to account for dedicated windows. If this is not accepted this local fix in xref.el will also work fine. @@ -504,7 +504,8 @@ xref--show-location (t (save-selected-window (xref--with-dedicated-window - (xref--show-pos-in-buf marker buf)))))) + (let ((split-height-threshold 0)) + (xref--show-pos-in-buf marker buf))))))) (user-error (message (error-message-string err))))) =20=20=20=20 (defun xref-show-location-at-point () >> Also, in both >> situations, expected the window configuration to be the same as if I had >> searched for, say xref-backend-functions. >> >> This is fixed by the patches that I reattach after minor tweaks. The >> general idea is to have the *xref*, whose sudden appearance is hard to >> predict, obtrude as little as possible on the user's window >> configuration.p > > If we don't bring back the "disappearing *xref* buffer problem", > *xref* has to stay obtrusive. Do you think the rest of your patch will > make sense with that change? 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. Jo=C3=A3o --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0003-Allow-split-window-sensibly-to-split-threshold-in-fu.patch >From 47480926f328db5d840ba518125e0866d29f8665 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Mon, 23 Oct 2017 09:05:32 +0100 Subject: [PATCH 3/3] Allow split-window-sensibly to split threshold in further edge case As a fallback, and to avoid creating a frame, split-window-sensibly would previously disregard split-height-threshold if the window to be split is the frame's root window. This change slightly expands on that: it disregards the threshold if the window to be split is the frame's only usable window (it is either the only one, as before, or all the other windows are dedicated to some buffer and thus cannot be touched). * lisp/window.el (split-height-threshold): Adjust doc to match split-window-sensibly. (split-window-sensibly): Also disregard threshold if all other windows are dedicated. --- lisp/window.el | 33 ++++++++++++++++++++++----------- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/lisp/window.el b/lisp/window.el index 5ba9a305f9..21271944c0 100644 --- a/lisp/window.el +++ b/lisp/window.el @@ -6449,8 +6449,9 @@ split-height-threshold vertically only if it has at least this many lines. If this is nil, `split-window-sensibly' is not allowed to split a window vertically. If, however, a window is the only window on its -frame, `split-window-sensibly' may split it vertically -disregarding the value of this variable." +frame, or all the other ones are dedicated, +`split-window-sensibly' may split it vertically disregarding the +value of this variable." :type '(choice (const nil) (integer :tag "lines")) :version "23.1" :group 'windows) @@ -6557,15 +6558,25 @@ split-window-sensibly ;; Split window horizontally. (with-selected-window window (split-window-right))) - (and (eq window (frame-root-window (window-frame window))) - (not (window-minibuffer-p window)) - ;; If WINDOW is the only window on its frame and is not the - ;; minibuffer window, try to split it vertically disregarding - ;; the value of `split-height-threshold'. - (let ((split-height-threshold 0)) - (when (window-splittable-p window) - (with-selected-window window - (split-window-below)))))))) + (and + (let ((frame (window-frame window))) + (or + (eq window (frame-root-window frame)) + (let ((windows (delete window (window-list frame))) + w) + (while (and (setq w (pop windows)) + (window-dedicated-p w))) + (not windows)))) + (not (window-minibuffer-p window)) + ;; If WINDOW is the only usable window on its frame (it is + ;; the only one or,not being the only one, all the other ones + ;; are dedicated) and is not the minibuffer window, try to + ;; split it vertically disregarding the value of + ;; `split-height-threshold'. + (let ((split-height-threshold 0)) + (when (window-splittable-p window) + (with-selected-window window + (split-window-below)))))))) (defun window--try-to-split-window (window &optional alist) "Try to split WINDOW. -- 2.14.2 --=-=-=-- From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) 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: Mon, 23 Oct 2017 20:05: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 To: Dmitry Gutov Cc: eliz@gnu.org, 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150878904826290 (code B ref 28814); Mon, 23 Oct 2017 20:05:02 +0000 Received: (at 28814) by debbugs.gnu.org; 23 Oct 2017 20:04:08 +0000 Received: from localhost ([127.0.0.1]:58035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e6ixD-0006px-9S for submit@debbugs.gnu.org; Mon, 23 Oct 2017 16:04:08 -0400 Received: from mail-wr0-f172.google.com ([209.85.128.172]:56300) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e6ixA-0006pR-Jn for 28814@debbugs.gnu.org; Mon, 23 Oct 2017 16:04:05 -0400 Received: by mail-wr0-f172.google.com with SMTP id l8so5711320wre.12 for <28814@debbugs.gnu.org>; Mon, 23 Oct 2017 13:04:04 -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; bh=15e5XEV9p9vhUBtyDenLe0Z9ptpKwyAs0k68T9IW/yA=; b=j425lr4CvU9Ebb5wt2zBKOIdru5SKZzEm4rDtg+FQ2VG7s5O3SR4CYn9UHJFt4CPfC vH180oGitGEMuHhfXN2UH+kyaJu1LW07ZUP3ro+Rj8XJ82+4HCUCZPlCneflyJFiXQZG N5mggKm7+AOcvVS+uM+ajk9jcIXKUq8USFOcG9aLDJlzNMknKt2G9/WmGaT0B5Is0wlJ U8JoDTno/enLp6G0OnVhJAruQawA9RecfAi5M3fnLzbgeb3GYmZ/2EM3ScT5hih8EI2G GIN1qTtBiI4woDjhvmap+Ko6c6WKkLjvMu70rFI8ZW+7lmuI+uihKpFKm5amvpVaMqIz TQDQ== 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; bh=15e5XEV9p9vhUBtyDenLe0Z9ptpKwyAs0k68T9IW/yA=; b=OXA9XAaIqc+3b8zhMlnq0mSbO/GZE7ScqvrHunIzK1WiEFf6dx5/OvQZr7Eri28TjW AoJqgQYAz+nGjO+EeZe1UUCpT4G1QVr+BFxEAqJh6dCwSl+lo2RFL+JItahBOvYgPhVi E15A4oGqucq1Ac+Hsy1ycdmixilbtFK4s7Y9VuOE1NsmgLwjIK/33JZFCDVxI2eyE6M4 ZUbOBewdBNw+1Tq+XpOVlAwmt3lQSA7Dbdwt8gamOPBsgbGU23zlpsCT7ST4gytJ3cpR LkS5q737JTS1Ps2Y6GCNOJK6UOPLPRLbjHL+2b9vKYmcshfpezOk+qOGfd3NsK3GdGO7 4H1Q== X-Gm-Message-State: AMCzsaUtxOVkHVDuNGVetr+Ee6q0wyXZXx5frSaVc0QC9kMd29u1ET4K fUMOmc7UNUFOZSMRRw8zA+o= X-Google-Smtp-Source: ABhQp+TsMdLGUi6rDBXPcIYbhfxpFGdknwPrD4n7Mm7rVAoNv7Q3xaqOuwOEc8YN1g09dla1NEzpow== X-Received: by 10.223.135.197 with SMTP id c5mr10879239wrc.183.1508789038912; Mon, 23 Oct 2017 13:03:58 -0700 (PDT) Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id f27sm16907282wrf.63.2017.10.23.13.03.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 23 Oct 2017 13:03:57 -0700 (PDT) From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> Date: Mon, 23 Oct 2017 21:03:55 +0100 In-Reply-To: <87lgk22ryu.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Mon, 23 Oct 2017 09:23:05 +0100") Message-ID: <87fua91vis.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.8 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dmitry, Eli, 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. The second patch does indeed bring the problem known as "the disappearing *xref* problem", so I mended that with a very simple fourth patch, described below. So now, to summarize, there are 4 patches in total, that I reattach: * 0001-Honor-window-switching-intents-in-xref-find-definiti.patch This fixes the problem with the non-deterministic behaviour of selecting a window for displaying cross-references, as well the problem where the initial window/frame switching intent is lost. * 0002-Quit-the-xref-window-if-user-decides-to-go-to-a-ref.patch This makes the xref buffer non-obstrusive by quitting it on xref-goto-xref. This is a change to a current behaviour that was specifically requested by Eli (the "the disappearing *xref* problem"). * 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. 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. * 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. Jo=C3=A3o --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Honor-window-switching-intents-in-xref-find-definiti.patch >From 1b760816ac8886313996c635ee1cf696b937c20e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Fri, 13 Oct 2017 15:13:14 +0100 Subject: [PATCH 1/4] Honor window-switching intents in xref-find-definitions When there is more than one xref to jump to, and an *xref* window appears to help the user choose, the original intent to open a definition another window or frame is remembered when the choice to go to or show a reference is finally made. * lisp/progmodes/xref.el (xref--show-pos-in-buf): Rewrite. (xref--original-window-intent): New variable. (xref--original-window): Rename from xref--window and move up here for clarity. (xref--show-pos-in-buf): Rewrite. Don't take SELECT arg here. (xref--show-location): Handle window selection decision here. (xref--window): Rename to xref--original-window. (xref-show-location-at-point): Don't attempt window management here. (xref--show-xrefs): Ensure display-action intent is saved. --- lisp/progmodes/xref.el | 69 +++++++++++++++++++++++++++++++++++--------------- 1 file changed, 48 insertions(+), 21 deletions(-) diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 80cdcb3f18..c3e7982205 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -449,43 +449,68 @@ xref--with-dedicated-window (when xref-w (set-window-dedicated-p xref-w xref-w-dedicated))))) -(defun xref--show-pos-in-buf (pos buf select) - (let ((xref-buf (current-buffer)) - win) +(defvar-local xref--original-window-intent nil + "Original window-switching intent before xref buffer creation.") + +(defvar-local xref--original-window nil + "The original window this xref buffer was created from.") + +(defun xref--show-pos-in-buf (pos buf) + "Goto and display position POS of buffer BUF in a window. +Honour `xref--original-window-intent', run `xref-after-jump-hook' +and finally return the window." + (let* ((xref-buf (current-buffer)) + (pop-up-frames + (or (eq xref--original-window-intent 'frame) + pop-up-frames)) + (action + (cond ((memq + xref--original-window-intent + '(window frame)) + t) + ((and + (window-live-p xref--original-window) + (or (not (window-dedicated-p xref--original-window)) + (eq (window-buffer xref--original-window) buf))) + `(,(lambda (buf _alist) + (set-window-buffer xref--original-window buf) + xref--original-window)))))) (with-selected-window - (xref--with-dedicated-window - (display-buffer buf)) + (with-selected-window + ;; Just before `display-buffer', place ourselves in the + ;; original window to suggest preserving it. Of course, if + ;; user has deleted the original window, all bets are off, + ;; just use the selected one. + (or (and (window-live-p xref--original-window) + xref--original-window) + (selected-window)) + (display-buffer buf action)) (xref--goto-char pos) (run-hooks 'xref-after-jump-hook) (let ((buf (current-buffer))) - (setq win (selected-window)) (with-current-buffer xref-buf - (setq-local other-window-scroll-buffer buf)))) - (when select - (select-window win)))) + (setq-local other-window-scroll-buffer buf))) + (selected-window)))) (defun xref--show-location (location &optional select) (condition-case err (let* ((marker (xref-location-marker location)) (buf (marker-buffer marker))) - (xref--show-pos-in-buf marker buf select)) + (cond (select + (select-window (xref--show-pos-in-buf marker buf))) + (t + (save-selected-window + (xref--with-dedicated-window + (xref--show-pos-in-buf marker buf)))))) (user-error (message (error-message-string err))))) -(defvar-local xref--window nil - "The original window this xref buffer was created from.") - (defun xref-show-location-at-point () "Display the source of xref at point in the appropriate window, if any." (interactive) (let* ((xref (xref--item-at-point)) (xref--current-item xref)) (when xref - ;; Try to avoid the window the current xref buffer was - ;; originally created from. - (if (window-live-p xref--window) - (with-selected-window xref--window - (xref--show-location (xref-item-location xref))) - (xref--show-location (xref-item-location xref)))))) + (xref--show-location (xref-item-location xref))))) (defun xref-next-line () "Move to the next xref and display its source in the appropriate window." @@ -727,7 +752,8 @@ xref--show-xref-buffer (xref--xref-buffer-mode) (pop-to-buffer (current-buffer)) (goto-char (point-min)) - (setq xref--window (assoc-default 'window alist)) + (setq xref--original-window (assoc-default 'window alist) + xref--original-window-intent (assoc-default 'display-action alist)) (current-buffer))))) @@ -754,7 +780,8 @@ xref--show-xrefs (t (xref-push-marker-stack) (funcall xref-show-xrefs-function xrefs - `((window . ,(selected-window))))))) + `((window . ,(selected-window)) + (display-action . ,display-action)))))) (defun xref--prompt-p (command) (or (eq xref-prompt-for-identifier t) -- 2.14.2 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0002-Quit-the-xref-window-if-user-decides-to-go-to-a-ref.patch >From 9feaf473479dcd8edcf2c0bb14044995abb5eeb0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Fri, 13 Oct 2017 16:37:47 +0100 Subject: [PATCH 2/4] Quit the *xref* window if user decides to go to a ref The idea is to have this window, whose sudden appearance is hard to predict, obtrude as little as possible on the user's window configuration. * lisp/progmodes/xref.el (xref--show-location): When SELECT is t, quit window. --- lisp/progmodes/xref.el | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index c3e7982205..cf9e027ba0 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -495,9 +495,12 @@ xref--show-pos-in-buf (defun xref--show-location (location &optional select) (condition-case err (let* ((marker (xref-location-marker location)) - (buf (marker-buffer marker))) + (buf (marker-buffer marker)) + (xref-buffer (current-buffer))) (cond (select - (select-window (xref--show-pos-in-buf marker buf))) + (quit-window nil nil) + (with-current-buffer xref-buffer + (select-window (xref--show-pos-in-buf marker buf)))) (t (save-selected-window (xref--with-dedicated-window -- 2.14.2 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0003-Allow-split-window-sensibly-to-split-threshold-in-fu.patch >From 47480926f328db5d840ba518125e0866d29f8665 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Mon, 23 Oct 2017 09:05:32 +0100 Subject: [PATCH 3/4] Allow split-window-sensibly to split threshold in further edge case As a fallback, and to avoid creating a frame, split-window-sensibly would previously disregard split-height-threshold if the window to be split is the frame's root window. This change slightly expands on that: it disregards the threshold if the window to be split is the frame's only usable window (it is either the only one, as before, or all the other windows are dedicated to some buffer and thus cannot be touched). * lisp/window.el (split-height-threshold): Adjust doc to match split-window-sensibly. (split-window-sensibly): Also disregard threshold if all other windows are dedicated. --- lisp/window.el | 33 ++++++++++++++++++++++----------- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/lisp/window.el b/lisp/window.el index 5ba9a305f9..21271944c0 100644 --- a/lisp/window.el +++ b/lisp/window.el @@ -6449,8 +6449,9 @@ split-height-threshold vertically only if it has at least this many lines. If this is nil, `split-window-sensibly' is not allowed to split a window vertically. If, however, a window is the only window on its -frame, `split-window-sensibly' may split it vertically -disregarding the value of this variable." +frame, or all the other ones are dedicated, +`split-window-sensibly' may split it vertically disregarding the +value of this variable." :type '(choice (const nil) (integer :tag "lines")) :version "23.1" :group 'windows) @@ -6557,15 +6558,25 @@ split-window-sensibly ;; Split window horizontally. (with-selected-window window (split-window-right))) - (and (eq window (frame-root-window (window-frame window))) - (not (window-minibuffer-p window)) - ;; If WINDOW is the only window on its frame and is not the - ;; minibuffer window, try to split it vertically disregarding - ;; the value of `split-height-threshold'. - (let ((split-height-threshold 0)) - (when (window-splittable-p window) - (with-selected-window window - (split-window-below)))))))) + (and + (let ((frame (window-frame window))) + (or + (eq window (frame-root-window frame)) + (let ((windows (delete window (window-list frame))) + w) + (while (and (setq w (pop windows)) + (window-dedicated-p w))) + (not windows)))) + (not (window-minibuffer-p window)) + ;; If WINDOW is the only usable window on its frame (it is + ;; the only one or,not being the only one, all the other ones + ;; are dedicated) and is not the minibuffer window, try to + ;; split it vertically disregarding the value of + ;; `split-height-threshold'. + (let ((split-height-threshold 0)) + (when (window-splittable-p window) + (with-selected-window window + (split-window-below)))))))) (defun window--try-to-split-window (window &optional alist) "Try to split WINDOW. -- 2.14.2 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0004-Don-t-quit-xref-window-on-RET-only-on-C-u-RET.patch >From 1b527b10ad44ee4863e87700fb50dcfda14c72f5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Mon, 23 Oct 2017 20:51:54 +0100 Subject: [PATCH 4/4] Don't quit *xref* window on RET, only on C-u RET * lisp/progmodes/xref.el (xref--show-location): Handle new 'quit value for SELECT. (xref-goto-xref): Allow prefix argument. --- lisp/progmodes/xref.el | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index cf9e027ba0..9dc78397eb 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -493,12 +493,15 @@ xref--show-pos-in-buf (selected-window)))) (defun xref--show-location (location &optional select) + "Helper for `xref-show-xref' and `xref-goto-xref'. +Go to LOCATION and if SELECT is non-nil select its window. If +SELECT is `quit', also quit the *xref* window." (condition-case err (let* ((marker (xref-location-marker location)) (buf (marker-buffer marker)) (xref-buffer (current-buffer))) (cond (select - (quit-window nil nil) + (if (eq select 'quit) (quit-window nil nil)) (with-current-buffer xref-buffer (select-window (xref--show-pos-in-buf marker buf)))) (t @@ -532,12 +535,13 @@ xref--item-at-point (back-to-indentation) (get-text-property (point) 'xref-item))) -(defun xref-goto-xref () - "Jump to the xref on the current line and select its window." - (interactive) +(defun xref-goto-xref (&optional quit) + "Jump to the xref on the current line and select its window. +With QUIT (the prefix argument) also quit the *xref* window." + (interactive "P") (let ((xref (or (xref--item-at-point) (user-error "No reference at point")))) - (xref--show-location (xref-item-location xref) t))) + (xref--show-location (xref-item-location xref) (if quit 'quit t)))) (defun xref-query-replace-in-results (from to) "Perform interactive replacement of FROM with TO in all displayed xrefs. -- 2.14.2 --=-=-=-- From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Oct 2017 00:09: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 To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150889008715328 (code B ref 28814); Wed, 25 Oct 2017 00:09:02 +0000 Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 00:08:07 +0000 Received: from localhost ([127.0.0.1]:60422 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e79Es-0003zA-Pw for submit@debbugs.gnu.org; Tue, 24 Oct 2017 20:08:07 -0400 Received: from mail-wr0-f169.google.com ([209.85.128.169]:47004) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e79Eq-0003yg-Ry for 28814@debbugs.gnu.org; Tue, 24 Oct 2017 20:08:05 -0400 Received: by mail-wr0-f169.google.com with SMTP id l1so22312317wrc.3 for <28814@debbugs.gnu.org>; Tue, 24 Oct 2017 17:08:04 -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=Ewe8F0WB89CB/5h84RtcYJs0lOMpx9L2CccZmF+q5sY=; b=bibP/ATImrkapvL7KyLQN2rGhIReedJjmYCBQ4IRwaDp9vXaKUlSyC6ILnMCVq/qSh 3zpEk14aUUSqcjNacHTR6pbT0OW6eWUqV/OtsfDdBF9uc/BNDnqqNG0LkiHNo5weCFzW edX/K3IqfNC7Dfb+FP8z84scROoroNj/i/6Y+GHJr/brrB9pyyIzjL7IagtWfzYMwTRK V0arKqTofgKsqexTg8molgqgcVC/e7ZbT/EUMPnotkV5T14eclQu0AG+1okfTBbifyyQ 9uDj7sy2He18KzDN9VIxzdfK0Gz2/S4By9ulOA1kR+a5ULbok3yXER1AuDlU+LjmJDmK RVLA== 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=Ewe8F0WB89CB/5h84RtcYJs0lOMpx9L2CccZmF+q5sY=; b=owHVMjliML2HZnBIMM/jDrBKXGUy9BN6Qrv3q5/2FEXJYamHJAh9Wi2C6aNjT1U70Z PLF6Pkq78216AgnqDNjXsXeifvm17YhOLOI9400/SKEwI19NnIbYjMdJ17gaK2OKjHp+ fR71Km4Wq72BrsIWZF6uGvPZ7jYU6ygXJcL3Q9OkYFBg68AMC8BNFl0PeA2Vh8hiMmdl S5Hb1JS3mrHcUbIq94wYl5nWlorlaAG1sr+3UOr8+AgZEOAtNU/zJ4+tJmI8CFVp518u pqwdM00ZDSwVZ/kFAEK4A9fn7A634fDmpvJwzNQp0QyOGYN8qNdxQLOljk5LlSx6nrZg 4q9Q== X-Gm-Message-State: AMCzsaVHq4bqeZ9badp9AIl0oP1pJxyZbNHLelZybfsanvKsZOMCB7/j PjVJLQ/2Ak52ffP44vEJeIN/DjbA X-Google-Smtp-Source: ABhQp+TOlmowqZvPlV7Cms+UMuB1q8VZAQfGwN4U//UU0YBxuLYJJm99qemswqOl4HEYrhsxBteGXQ== X-Received: by 10.223.176.82 with SMTP id g18mr251677wra.234.1508890078898; Tue, 24 Oct 2017 17:07:58 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id 12sm411666wmy.46.2017.10.24.17.07.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 17:07:57 -0700 (PDT) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> From: Dmitry Gutov Message-ID: Date: Wed, 25 Oct 2017 03:07:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <87lgk22ryu.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) On 10/23/17 11:23 AM, João Távora wrote: > The cause of this problem is that split-window-sensibly refuses to split > a window whose dimensions are below those of split-height-threshold and > split-width-threshold. The reason you don't see frames popping up every > time you do C-x 4 b on a small frame is that this function contains a > safety net for these cases: if the window to be split is the only one > available in the frame, it disregards the dimension threshholds and > splits anyway. The attached window.el patch is a correct way to > generalize this to account for dedicated windows. 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". This stuff is difficult, and personally I don't like either of the easily reachable solutions. > 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. 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. From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) 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 To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: eliz@gnu.org, 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150889110817079 (code B ref 28814); Wed, 25 Oct 2017 00:26:01 +0000 Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 00:25:08 +0000 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 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 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) 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) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> From: Dmitry Gutov Message-ID: <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> Date: Wed, 25 Oct 2017 03:24:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <87fua91vis.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) 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. From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) 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 To: Dmitry Gutov Cc: eliz@gnu.org, 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150891744812609 (code B ref 28814); Wed, 25 Oct 2017 07:45:02 +0000 Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 07:44:08 +0000 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 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 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) 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) From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> Date: Wed, 25 Oct 2017 08:43:57 +0100 In-Reply-To: <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> (Dmitry Gutov's message of "Wed, 25 Oct 2017 03:24:58 +0300") Message-ID: <87y3nzu0xu.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) 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 From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Oct 2017 07:47: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 To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Dmitry Gutov Cc: 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150891758412878 (code B ref 28814); Wed, 25 Oct 2017 07:47:02 +0000 Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 07:46:24 +0000 Received: from localhost ([127.0.0.1]:60630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7GOO-0003Le-Fp for submit@debbugs.gnu.org; Wed, 25 Oct 2017 03:46:24 -0400 Received: from mout.gmx.net ([212.227.15.15]:60190) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7GOM-0003LK-TY for 28814@debbugs.gnu.org; Wed, 25 Oct 2017 03:46:23 -0400 Received: from [192.168.1.100] ([46.125.249.113]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MD9J6-1dxQdY2RBs-00GUyn; Wed, 25 Oct 2017 09:46:16 +0200 Message-ID: <59F0413F.8010100@gmx.at> Date: Wed, 25 Oct 2017 09:46:07 +0200 From: martin rudalics MIME-Version: 1.0 References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> In-Reply-To: <87fua91vis.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:EPJuEpxwa+9i3ffcl+xQKuCsC27ZMaN2ZW4MSBiK06tHGDeekM1 LsDBtOp6Y+rTGGdOvl5tPCWu8VQhOSe1J+lvbFaa4hWYjQLSgC/HRpKspFI/dm+HRKq7+Cy KVjjC9vgJP5lJvNFGiYQ+Av+1Yt11K6ur1G5u/ZrS5/1yb6yENYkJAhAGAg2M3ecGlOCzes HZAaoDgAVjGGMmqWrRLYA== X-UI-Out-Filterresults: notjunk:1;V01:K0:PFpdJMHMFAY=:2rQOdaQH7bZBOxTH2eIrmQ mAqpZJglpYvGBGAx0Fu1BI9qG0fbWzuCbHhVM8Se0XvFJKZhaE08aWny7KycdWJ3WqojtnpBQ ds3jL59hyuYfRsT0H92tdRjP86UoSThq66L0f4yEWFAMyDubxBqAux8r8c520V//KT3Ysa6m1 j69KwGIxTpNQAVKxRAzKcpjwyOTU226g5g+k4c/od09UloYOYyN0ZVK0w/6tQ5p13n1uaGEVS ytP7RpmycFtTla0LNmOEP3+Hc0qWMY4AU+bsys1XAlf0KTt+p9vqakzcn8By6lECkg8h+exgQ DHlpx3Lzf3oGbmOe7PbzIJk50RixoZuMkUb+vsVL81jIQwj3HnJf7u+MjNcwF5dXuPEPK3Wjl c7aEr/loh90pYJiuJuHV21aIiFS7b/QXnyv3+0Z+aw5uCnzHV0+PvoW81+ex9cT8wZ397tt5Z t5pRe62CedVUynAASz8hyDJE/UxRXTCEBO6YsBbX8eUyw2BGbKcddyubTQL2kJauNp3WKGJhO y/sF5YGug6inoyvOmxYfMKPtHEQnhsdkXk6R/ImyKOeCCOklZP5VMuiEOdFPbybjN7oMN3QD6 znhV2LFNc7Crm6UQQxht9uxEm0EEcMxhztKSc7iOS94f0TDqaxwjRHbt175HveqrXrorawzex YpdUSjpIn6+AycOxtgZwANI4WnhNJc8zvmhFM5hIARQsiAUELRUyPl3laO6rXw0EtPgkxypKz YQQA/mWmkYqKslCg58QDGIDZTifPWURPGMs2GUi8pQVT8FwXMWDWICYpQy1wemRWhhGO+2fRj 9IrnhrovIFf2BYAkortzFcDNqEIjVk2QYR2yRA1nN6OWRUqA+61PIzEw2C7r1DXAOujpZeL X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > * 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. Maybe the new behavior should be made customizable but this is for users of dedicated windows to decide. In either case, instead of constructing =E2=80=98window-list=E2=80=99 please consider using =E2=80=98walk-window-= tree=E2=80=99 for that part + (let ((windows (delete window (window-list frame))) + w) + (while (and (setq w (pop windows)) + (window-dedicated-p w))) + (not windows)))) Thank you, martin From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Oct 2017 10:25: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 To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: eliz@gnu.org, 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150892705429182 (code B ref 28814); Wed, 25 Oct 2017 10:25:01 +0000 Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 10:24:14 +0000 Received: from localhost ([127.0.0.1]:60664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7Ir7-0007ab-On for submit@debbugs.gnu.org; Wed, 25 Oct 2017 06:24:14 -0400 Received: from mail-wm0-f43.google.com ([74.125.82.43]:55271) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7Ir4-0007aH-Sb for 28814@debbugs.gnu.org; Wed, 25 Oct 2017 06:24:11 -0400 Received: by mail-wm0-f43.google.com with SMTP id r68so910582wmr.3 for <28814@debbugs.gnu.org>; Wed, 25 Oct 2017 03:24:10 -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=0YWWuZKPDOpFWLUZRAnf9X2Ig36dHV7wKTY20gc/qVA=; b=CiJkhIgaxqMd6Rr6a+L5xfVEGofGQb0yemdsumDYe4kvgrv6Nr44WnioLEYlqwpEGY XHX0D8vsQ/BzEH58ibofL/UbMJNta1QGJWchQRNv90XpceqkVc8b+QARXkVvIQaY/vXQ XDAks0QFo9teipfqfrM6lzCHOL+wAAWVqzgC95aoSMXOPVjfpjNleUj3f+O41NsRMKu5 3G5bwznw2xNdZInlbaIc91vb8q5sORRkgYkKxj6KJna8JYQMaAsytqKoONIAM7CI29v0 8QzGmb0oJAstp/mDwp3LotSjYUFyz/r16EnxxaBmsxa8k1ICEKQ3IkL+AYi8xcUYI3tV 7n8g== 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=0YWWuZKPDOpFWLUZRAnf9X2Ig36dHV7wKTY20gc/qVA=; b=TRGOs+XB/se5FkLc2rP76ZkwXdA1ih7IZd1simph94vdCJyIZ3VETz47PEmGw6POGs O30gmJXcwus2X6Ihjq20SBED+5vSlTgRLciVNHym0TlWyFJTQr7XZiO+mIm2Irz66mbi qmtbOAU7oGABJ6naWtJ7hhtE+gVkh5n3I2rS571P1gCnBeG/RVNyw8LHDNgNVT3fX+Ib 4gAS1Emdp7A4o0j/Ec3ciOSJDA9ibbK4yOebOoKeT0EM0BiNnB1jQhQozp30hX98a+az GEdwebrgBWGNiT/ESbJRHZP72fpwNRCRoYlAvqeiE4YYgkamO071KMVkS3PhWLHslP6W nqmQ== X-Gm-Message-State: AMCzsaW48UxE4tRXSIfW+PeANLTL1RmdrLZBiGwjyZ1DzIBbv+RjRkq7 eToBqI12WJKAXS5vuTW717jeHKWi X-Google-Smtp-Source: ABhQp+SzIH750Ej1AJpY7UZ/MtyE6nTfmVs49jEybZ3icCbFU+If2nkciqMJuwunkZlKAhq80LpD8w== X-Received: by 10.80.186.29 with SMTP id g29mr19551593edc.206.1508927044812; Wed, 25 Oct 2017 03:24:04 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id s6sm1688154edc.2.2017.10.25.03.24.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Oct 2017 03:24:03 -0700 (PDT) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <87y3nzu0xu.fsf@gmail.com> From: Dmitry Gutov Message-ID: <4b46c989-f94e-a5ce-9264-069c34096419@yandex.ru> Date: Wed, 25 Oct 2017 13:24:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <87y3nzu0xu.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) On 10/25/17 10:43 AM, João Távora wrote: >> 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’t think it’s that bad if a tiny window pops up, considering: Yeah, maybe it's not too bad. Like I said, no strong objections. > I see, there’s prior art here. You approach is much more ambitious than > mine and given the hairiness of window code, it’s no wonder it didn’t > work well, if you will excuse the hindsight 20/20 :-) It would have given a more consistent mental model, though. And it's something that corresponds to some users expectations already. Think Ctrl-P or "Goto Definition" preview in Sublime Text. You can look at the destinations and pick one, or not pick anything, and the tabs list would be intact. > If it helps, this itch didn’t pop out of thin air: as you know, xref.el > is lifted from SLIME’s UI. SLY, my fork of SLIME, does the same, and a > user complained about SLY’s use of popup windows in a way that finally > convinced me. See https://github.com/joaotavora/sly/issues/121 I agree that it might be a step forward, and help you retain some main aspects of behavior that the users are accustomed to. I just wish it was a step toward a more well-rounded UI. >> 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. Good. >> 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’s a bit odd indeed, but I had no idea of any kind of rule or > policy in that direction. If we don't, maybe we should. Consistency in the way modes work is a good thing, and allows the user to adapt to each of them much quicker. Not to mention having to keep the effects of different bindings in memory (both muscle and cranial). > Anyway, In the thread you pointed me to, there was talk of an ’a’ > command but I never saw it. It was some hypothetical > xref-quit-and-goto-xref. I’m perfectly fine with implementing that > instead. But 'a' (correct me if I'm wrong) normally replaces a buffer in the *current* window. And kill the previous buffer. > Of course my priority goes towards RET doing xref-quit-and-goto-xref and > something else doing xref-goto-xref. If that default isn’t changed, I’ll > probably to that remap in my init file.. So you'd always use "something else" to navigate to project-find-regexp search results? From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) 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 13:20: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 To: martin rudalics Cc: 28814@debbugs.gnu.org, Dmitry Gutov Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150893757922962 (code B ref 28814); Wed, 25 Oct 2017 13:20:02 +0000 Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 13:19:39 +0000 Received: from localhost ([127.0.0.1]:60751 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7Lat-0005yI-Cc for submit@debbugs.gnu.org; Wed, 25 Oct 2017 09:19:39 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:44197) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7Lar-0005y0-3J for 28814@debbugs.gnu.org; Wed, 25 Oct 2017 09:19:37 -0400 Received: by mail-wr0-f196.google.com with SMTP id z55so17944094wrz.1 for <28814@debbugs.gnu.org>; Wed, 25 Oct 2017 06:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version; bh=UCbpZ91cG27p1K4pfQowLXR9I5T2g+CxuYp3dZOZTUQ=; b=VHu81xtjMcM22c3UUK9J0+T9+D1twIavZNUDBdHcnJYAXUuiVz6tbRKd24/P7oPz60 QD6Ju6v8PkLJs5RXq1BaUVpPzeXWgZ8atiSqFXUlPxo8i2VF2QjVAK4luX1nrHKyJP6w 74+OSutdi6d/T60Mh6bypthv/5yoqSu9zA/ZgNaxTLW1qvsnXtI32ikTX1eWfC+MJDzU lIjQXKJTuaQhJdHJuusHFrCBRfx1+soOt6we5BftAOw9x6h4FRImGw3ZfA/Ch3vZtZ+O rhX/jhC0Sg01NMfx5OQRl17tfoeHkcdwxVBfID340hpNb1PfmEAdtcxlCnhrkpuk2pDP cclw== 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:in-reply-to:references :user-agent:date:message-id:mime-version; bh=UCbpZ91cG27p1K4pfQowLXR9I5T2g+CxuYp3dZOZTUQ=; b=ZoOHw0yWZ1E2cCQPCGhmwgB1GYu1UWtouZby+beHeDHBZZXouCHER0fhKwsSPhIhIL 9kvZ7x1p2MB2z9YnGN3kBfpp3WYaN7FS1HVR1VSe875RSduW0hqJ9LITNaT3Iy8NVBx1 lsiM969rIUhP4VwRpvo4kQIr/zz56h+024StDKUPHFHJc+fvyk1nCIBPfE2TyoQhuj7O qh1fen8RRKJ5ZMKxa2BxL7wTdid0ent59JYewfoZbfc9sCKlisHx8CxHR8OHdRaYO610 BuNJWQP8FFlKJtVc8vRZ263jv1x28IjunCLHKgFRgUbIWL/PjVwVGiH+nid2FUYvUw1F DybA== X-Gm-Message-State: AMCzsaWX8DIH8C07He18o+7UCJ2HahzBgUhvna4u25EpR2M3FI0EPyxl NXuQW3ZcBpuOoGyYU/xvDF6P0Rks X-Google-Smtp-Source: ABhQp+Shr0SIF/5pInN7Aq7F+70Z0AzetePFefoyd0FOtp2Wr0JCC+lhEzIZbKkNS7kH7Yh29uO/6g== X-Received: by 10.223.156.144 with SMTP id d16mr2291951wre.29.1508937570114; Wed, 25 Oct 2017 06:19:30 -0700 (PDT) Received: from lolita.yourcompany.com ([88.157.205.17]) by smtp.gmail.com with ESMTPSA id m26sm2683058wrb.81.2017.10.25.06.19.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 25 Oct 2017 06:19:29 -0700 (PDT) From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) In-Reply-To: <59F0413F.8010100@gmx.at> (martin rudalics's message of "Wed, 25 Oct 2017 09:46:07 +0200") References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <59F0413F.8010100@gmx.at> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) Date: Wed, 25 Oct 2017 14:19:26 +0100 Message-ID: <87wp3js6u9.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable martin rudalics writes: >> * 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. > > Maybe the new behavior should be made customizable but this is for users > of dedicated windows to decide. > Hmmm, adding a defcustom sounds a bit heavy-handed to me. We=E2=80=99re tal= king about adding an option to preserve the behaviour of a failure. The docstring would certainly be hard to phrase. Perhaps we could just wait for the (quite improbable in my opinion) complaints of dedicated window users that expected their split-window operations to fail in certain extreme situations hence causing (un)expected frames to pop up? > In either case, instead of constructing > =E2=80=98window-list=E2=80=99 please consider using =E2=80=98walk-window-= tree=E2=80=99 for that part Done. See attached patch. Jo=C3=A3o --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0003-Allow-split-window-sensibly-to-split-threshold-in-fu.patch >From eb1a0ce0c66502bee41c090afcb04c65271196a1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Mon, 23 Oct 2017 09:05:32 +0100 Subject: [PATCH 3/4] Allow split-window-sensibly to split threshold in further edge case As a fallback, and to avoid creating a frame, split-window-sensibly would previously disregard split-height-threshold if the window to be split is the frame's root window. This change slightly expands on that: it disregards the threshold if the window to be split is the frame's only usable window (it is either the only one, as before, or all the other windows are dedicated to some buffer and thus cannot be touched). * lisp/window.el (split-height-threshold): Adjust doc to match split-window-sensibly. (split-window-sensibly): Also disregard threshold if all other windows are dedicated. --- lisp/window.el | 35 ++++++++++++++++++++++++----------- 1 file changed, 24 insertions(+), 11 deletions(-) diff --git a/lisp/window.el b/lisp/window.el index c0a9ecd093..4814d12400 100644 --- a/lisp/window.el +++ b/lisp/window.el @@ -6465,8 +6465,9 @@ split-height-threshold vertically only if it has at least this many lines. If this is nil, `split-window-sensibly' is not allowed to split a window vertically. If, however, a window is the only window on its -frame, `split-window-sensibly' may split it vertically -disregarding the value of this variable." +frame, or all the other ones are dedicated, +`split-window-sensibly' may split it vertically disregarding the +value of this variable." :type '(choice (const nil) (integer :tag "lines")) :version "23.1" :group 'windows) @@ -6573,15 +6574,27 @@ split-window-sensibly ;; Split window horizontally. (with-selected-window window (split-window-right))) - (and (eq window (frame-root-window (window-frame window))) - (not (window-minibuffer-p window)) - ;; If WINDOW is the only window on its frame and is not the - ;; minibuffer window, try to split it vertically disregarding - ;; the value of `split-height-threshold'. - (let ((split-height-threshold 0)) - (when (window-splittable-p window) - (with-selected-window window - (split-window-below)))))))) + (and + ;; If WINDOW is the only usable window on its frame (it is + ;; the only one or, not being the only one, all the other + ;; ones are dedicated) and is not the minibuffer window, try + ;; to split it vertically disregarding the value of + ;; `split-height-threshold'. + (let ((frame (window-frame window))) + (or + (eq window (frame-root-window frame)) + (catch 'done + (walk-window-tree (lambda (w) + (unless (or (eq w window) + (window-dedicated-p w)) + (throw 'done nil))) + frame) + t))) + (not (window-minibuffer-p window)) + (let ((split-height-threshold 0)) + (when (window-splittable-p window) + (with-selected-window window + (split-window-below)))))))) (defun window--try-to-split-window (window &optional alist) "Try to split WINDOW. -- 2.14.2 --=-=-=-- From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) 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 13:30: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 To: Dmitry Gutov Cc: eliz@gnu.org, 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150893819924005 (code B ref 28814); Wed, 25 Oct 2017 13:30:02 +0000 Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 13:29:59 +0000 Received: from localhost ([127.0.0.1]:60755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7Lkt-0006F7-E9 for submit@debbugs.gnu.org; Wed, 25 Oct 2017 09:29:59 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:46281) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7Lkr-0006Ep-BO for 28814@debbugs.gnu.org; Wed, 25 Oct 2017 09:29:57 -0400 Received: by mail-wr0-f196.google.com with SMTP id l1so24063662wrc.3 for <28814@debbugs.gnu.org>; Wed, 25 Oct 2017 06:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-transfer-encoding; bh=9EjWqV7oE6k5KZN89eVNyqDj1/iuah1RJyYiOEYfxbg=; b=XWgNvhi+lHzCGfClwjRbUKn+kF4iPxMhYo4k9KODJ7r/jFU5bmXmtKOuPf7t69YIxQ U09+Z4YjIashDDP52qhnncPR+2fGXtc4jgXWD+RuDKFv/r4i9gMHQUPkZpzwZ3HC+5zO 5FF4pZbUSpXp3G6natEXo76kQvG6MNk1W1TjxeLqJHLHNu3GqUvIWDeO+ka07Sf6Ha2V xvXESdR+zjhmWAy2lQ8OV8VL8TyMyM1X8yR2+9IN1F0OA6R0bzhvpQ6fZ3se1hSEKfeS ANMFYiZU+x4P55d6ErOH/FEZNliZkOA4DERCOWCRoFqU89ExlQXl4oVPsbxoyOu64y7f vewQ== 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:in-reply-to:references :user-agent:date:message-id:mime-version:content-transfer-encoding; bh=9EjWqV7oE6k5KZN89eVNyqDj1/iuah1RJyYiOEYfxbg=; b=S+AW0AVM1Cx5QxbPVZXNUEt8Nj8ScaWbWdxgi79N5cy2/7IU6YOX09kRhVKH3Lx8qr M6Nm53O1CZIcAJBnh1D/48JOW2hRCtudiRsI+8ScZZlKpVjsnoK9Nf5+34LzLEJyNbox JI9xa9E3ZnpXKFjDl05Lo8GNOBcOtqT/zOVCYES74j5UU3q317HDMDiKQ000PygdjliW sNQk4+wUMnSGD5LCqb9NpoflWPgQ80FlME37V5i25hl0FM0an2MnOqM8/XLLvnzNsfDL sekXPNWluejhaWWd2jtIXgxOIZu/DqDcfrWhiq8D54G7xNbxd1p/rYdQXKpiK2WRc8kr Wt6Q== X-Gm-Message-State: AMCzsaWXQoeGFeUoYEJ4FXs09QV4nqqkA27SjPP/1yWnS72ythta64ow RAwLPW8ar6YwzRH3xl8CtiM= X-Google-Smtp-Source: ABhQp+Q+Xj6zbeY2tsXl+aDSkov+KGNrHvReD0o+ou0govcLRh1pQd9BKpJtZUO1h7dljgzpgBQAHA== X-Received: by 10.223.133.242 with SMTP id 47mr2364248wru.170.1508938191677; Wed, 25 Oct 2017 06:29:51 -0700 (PDT) Received: from lolita.yourcompany.com ([88.157.205.17]) by smtp.gmail.com with ESMTPSA id w75sm2242558wmw.17.2017.10.25.06.29.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 25 Oct 2017 06:29:50 -0700 (PDT) From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) In-Reply-To: <4b46c989-f94e-a5ce-9264-069c34096419@yandex.ru> (Dmitry Gutov's message of "Wed, 25 Oct 2017 13:24:01 +0300") References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <87y3nzu0xu.fsf@gmail.com> <4b46c989-f94e-a5ce-9264-069c34096419@yandex.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) Date: Wed, 25 Oct 2017 14:29:45 +0100 Message-ID: <87o9ovs6d2.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Dmitry Gutov writes: > It would have given a more consistent mental model, though. And it's > something that corresponds to some users expectations already. > > Think Ctrl-P or "Goto Definition" preview in Sublime Text. You can > look at the destinations and pick one, or not pick anything, and the > tabs list would be intact. > ... > I agree that it might be a step forward, and help you retain some main > aspects of behavior that the users are accustomed to. I just wish it > was a step toward a more well-rounded UI. It seems you=E2=80=99re talking, in part, of the expectations of users comi= ng from more "modern" UI=E2=80=99s, like Sublime=E2=80=99s. I can understand t= hat argument, but I also argue that not drifting too much from the (twitchy, I=E2=80=99ll admit) window popping behavior of Emacs is useful in its own right. For example, I=E2=80=99d argue that Emacs users are almost universally used= to =E2=80=99C-h f/c/m=E2=80=99 stuff bringing up obtrusive windows that they c= an quit by typing =E2=80=99q=E2=80=99 and get back to their original configuration (pr= ovided, yes, that they don=E2=80=99t mess with the window configuration in the meantime). It=E2=80=99s the number one thing that annoyed me in my early Em= acs days, and I see a lot of people confused by it, until they learn how to =E2=80=99q=E2=80=99. Other examples are the default completion UI and the "= disabled command" interface. If that UI can be improved, it certainly should. (I have some very old ideas about a single window dedicated frame for help windows that could be discussed and developed). But whatever is done it should be done to Emacs as a whole, to preserve consistency. In the meantime, my xref patches try to stay close to the current paradigm. Additionally, they should benefit automatically from any future improvements. > But 'a' (correct me if I'm wrong) normally replaces a buffer in the > *current* window. And kill the previous buffer. I can=E2=80=99t correct you because I had no idea of that convention either= . I just mentioned =E2=80=99a=E2=80=99 because I read it somewhere in the discu= ssion. I=E2=80=99ll be fine with any key that means "yes I=E2=80=99ve really decided I want to = go here now take me there and bury this buffer". As a last resort, an unbound command that I can remap RET to, or a decent interface that allows me to write such a command. >> 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 chang= ed, I=E2=80=99ll >> probably to that remap in my init file.. > > So you'd always use "something else" to navigate to > project-find-regexp search results? No, I=E2=80=99d use "n" or "SPC". These work fine as always. When I find th= e one I want to edit, I press "RET". I=E2=80=99m a big boy, I can find the *xref* buffer again :-) From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Oct 2017 14:50: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 To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.15089429608066 (code B ref 28814); Wed, 25 Oct 2017 14:50:02 +0000 Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 14:49:20 +0000 Received: from localhost ([127.0.0.1]:33456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7Mzg-000261-HQ for submit@debbugs.gnu.org; Wed, 25 Oct 2017 10:49:20 -0400 Received: from mail-wm0-f47.google.com ([74.125.82.47]:53126) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7Mzf-00025n-DC for 28814@debbugs.gnu.org; Wed, 25 Oct 2017 10:49:19 -0400 Received: by mail-wm0-f47.google.com with SMTP id t139so2492937wmt.1 for <28814@debbugs.gnu.org>; Wed, 25 Oct 2017 07:49:19 -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=Y/FDrFKLdG1k+jYjlOZGCIaMc2gLZtfnYmZ0lH7zWA4=; b=MlMalzgn6/g1qntcGVhy0fWGfG6qqSJHBPIY+1XhUi3WX1Yuumvacr9mUFnsuCQpa1 Ph67uL7eURotD8gC3KJHdGLwoxqaTEIEp8KVgAJaHxA3cuK7u0jNFt8DEfRIreQkifPC b67YP9MCnKlCk6dwvnmxUvvVfAdrJ4aoOZnyoLrFZRpUlzLj9iJh+JWO+bXTrAdDqD+Q xNLRuWY1XczZKcmYozSAobueOqWFFUi4nU4HXqRF5kYKYCB4a59Gps5XuVMxub+aJ+iz Tcw5O46EcOCW1KA8rFkcgqL3Y4fP4zrMjQrOce4K7CRyjPYT9dU4/A7zwUJH66nBOA8G b9OA== 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=Y/FDrFKLdG1k+jYjlOZGCIaMc2gLZtfnYmZ0lH7zWA4=; b=X7rtlOKdS6GKpsTweV3elsElE75yZvwZCny0TQDv79fB/kSDN6KxHWMYOoysTjDar3 saQt1q63WuqTzaYwD+Al1o34Pkt9uTjPLUhGZC02JKNyk6vP2FKc8mJ/EQX+8Vy/q0OG lj1Lt7xg86jRhvv112I3Sl0DZwokyB/BNyG6rSIoimxDoS3KAeIEpOI0DoEdx/mChGVP yCaxWwiMDCHnho+cCwTnqWN2QRo9399iazBYTco6vU08KpMTUltoO50F+Tqsk76rTXnL 1iXDi12sLu0QHhyEf0oIRqPMJMd8TH4abSBa/wRqS7cuucwf7HfXYQow+KNW+gtrq971 8z3Q== X-Gm-Message-State: AMCzsaVgtm9oSpOUZ7yL2F3EdeN6XOYr6EBmNRntfLss2LL75xomh4k7 upcn0zeetz+Da2Tghu8ITrRJKJHd X-Google-Smtp-Source: ABhQp+SB7/JXgLmrARX4Jiv6C4QoojmNQXu02Ru/UKECYEWX6ERwTQOJi2dXJnNwEIl5S0GlWBbP3w== X-Received: by 10.80.194.146 with SMTP id o18mr23736622edf.19.1508942953042; Wed, 25 Oct 2017 07:49:13 -0700 (PDT) Received: from [192.168.0.133] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by smtp.googlemail.com with ESMTPSA id w51sm1963907edd.60.2017.10.25.07.49.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Oct 2017 07:49:11 -0700 (PDT) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <87y3nzu0xu.fsf@gmail.com> <4b46c989-f94e-a5ce-9264-069c34096419@yandex.ru> <87o9ovs6d2.fsf@gmail.com> From: Dmitry Gutov Message-ID: <99a495f7-0d27-27b1-e540-603900d7b614@yandex.ru> Date: Wed, 25 Oct 2017 17:49:09 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <87o9ovs6d2.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) On 10/25/17 4:29 PM, João Távora wrote: > It seems you’re talking, in part, of the expectations of users coming > from more "modern" UI’s, like Sublime’s. Naturally, I want all kinds of users to be happy with Emacs. And the "modern" editors have the right idea in some of their design decisions. > I can understand that argument, > but I also argue that not drifting too much from the (twitchy, I’ll > admit) window popping behavior of Emacs is useful in its own right. I'm arguing that what in the cases we want to quit the xref buffer right after, we actually want some sort of richly-decorated *completion* UI where the user picks one destination (or we could call it a selection UI; something other editors often use popups for). And once they pick it, Emacs can pop the destination in some window or other to its heart content. > For example, I’d argue that Emacs users are almost universally used to > ’C-h f/c/m’ stuff bringing up obtrusive windows that they can quit by > typing ’q’ and get back to their original configuration (provided, yes, > that they don’t mess with the window configuration in the > meantime). But the window configuration changes that happen while the user selects the destination in the xref buffer, can't be undone with 'quit', with out without your patches. > If that UI can be improved, it certainly should. (I have some very old > ideas about a single window dedicated frame for help windows that could > be discussed and developed). But whatever is done it should be done to > Emacs as a whole, to preserve consistency. If you're talking about window management in general, that seems orthogonal to me. > In the meantime, my xref patches try to stay close to the current > paradigm. Additionally, they should benefit automatically from any > future improvements. Let's wait for Eli's opinion. >> But 'a' (correct me if I'm wrong) normally replaces a buffer in the >> *current* window. And kill the previous buffer. > > I can’t correct you because I had no idea of that convention either. I > just mentioned ’a’ because I read it somewhere in the discussion. The binding I have in mind is in dired-mode. There, 'a' replaces the current buffer with another. I don't recall any other 'a' bindings, off the top of my head. > I’ll > be fine with any key that means "yes I’ve really decided I want to go > here now take me there and bury this buffer". As a last resort, an > unbound command that I can remap RET to, or a decent interface that > allows me to write such a command. I'd also be fine with any of those. :) 2 or 3 sound best, though. >>> Of course my priority goes towards RET doing xref-quit-and-goto-xref and >>> something else doing xref-goto-xref. If that default isn’t changed, I’ll >>> probably to that remap in my init file.. >> >> So you'd always use "something else" to navigate to >> project-find-regexp search results? > > No, I’d use "n" or "SPC". These work fine as always. SPC is not bound by default. And you'll probably use 'n' in xref-find-definitions output as well. > When I find the one > I want to edit, I press "RET". I’m a big boy, I can find the *xref* > buffer again :-) Would you prefer similar behavior in *Grep* buffers as well? If you still use those. From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Oct 2017 15:12: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 To: Dmitry Gutov Cc: joaotavora@gmail.com, 28814@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150894428610227 (code B ref 28814); Wed, 25 Oct 2017 15:12:02 +0000 Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 15:11:26 +0000 Received: from localhost ([127.0.0.1]:33466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7NL3-0002es-NU for submit@debbugs.gnu.org; Wed, 25 Oct 2017 11:11:25 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38182) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7NL2-0002eg-5F for 28814@debbugs.gnu.org; Wed, 25 Oct 2017 11:11:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e7NKu-0003DW-BQ for 28814@debbugs.gnu.org; Wed, 25 Oct 2017 11:11:18 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39749) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e7NKu-0003DO-7N; Wed, 25 Oct 2017 11:11:16 -0400 Received: from [176.228.60.248] (port=4892 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1e7NKr-0006i7-PJ; Wed, 25 Oct 2017 11:11:16 -0400 Date: Wed, 25 Oct 2017 18:11:01 +0300 Message-Id: <83inf38dq2.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> (message from Dmitry Gutov on Wed, 25 Oct 2017 03:24:58 +0300) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: 28814@debbugs.gnu.org, eliz@gnu.org > From: Dmitry Gutov > Date: Wed, 25 Oct 2017 03:24:58 +0300 > > 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. Sorry, guys: I will have to take you several steps back, because I got lost in the details of your discussion. I understand that the motivation for changing the existing solution for the "disappearing XREF buffer" was the unexpected or even incorrect behavior when the "C-x 4" variety of the commands is invoked. That is, the existing code would display the definition in the original window, not in "the other" window (which is taken by the XREF buffer). And the original solution was to display the definition in the window where the XREF buffer was displayed, thus making it "disappear". Is that correct? If so, then the easiest solution IMO would be to pop up one more window, i.e. behave as if the window displaying the XREF buffer didn't exist. That would both keep the contract of "C-x 4" and leave the XREF buffer visible. As for quitting the XREF buffer when it's no longer needed: how about 'q', like other similar modes do, or some variety thereof? "C-u RET" is too odd, almost outlandish in Emacs. If the above solves the remaining issues, and if you have no other problems, can we have patches to that effect? And then the next question would be: what branch to install this on? Thanks, and sorry for keeping silence until now. From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) 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 15:28: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 To: Eli Zaretskii Cc: 28814@debbugs.gnu.org, Dmitry Gutov Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150894524511810 (code B ref 28814); Wed, 25 Oct 2017 15:28:01 +0000 Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 15:27:25 +0000 Received: from localhost ([127.0.0.1]:33485 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7NaX-00034Q-Ce for submit@debbugs.gnu.org; Wed, 25 Oct 2017 11:27:25 -0400 Received: from mail-wr0-f180.google.com ([209.85.128.180]:50693) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7NaV-00034A-9g for 28814@debbugs.gnu.org; Wed, 25 Oct 2017 11:27:23 -0400 Received: by mail-wr0-f180.google.com with SMTP id p96so376695wrb.7 for <28814@debbugs.gnu.org>; Wed, 25 Oct 2017 08:27:23 -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=fl/TsnGNtHA7ih+gq9A3EXcSjXZXnI9dwVyTwhVU1JI=; b=q9Z+wUxWfcGwRgliqFdfeDEREHNF6Cyn4oja0f/SigGCxxM+AorsDZuyzJcE7hD6xa z+r0hxYR0AsNhSAZnMc2dKsDeg0Gw4TGrbylnGKHRO8QjwHxTujCOFOQP0xxtXQOH3em kkKWVCdTGW4HR53ZiJpu6OfQyfzYH0siLdkkTkV+7jjlLXSiIfJ5cqCa7Q5N9GaBOe94 OrXnCa1YZgfumPT63GDDS++BnyLatfKzh4R1LVaPWR2eQ4kZSZ5u9YGi4n6+7b794GaX r4kL0NiHM3NEIlrXaeE+5aiftYtGJRVqIQRLJScDvB1uSL4mbdp+bCqQK/tuqdbcFkHI yKtA== 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=fl/TsnGNtHA7ih+gq9A3EXcSjXZXnI9dwVyTwhVU1JI=; b=kdBlyguQfBI0JHOVWHGT3pC1axZR5Sy7JHZMw0azS4rgw25V7r0KD4r2IeF3NGU69v K1COVf8+DS4PrZodWjtgzHm7+6B++LRAvQMyjdjdGGcVR+1ebMQWwJWxQs9T+pRL64Hh c1lda/NMeKbHuZJs43HuxuNe/COv0nWIaELcjC/7ipQ4tuk+eke+gzUIQLfH9VmtVplg hWPuqIfxkTRZ6Pglb7kvmL5ud5kqc2BL/1S6gXNUuoRl2NDdcv4JHcFpHsFOafGtfyFN UH0SrusL2FXuskFf8s9/1xkDG5yb8woCabBv7v0G6ZW6lB6Va83ph+whRRexcQqQyFoJ i6Jw== X-Gm-Message-State: AMCzsaXS67VEkG7+JuZOpdpRKjWd8NTy1Y4dxMfTfcw+mwCmMAWFhNPC mN58fvh7swGHQxSHXoN3Kpkitr5R X-Google-Smtp-Source: ABhQp+Rx/yMZvhT7/zBk8uulC7LG49L4UsrCedk3NdQkkhKAjKWKVqN174MkSJKsNQD2tQZWUuYcxA== X-Received: by 10.223.153.234 with SMTP id y97mr2604798wrb.165.1508945237252; Wed, 25 Oct 2017 08:27:17 -0700 (PDT) Received: from lolita.yourcompany.com ([88.157.205.17]) by smtp.gmail.com with ESMTPSA id x189sm2359498wmf.10.2017.10.25.08.27.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 25 Oct 2017 08:27:16 -0700 (PDT) From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <83inf38dq2.fsf@gnu.org> Date: Wed, 25 Oct 2017 16:27:13 +0100 In-Reply-To: <83inf38dq2.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 25 Oct 2017 18:11:01 +0300") Message-ID: <87k1zjs0xa.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) Eli Zaretskii writes: > I understand that the motivation for changing the existing solution > for the "disappearing XREF buffer" was the unexpected or even > incorrect behavior when the "C-x 4" variety of the commands is > invoked. That is, the existing code would display the definition in > the original window, not in "the other" window (which is taken by the > XREF buffer). And the original solution was to display the definition > in the window where the XREF buffer was displayed, thus making it > "disappear". Is that correct? More or less. You are 90% correct. I wouldn=E2=80=99t link unexpected behav= iour with the "disappear XREF buffer" because they can be seen as independent issues, though closely related. Anyway, it=E2=80=99s OK because the fix you propose further below is exactly the current one I propose (minus some subtleties for when we "can=E2=80=99t" pop a new window because of insufici= ent window dimensions). > If so, then the easiest solution IMO would be to pop up one more > window, i.e. behave as if the window displaying the XREF buffer didn't > exist. That would both keep the contract of "C-x 4" and leave the > XREF buffer visible. Yes, this is the default behaviour in the current patches. > As for quitting the XREF buffer when it's no longer needed: how about > 'q', like other similar modes do, or some variety thereof? "C-u RET" > is too odd, almost outlandish in Emacs. =E2=80=99q=E2=80=99 is already taken by =E2=80=99quit-window=E2=80=99 in *x= ref* buffers. It quits the window and does nothing else. I=E2=80=99m looking for a command that quits = *and* goes to the target. If done in this order, it has the nice benefit that the window thus immediately released is available for showing the cross reference (in the C-x 4 case, that is) If no suitable key for this command can be found (=E2=80=99a=E2=80=99, =E2= =80=99o=E2=80=99 would perhaps be nice), then let=E2=80=99s make an unbound command that I can bound to RE= T. Then let=E2=80=99s open a separate discussion on whether that behaviour sho= uld become the default (I think it should). > If the above solves the remaining issues, and if you have no other > problems, can we have patches to that effect? Sure, as soon as you (or we) decide on one of the following: * C-u RET (for completeness sake, you seem to be against this one) * =E2=80=99a=E2=80=99 bound to a new command xref-quit-and-goto-xref * =E2=80=99o=E2=80=99 bound to a new command xref-quit-and-goto-xref * a new unbound command xref-quit-and-goto-xref > And then the next question would be: what branch to install this on? It=E2=80=99s a bugfix, so emacs-26. From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) 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 15:36: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 To: Dmitry Gutov Cc: 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150894572112686 (code B ref 28814); Wed, 25 Oct 2017 15:36:02 +0000 Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 15:35:21 +0000 Received: from localhost ([127.0.0.1]:33501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7NiC-0003IY-LT for submit@debbugs.gnu.org; Wed, 25 Oct 2017 11:35:20 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:48642) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7NiB-0003IL-OU for 28814@debbugs.gnu.org; Wed, 25 Oct 2017 11:35:20 -0400 Received: by mail-wm0-f51.google.com with SMTP id p75so2680494wmg.3 for <28814@debbugs.gnu.org>; Wed, 25 Oct 2017 08:35:19 -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=oGEzQMxs5odELiv1+//9/oKnQNDo9CFA6rwcNZfyO4o=; b=NRZFVK0bTjJ94Sf4K0QXhOpcUSVuOxW6Xu6vsOMrM49kGzljMI3GM/UCV/NDT95J8x q/ZX5YFaAhNrixuViIH9xCOaE0s4/H88Mh0x2Kqe7eoq/BiEECxX75PzGY8T0pslh1BJ Ua8oh/2ldBFT+ah/EoawGSWLmfMa/rPd9SYjlCgllMaXJJvNkob2FnNNtg51ITvNo4l6 5dM9kfZjknyzd9wwZ53iDsMY7js2LApnWAZcVuEfLvopJ5hzKF/ewthqbhwbk1vMqCJ5 jf/eM2IB3XxhdXyH2CWKToZ/SfZzovgxw0/FiR7A5GJGnLJqgZeZpuKeA3kiR13NRGVn DEdg== 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=oGEzQMxs5odELiv1+//9/oKnQNDo9CFA6rwcNZfyO4o=; b=ROjs6sDG5AupWF8Oxhx1NS8jm6Sd9aeOjdnElaoRM3GmIZH6W/rJFkhINOTPo4bmGp rhWG22ceXNR4xPs1C2Tisq/Cm7IgM3fwtewCiINt6st3Ysx3ML0hd4hXEcjiHobieSMV V9BTMpWu9oZQJlHPZm6197sZ0sJs4nI0ey3s5UIoGaawpJXaVxu8Ew3IR+hIhA8U59oa ESCLIj5t9rQdPuykgpg/TpaqrTUlHXGbi3KYIDC2CuR7IPPvF7AB1BMGr9a8KRwfG/Cv O1NvXKuGNhXWJruSbzJLlY/3pPi8m9ZKrQsFLsOMVnHMcSZo2ZiJ6T4Fye/JANFisXgW wwXg== X-Gm-Message-State: AMCzsaVPExMMihzmbHeKctHzTMfJTNVqiJhGXALVxJiNGcxxmUNbxi74 Tni0Po9aYthMdKIldsMRnjy33zVI X-Google-Smtp-Source: ABhQp+RhDK0iJB6Q0R9GU8n6GKTm+A4umIA0P6R1HB3EhOvlAgfquTlxW9fNCkSDtv2EpyPJGmaARQ== X-Received: by 10.28.55.78 with SMTP id e75mr2046819wma.112.1508945713819; Wed, 25 Oct 2017 08:35:13 -0700 (PDT) Received: from lolita.yourcompany.com ([88.157.205.17]) by smtp.gmail.com with ESMTPSA id u8sm3528960wmd.33.2017.10.25.08.35.12 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 25 Oct 2017 08:35:13 -0700 (PDT) From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <87y3nzu0xu.fsf@gmail.com> <4b46c989-f94e-a5ce-9264-069c34096419@yandex.ru> <87o9ovs6d2.fsf@gmail.com> <99a495f7-0d27-27b1-e540-603900d7b614@yandex.ru> Date: Wed, 25 Oct 2017 16:35:10 +0100 In-Reply-To: <99a495f7-0d27-27b1-e540-603900d7b614@yandex.ru> (Dmitry Gutov's message of "Wed, 25 Oct 2017 17:49:09 +0300") Message-ID: <87fua7s0k1.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Dmitry Gutov writes: > On 10/25/17 4:29 PM, Jo=C3=A3o T=C3=A1vora wrote: > But the window configuration changes that happen while the user > selects the destination in the xref buffer, can't be undone with > 'quit', with out without your patches. You=E2=80=99re right, my patches they keep the window configuration for some definition of "keep" :-). However, a much more correct definition of "keep" than the one we have now. >> If that UI can be improved, it certainly should. (I have some very old >> ideas about a single window dedicated frame for help windows that could >> be discussed and developed). But whatever is done it should be done to >> Emacs as a whole, to preserve consistency. > > If you're talking about window management in general, that seems > orthogonal to me. As it should be. But if we give xref.el a special interface it ceases to be :-) > Let's wait for Eli's opinion. It seems Eli=E2=80=99s OK with the current behaviour minus the C-u RET. > The binding I have in mind is in dired-mode. There, 'a' replaces the > current buffer with another. > > I don't recall any other 'a' bindings, off the top of my head. Then perhaps =E2=80=99a=E2=80=99 can be xref-quit-and-goto-xref if you=E2= =80=99re not opposed to that. > SPC is not bound by default. And you'll probably use 'n' in > xref-find-definitions output as well. You=E2=80=99re right. SPC should be bound to xref-show-xref though, if we a= re honour the SLIME ancestry. >> When I find the one >> I want to edit, I press "RET". I=E2=80=99m a big boy, I can find the *xr= ef* >> buffer again :-) > > Would you prefer similar behavior in *Grep* buffers as well? If you > still use those. Meh... Maybe. I don=E2=80=99t know. I would prefer to always use XREF and project-find-regexp (that I just learned about, thanks!), if only that could be enhanced to the much much faster =E2=80=98git grep=E2=80=99 in Git= projects. Perhaps we could work on that as a separate modification. From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Oct 2017 15:41: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 To: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) Cc: 28814@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150894600513126 (code B ref 28814); Wed, 25 Oct 2017 15:41:02 +0000 Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 15:40:05 +0000 Received: from localhost ([127.0.0.1]:33505 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7Nmn-0003Pe-99 for submit@debbugs.gnu.org; Wed, 25 Oct 2017 11:40:05 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46665) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7Nml-0003P4-AX for 28814@debbugs.gnu.org; Wed, 25 Oct 2017 11:40:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e7Nmc-0005hE-OZ for 28814@debbugs.gnu.org; Wed, 25 Oct 2017 11:39:58 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e7Nmc-0005h4-KY; Wed, 25 Oct 2017 11:39:54 -0400 Received: from [176.228.60.248] (port=1167 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1e7Nmc-0005Um-2U; Wed, 25 Oct 2017 11:39:54 -0400 Date: Wed, 25 Oct 2017 18:39:42 +0300 Message-Id: <83fua78ce9.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87k1zjs0xa.fsf@gmail.com> (joaotavora@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> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: joaotavora@gmail.com (João Távora) > Cc: Dmitry Gutov , 28814@debbugs.gnu.org > Date: Wed, 25 Oct 2017 16:27:13 +0100 > > > If so, then the easiest solution IMO would be to pop up one more > > window, i.e. behave as if the window displaying the XREF buffer didn't > > exist. That would both keep the contract of "C-x 4" and leave the > > XREF buffer visible. > > Yes, this is the default behaviour in the current patches. Good. Then I'm happy. As for when we can't pop up a new window: would it be okay to reuse the current window only in that (hopefully, rare) case? > > As for quitting the XREF buffer when it's no longer needed: how about > > 'q', like other similar modes do, or some variety thereof? "C-u RET" > > is too odd, almost outlandish in Emacs. > > ’q’ is already taken by ’quit-window’ in *xref* buffers. It quits the > window and does nothing else. I’m looking for a command that quits *and* > goes to the target. How about 'Q'? > Then let’s open a separate discussion on whether that behaviour should > become the default (I think it should). What behavior should become the default? The problem with binding this "quit and go to reference" function to RET is that it is unlike any other similar feature we have: RET usually selects the item, but does not quit any windows. > It’s a bugfix, so emacs-26. I'd need to see the patches in their last incarnation (if you already posted them, and nothing needs to be changed, a URL will be appreciated). In general, this changes user-visible behavior in non-trivial ways, so it's borderline between a bugfix and a new feature. But if the patches are small and simple enough, I guess they could be okay for emacs-26. Thanks. From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Oct 2017 15:47: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 To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150894640913788 (code B ref 28814); Wed, 25 Oct 2017 15:47:01 +0000 Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 15:46:49 +0000 Received: from localhost ([127.0.0.1]:33515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7NtJ-0003aK-Ef for submit@debbugs.gnu.org; Wed, 25 Oct 2017 11:46:49 -0400 Received: from mail-wm0-f42.google.com ([74.125.82.42]:57070) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7NtH-0003a6-J4 for 28814@debbugs.gnu.org; Wed, 25 Oct 2017 11:46:47 -0400 Received: by mail-wm0-f42.google.com with SMTP id z3so2815318wme.5 for <28814@debbugs.gnu.org>; Wed, 25 Oct 2017 08:46:47 -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=IHEapYksJ9h0zSNzLa0IFfNUD4Nr+OMvTEqVxW4ODng=; b=gYwL57hxVTkuh5CCDjr1FM2Qldy1Pm3iha8bryg9axjE6KLbuFAkcKZfZO1I9wK9u+ zfyZEiz1iUHhBaxore6+jnW1LVyPP8Ez1mg3aap/rRwZDs8XgwvwSaEqs1ZVPYqeomP0 TzzAfNk5+UG+wRFUy3Ll8PCPEXey715wnMf09zlEfkR3Z2NCKK+gXMLJqduIEHQvLQ3R Pz3nBqcA7qnL83NjpOlNzz3ACBhPomZzHOC90E6tW1UVNbe7r1toYj72UHJ6b9FqEA/b 73UdzchMPy9dqi0fpCRQg00g9SQHvBldb2Zd9rDKMLxDUu4etM4Xklbp/AtgZIpRmkpW RgQw== 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=IHEapYksJ9h0zSNzLa0IFfNUD4Nr+OMvTEqVxW4ODng=; b=hqGSOToKKCTr4IZLS+254Ob6hJufZS55JrMYOckcoRZ1Cd/89njePx/CWLnBfugzqw bE1vQ+QQrXt89pU7HXOkKjRTf2j7pigRhkIW3G2k5Ly42iNERL3P7HFNhptcgOunNCoD H41wtAgzymD20xA0fHhgSIuvJPkuAnpvS0om7F7RlmqmPBpYnIRmhY9PZtMG6JlrXoQ4 HZgMseDar/19eOlkgrVDAmkisLmAaW05J7LDzAW36c/w48t0oHCZ7Z1LHfrlrss8nSud ZD4gpHH6Z9FUmG5wTTSKpEz0D7OaRW97XP+1/YPR5rUKJA3UioOl+tqX+yAaRiqPn4lM AnWw== X-Gm-Message-State: AMCzsaVIfQxHveoAh3VTIKI2XDfn1HRsotg3jEY4M0dAxkCnbY74cQNQ lUVVsTZgR1oHqzhvFMuwZQPdDl8k X-Google-Smtp-Source: ABhQp+TFVrgeXJpJDeEflAoAtwSVcl45ESmd5t4u7xFaFQWlr7mTvWM8OegtfyYOAe7p7bu7OAHpxg== X-Received: by 10.80.215.91 with SMTP id i27mr24989801edj.274.1508946401643; Wed, 25 Oct 2017 08:46:41 -0700 (PDT) Received: from [192.168.0.133] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by smtp.googlemail.com with ESMTPSA id w7sm1435734edw.65.2017.10.25.08.46.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Oct 2017 08:46:40 -0700 (PDT) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <87y3nzu0xu.fsf@gmail.com> <4b46c989-f94e-a5ce-9264-069c34096419@yandex.ru> <87o9ovs6d2.fsf@gmail.com> <99a495f7-0d27-27b1-e540-603900d7b614@yandex.ru> <87fua7s0k1.fsf@gmail.com> From: Dmitry Gutov Message-ID: <64112c8e-81a8-826e-d26f-5a9af8b82aec@yandex.ru> Date: Wed, 25 Oct 2017 18:46:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <87fua7s0k1.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) On 10/25/17 6:35 PM, João Távora wrote: >> The binding I have in mind is in dired-mode. There, 'a' replaces the >> current buffer with another. >> >> I don't recall any other 'a' bindings, off the top of my head. > > Then perhaps ’a’ can be xref-quit-and-goto-xref if you’re not opposed to > that. Just the objection that I've already voiced. 'o' seems better, if you go that route. But that's just because I don't recall exactly what other 'o' bindings do. > I would prefer to always use XREF and > project-find-regexp (that I just learned about, thanks!), if only that > could be enhanced to the much much faster ‘git grep’ in Git projects. > Perhaps we could work on that as a separate modification. Yup. Continuing that discussion is on my list. From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) 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 20:57: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 To: Eli Zaretskii Cc: 28814@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150896499418456 (code B ref 28814); Wed, 25 Oct 2017 20:57:01 +0000 Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 20:56:34 +0000 Received: from localhost ([127.0.0.1]:33702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7Sj2-0004na-R8 for submit@debbugs.gnu.org; Wed, 25 Oct 2017 16:56:34 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:53763) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7Sj0-0004nN-U1 for 28814@debbugs.gnu.org; Wed, 25 Oct 2017 16:56:31 -0400 Received: by mail-wm0-f68.google.com with SMTP id r196so4390851wmf.2 for <28814@debbugs.gnu.org>; Wed, 25 Oct 2017 13:56:30 -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; bh=NhTO8lWBR0q1R7p8LEc2VAwTyvvNeBD2xfUYSXI1JpM=; b=WpIZ6Vyn6Wgk74mw/jETHQVOPDUMtZ0PF7UUoZWBQOZzzpX1GsLl15zZsK4MeX3jAm wEaEVSykjTwx9qH01RLm1xXyk1+qEKm8utw46/YyuHBw3Pnfc2t5pYhKWUQPK2QbiXFU yzJl20c5UlLMOW6HERofW5oE9ry7B+6b0D3VxP6nfOAeEUhYvXB6JFLZtAzfOunPrw8O 03x0JjAayI5MFlg0FpSsXhGqkO50EB+F5V7qDBC1128iec34lP6yZ1b6dcGgzVjYg8zg 7w9aC8y3zbh7FFt4MK4D8qz6A6YGGCngGhZVb14LE7rHMhZP1eMOUzQXafT1/q4QsgHX zjjw== 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; bh=NhTO8lWBR0q1R7p8LEc2VAwTyvvNeBD2xfUYSXI1JpM=; b=SZKQfnfE6i8iD7B+fGZBAVRw1t9EV1hWiE2MQymnRdZ1WpLcyNig782+UaUD8Lkiql 3bWqFcE0MaAxMY19CI3AXhYRLHkvGfbb9xDpzv/ZrDgDF0H3u2VB5VmdPdsIiBUYph/L U5mvTeK4zO40XCraWkoLCOd6EgV9Cz0ZeRwyrNHwnE83l5UDKcANCvUGZVCoqSa2dTLP oJ+e31pXPRP4UR3ZtssdX2w8C4wF7BDZf29StzFjCk1g50Uoy2aCgY19HTolW5v4H5k6 hKcV7lOURCuVYsf+pTpln1JtcqxIccyc6UGx4wJ1pNLmsIe7wW71WRmWAmMZDzf7m2cs JofQ== X-Gm-Message-State: AMCzsaUr6uMUFM+CyoAbjtz8DxGvCbKH+8xq4nRliwaEnyEvB3g1HKXO DDz7IygzJnXTJCfg58f7Yo2WtujH X-Google-Smtp-Source: ABhQp+SYX/WwGJap8hPiXvF9RvvZliNcVAj0l5wah5+YoI5X2FNFZ70UawO5FtB9xeG77qoEW2knhQ== X-Received: by 10.28.152.76 with SMTP id a73mr2630847wme.127.1508964984758; Wed, 25 Oct 2017 13:56:24 -0700 (PDT) Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id c4sm3117744wre.57.2017.10.25.13.56.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 25 Oct 2017 13:56:23 -0700 (PDT) From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> Date: Wed, 25 Oct 2017 21:56:21 +0100 In-Reply-To: <83fua78ce9.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 25 Oct 2017 18:39:42 +0300") Message-ID: <87a80fvte2.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: > As for when we can't pop up a new window: would it be okay to reuse > the current window only in that (hopefully, rare) case? We could do that (I kinda like it) but it's actually harder to implement, I think. We'd have to precisely control the order of display-buffer fallbacks or repeat somewhere else the logic of split-window-sensibly. I'd leave this for an implementation on master. >> > As for quitting the XREF buffer when it's no longer needed: how about >> > 'q', like other similar modes do, or some variety thereof? "C-u RET" >> > is too odd, almost outlandish in Emacs. >>=20 >> =E2=80=99q=E2=80=99 is already taken by =E2=80=99quit-window=E2=80=99 in= *xref* buffers. It quits the >> window and does nothing else. I=E2=80=99m looking for a command that qui= ts *and* >> goes to the target. > > How about 'Q'? OK. I used 'Q'. And added 'TAB'. Because it's a bit what happens in completion, which also selects and quits the transient completions window. I can take 'TAB' out, if you think it's a too high profile a key for something like this. > The problem with binding this "quit and go to reference" function to > RET is that it is unlike any other similar feature we have: RET > usually selects the item, but does not quit any windows. I see. Well, I really don't have any strong arguments against that, other than my feeling that, because *xref* is such a suprise window, even unexpected, that criteria would somehow not apply here. Or rather it is superseeded by a superior mandate to not clutter the user's windows with unexpected cruft. As I mentioned, xref is rooted in SLIME, and I believe (but I might be mistaken now), it used to work like that in that program. Anyway, I'm happy with the new command. >> It=E2=80=99s a bugfix, so emacs-26. > > I'd need to see the patches in their last incarnation (if you already > posted them, and nothing needs to be changed, a URL will be > appreciated). In general, this changes user-visible behavior in > non-trivial ways, so it's borderline between a bugfix and a new > feature. But if the patches are small and simple enough, I guess they > could be okay for emacs-26. Let's hope they are. Attached are 4 patches. The 2 first are part of the bugfix. Number 3 is the new xref-quit-and-goto-xref and number 4 are documentation changes to the .texi manual (also fixed a small bug there) and NEWS. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Honor-window-switching-intents-in-xref-find-definiti.patch >From f4f774416ca0e90d351b10e7da2095ec9a9ba530 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Fri, 13 Oct 2017 15:13:14 +0100 Subject: [PATCH 1/4] Honor window-switching intents in xref-find-definitions (bug#28814) When there is more than one xref to jump to, and an *xref* window appears to help the user choose, the original intent to open a definition in another window or frame is remembered when the choice to go to or show a reference is finally made. * lisp/progmodes/xref.el (xref--show-pos-in-buf): Rewrite. (xref--original-window-intent): New variable. (xref--original-window): Rename from xref--window and move up here for clarity. (xref--show-pos-in-buf): Rewrite. Don't take SELECT arg here. (xref--show-location): Handle window selection decision here. (xref--window): Rename to xref--original-window. (xref-show-location-at-point): Don't attempt window management here. (xref--show-xrefs): Ensure display-action intent is saved. --- lisp/progmodes/xref.el | 69 +++++++++++++++++++++++++++++++++++--------------- 1 file changed, 48 insertions(+), 21 deletions(-) diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 80cdcb3f18..c3e7982205 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -449,43 +449,68 @@ xref--with-dedicated-window (when xref-w (set-window-dedicated-p xref-w xref-w-dedicated))))) -(defun xref--show-pos-in-buf (pos buf select) - (let ((xref-buf (current-buffer)) - win) +(defvar-local xref--original-window-intent nil + "Original window-switching intent before xref buffer creation.") + +(defvar-local xref--original-window nil + "The original window this xref buffer was created from.") + +(defun xref--show-pos-in-buf (pos buf) + "Goto and display position POS of buffer BUF in a window. +Honour `xref--original-window-intent', run `xref-after-jump-hook' +and finally return the window." + (let* ((xref-buf (current-buffer)) + (pop-up-frames + (or (eq xref--original-window-intent 'frame) + pop-up-frames)) + (action + (cond ((memq + xref--original-window-intent + '(window frame)) + t) + ((and + (window-live-p xref--original-window) + (or (not (window-dedicated-p xref--original-window)) + (eq (window-buffer xref--original-window) buf))) + `(,(lambda (buf _alist) + (set-window-buffer xref--original-window buf) + xref--original-window)))))) (with-selected-window - (xref--with-dedicated-window - (display-buffer buf)) + (with-selected-window + ;; Just before `display-buffer', place ourselves in the + ;; original window to suggest preserving it. Of course, if + ;; user has deleted the original window, all bets are off, + ;; just use the selected one. + (or (and (window-live-p xref--original-window) + xref--original-window) + (selected-window)) + (display-buffer buf action)) (xref--goto-char pos) (run-hooks 'xref-after-jump-hook) (let ((buf (current-buffer))) - (setq win (selected-window)) (with-current-buffer xref-buf - (setq-local other-window-scroll-buffer buf)))) - (when select - (select-window win)))) + (setq-local other-window-scroll-buffer buf))) + (selected-window)))) (defun xref--show-location (location &optional select) (condition-case err (let* ((marker (xref-location-marker location)) (buf (marker-buffer marker))) - (xref--show-pos-in-buf marker buf select)) + (cond (select + (select-window (xref--show-pos-in-buf marker buf))) + (t + (save-selected-window + (xref--with-dedicated-window + (xref--show-pos-in-buf marker buf)))))) (user-error (message (error-message-string err))))) -(defvar-local xref--window nil - "The original window this xref buffer was created from.") - (defun xref-show-location-at-point () "Display the source of xref at point in the appropriate window, if any." (interactive) (let* ((xref (xref--item-at-point)) (xref--current-item xref)) (when xref - ;; Try to avoid the window the current xref buffer was - ;; originally created from. - (if (window-live-p xref--window) - (with-selected-window xref--window - (xref--show-location (xref-item-location xref))) - (xref--show-location (xref-item-location xref)))))) + (xref--show-location (xref-item-location xref))))) (defun xref-next-line () "Move to the next xref and display its source in the appropriate window." @@ -727,7 +752,8 @@ xref--show-xref-buffer (xref--xref-buffer-mode) (pop-to-buffer (current-buffer)) (goto-char (point-min)) - (setq xref--window (assoc-default 'window alist)) + (setq xref--original-window (assoc-default 'window alist) + xref--original-window-intent (assoc-default 'display-action alist)) (current-buffer))))) @@ -754,7 +780,8 @@ xref--show-xrefs (t (xref-push-marker-stack) (funcall xref-show-xrefs-function xrefs - `((window . ,(selected-window))))))) + `((window . ,(selected-window)) + (display-action . ,display-action)))))) (defun xref--prompt-p (command) (or (eq xref-prompt-for-identifier t) -- 2.14.2 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0002-Allow-split-window-sensibly-to-split-threshold-in-fu.patch >From aae81ea38c6062399c60d0018533e4be359bae6e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Mon, 23 Oct 2017 09:05:32 +0100 Subject: [PATCH 2/4] Allow split-window-sensibly to split threshold in further edge case As a fallback, and to avoid creating a frame, split-window-sensibly would previously disregard split-height-threshold if the window to be split is the frame's root window. This change generalizes that: it disregards the threshold if the window to be split is the frame's only _usable_ window (it is either the only one, as before, or all the other windows are dedicated to some buffer and thus cannot be touched). This is required for the fix to bug#28814. * lisp/window.el (split-height-threshold): Adjust doc to match split-window-sensibly. (split-window-sensibly): Also disregard threshold if all other windows are dedicated. --- lisp/window.el | 35 ++++++++++++++++++++++++----------- 1 file changed, 24 insertions(+), 11 deletions(-) diff --git a/lisp/window.el b/lisp/window.el index c0a9ecd093..4814d12400 100644 --- a/lisp/window.el +++ b/lisp/window.el @@ -6465,8 +6465,9 @@ split-height-threshold vertically only if it has at least this many lines. If this is nil, `split-window-sensibly' is not allowed to split a window vertically. If, however, a window is the only window on its -frame, `split-window-sensibly' may split it vertically -disregarding the value of this variable." +frame, or all the other ones are dedicated, +`split-window-sensibly' may split it vertically disregarding the +value of this variable." :type '(choice (const nil) (integer :tag "lines")) :version "23.1" :group 'windows) @@ -6573,15 +6574,27 @@ split-window-sensibly ;; Split window horizontally. (with-selected-window window (split-window-right))) - (and (eq window (frame-root-window (window-frame window))) - (not (window-minibuffer-p window)) - ;; If WINDOW is the only window on its frame and is not the - ;; minibuffer window, try to split it vertically disregarding - ;; the value of `split-height-threshold'. - (let ((split-height-threshold 0)) - (when (window-splittable-p window) - (with-selected-window window - (split-window-below)))))))) + (and + ;; If WINDOW is the only usable window on its frame (it is + ;; the only one or, not being the only one, all the other + ;; ones are dedicated) and is not the minibuffer window, try + ;; to split it vertically disregarding the value of + ;; `split-height-threshold'. + (let ((frame (window-frame window))) + (or + (eq window (frame-root-window frame)) + (catch 'done + (walk-window-tree (lambda (w) + (unless (or (eq w window) + (window-dedicated-p w)) + (throw 'done nil))) + frame) + t))) + (not (window-minibuffer-p window)) + (let ((split-height-threshold 0)) + (when (window-splittable-p window) + (with-selected-window window + (split-window-below)))))))) (defun window--try-to-split-window (window &optional alist) "Try to split WINDOW. -- 2.14.2 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0003-Provide-new-xref-quit-and-goto-xref-bind-it-to-Q-and.patch >From 4cfc9f26f65038d088649789759ac7d2414ac2b8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Fri, 13 Oct 2017 16:37:47 +0100 Subject: [PATCH 3/4] Provide new xref-quit-and-goto-xref, bind it to "Q" and "TAB" (bug#28814) This quits the *xref* window just before the user decides jump to ref. * lisp/progmodes/xref.el (xref--show-location): Handle 'quit value for SELECT. (xref-goto-xref): Take optional QUIT arg. (xref-quit-and-goto-xref): New command. (xref--xref-buffer-mode-map): Bind "Q" and "TAB" to xref-quit-and-goto-xref. --- lisp/progmodes/xref.el | 25 ++++++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-) diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index c3e7982205..aeeeba8051 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -493,11 +493,17 @@ xref--show-pos-in-buf (selected-window)))) (defun xref--show-location (location &optional select) + "Helper for `xref-show-xref' and `xref-goto-xref'. +Go to LOCATION and if SELECT is non-nil select its window. If +SELECT is `quit', also quit the *xref* window." (condition-case err (let* ((marker (xref-location-marker location)) - (buf (marker-buffer marker))) + (buf (marker-buffer marker)) + (xref-buffer (current-buffer))) (cond (select - (select-window (xref--show-pos-in-buf marker buf))) + (if (eq select 'quit) (quit-window nil nil)) + (with-current-buffer xref-buffer + (select-window (xref--show-pos-in-buf marker buf)))) (t (save-selected-window (xref--with-dedicated-window @@ -529,12 +535,19 @@ xref--item-at-point (back-to-indentation) (get-text-property (point) 'xref-item))) -(defun xref-goto-xref () - "Jump to the xref on the current line and select its window." +(defun xref-goto-xref (&optional quit) + "Jump to the xref on the current line and select its window. +Non-interactively, non-nil QUIT says to first quit the *xref* +buffer." (interactive) (let ((xref (or (xref--item-at-point) (user-error "No reference at point")))) - (xref--show-location (xref-item-location xref) t))) + (xref--show-location (xref-item-location xref) (if quit 'quit t)))) + +(defun xref-quit-and-goto-xref () + "Quit *xref* buffer, then jump to xref on current line." + (interactive) + (xref-goto-xref t)) (defun xref-query-replace-in-results (from to) "Perform interactive replacement of FROM with TO in all displayed xrefs. @@ -658,6 +671,8 @@ xref--xref-buffer-mode-map (define-key map (kbd "p") #'xref-prev-line) (define-key map (kbd "r") #'xref-query-replace-in-results) (define-key map (kbd "RET") #'xref-goto-xref) + (define-key map (kbd "Q") #'xref-quit-and-goto-xref) + (define-key map (kbd "TAB") #'xref-quit-and-goto-xref) (define-key map (kbd "C-o") #'xref-show-location-at-point) ;; suggested by Johan Claesson "to further reduce finger movement": (define-key map (kbd ".") #'xref-next-line) -- 2.14.2 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0004-Document-changes-to-xref-behavior-in-NEWS-and-texi-m.patch >From ae3a5adda7debf77e03c151b84c1062ae90b6970 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Wed, 25 Oct 2017 19:27:15 +0100 Subject: [PATCH 4/4] Document changes to xref behavior in NEWS and texi manual (bug#28814) * doc/emacs/maintaining.texi (Looking Up Identifiers): Mention new bindings in *xref*, rework slightly to avoid repetition. (Xref Commands): Describe new bindings in *xref*. * etc/NEWS (Xref): New section describing bugfix and new bindings. --- doc/emacs/maintaining.texi | 52 ++++++++++++++++++++++++++-------------------- etc/NEWS | 20 ++++++++++++++++++ 2 files changed, 50 insertions(+), 22 deletions(-) diff --git a/doc/emacs/maintaining.texi b/doc/emacs/maintaining.texi index dc0a71511f..650419a855 100644 --- a/doc/emacs/maintaining.texi +++ b/doc/emacs/maintaining.texi @@ -1828,15 +1828,6 @@ Looking Up Identifiers to always prompt, customize @code{xref-prompt-for-identifier} to @code{t}.) -If the specified identifier has only one definition, the command jumps -to it. If the identifier has more than one possible definition (e.g., -in an object-oriented language, or if there's a function and a -variable by the same name), the command shows the candidate -definitions in a @file{*xref*} buffer, together with the files in -which these definitions are found. Selecting one of these candidates -by typing @kbd{@key{RET}} or clicking @kbd{mouse-2} will pop a buffer -showing the corresponding definition. - When entering the identifier argument to @kbd{M-.}, the usual minibuffer completion commands can be used (@pxref{Completion}), with the known identifier names as completion candidates. @@ -1860,21 +1851,34 @@ Looking Up Identifiers matching of identifiers instead of matching symbol names as fixed strings. - When any of the above commands finds more than one definition, it -presents the @file{*xref*} buffer showing the definition candidates. -In that buffer, you have several specialized commands, described in -@ref{Xref Commands}. +When any of these commands finds a unique definition for the specified +identifier, the command jumps to that location. If, however, the +identifier has more than one possible definition (e.g., in an +object-oriented language, or if there's a function and a variable by +the same name), the command shows the candidate definitions in a +@file{*xref*} buffer, together with the files in which these +definitions are found. + +Selecting one of these candidates by typing @kbd{@key{RET}} or +clicking @kbd{mouse-2} will pop a buffer showing the corresponding +definition. If you only want to display that buffer, but still remain +in @file{*xref*} window, you can also type @kbd{C-o} to do so. +Finally, if you're quite sure you're already at the definition you +want to jump to, you can press @kbd{@key{TAB}} to jump to the buffer +and dismiss the @file{*xref*} window. For a complete list of commands +available in this buffer, @ref{Xref Commands}. @kindex M-, @findex xref-pop-marker-stack @vindex xref-marker-ring-length - To go back to places @emph{from where} you found the definition, -use @kbd{M-,} (@code{xref-pop-marker-stack}). It jumps back to the -point of the last invocation of @kbd{M-.}. Thus you can find and -examine the definition of something with @kbd{M-.} and then return to -where you were with @kbd{M-,}. @kbd{M-,} allows you to retrace your -steps to a depth determined by the variable -@code{xref-marker-ring-length}, which defaults to 16. + Once you arrive at the desired definition, you may want to go back +to places @emph{from where} you found the definition. For this, use +@kbd{M-,} (@code{xref-pop-marker-stack}). It jumps back to the point +of the last invocation of @kbd{M-.}. Thus you can find and examine +the definition of something with @kbd{M-.} and then return to where +you were with @kbd{M-,}. @kbd{M-,} allows you to retrace your steps +to a depth determined by the variable @code{xref-marker-ring-length}, +which defaults to 16. @node Xref Commands @subsubsection Commands Available in the @file{*xref*} Buffer @@ -1887,8 +1891,7 @@ Xref Commands @table @kbd @item @key{RET} @itemx mouse-2 -Display the reference on the current line and bury the @file{*xref*} -buffer. +Display the reference on the current line. @item n @itemx . @findex xref-next-line @@ -1903,6 +1906,11 @@ Xref Commands @findex xref-show-location-at-point Display the reference on the current line in the other window (@code{xref-show-location-at-point}). +@item TAB +@itemx Q +@findex xref-quit-and-goto-xref +Display the reference on the current line and bury the @file{*xref*} +buffer (@code{xref-quit-and-goto-xref}). @findex xref-query-replace-in-results @item r @var{pattern} @key{RET} @var{replacement} @key{RET} Perform interactive query-replace on references that match diff --git a/etc/NEWS b/etc/NEWS index 82778932ab..b79a0019d8 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1185,6 +1185,26 @@ New user options `term-char-mode-buffer-read-only' and are non-nil by default. Customize these options to nil if you want the previous behavior. +** Xref + +*** When an *xref* buffer is needed, window-switching intent is preserved + +This most visibly affects the commands +'xref-find-definitions-other-window' and +'xref-find-definitions-other-frame' bound to 'C-x 4 .' and 'C-x 5 .' +by default. When selecting a cross reference from the *xref* list, +Emacs remembers that the user's intention was keep the originally +selected window/frame's contents. Similarly, the original window is +always chosen by the regular 'xref-find-definitions' command, +regardless if an *xref* buffer is needed or not. + ++++ +*** New command 'xref-quit-and-goto-xref' quits and jumps to an xref + +This command is bound to 'Q' and 'TAB' by default. By quitting +the *xref* window, it makes space for new windows, just as if +the *xref* hadn't been necessary in the first place. + * New Modes and Packages in Emacs 26.1 -- 2.14.2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 DQpKb8Ojbw0K --=-=-=-- From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Oct 2017 07:57: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 To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 28814@debbugs.gnu.org, Dmitry Gutov Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150900459522707 (code B ref 28814); Thu, 26 Oct 2017 07:57:01 +0000 Received: (at 28814) by debbugs.gnu.org; 26 Oct 2017 07:56:35 +0000 Received: from localhost ([127.0.0.1]:33946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7d1m-0005uB-V9 for submit@debbugs.gnu.org; Thu, 26 Oct 2017 03:56:35 -0400 Received: from mout.gmx.net ([212.227.17.21]:54073) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7d1k-0005tx-Ni for 28814@debbugs.gnu.org; Thu, 26 Oct 2017 03:56:33 -0400 Received: from [192.168.1.100] ([46.125.250.87]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LqW8j-1dTbJY4Btp-00e4sp; Thu, 26 Oct 2017 09:56:26 +0200 Message-ID: <59F1951E.1060204@gmx.at> Date: Thu, 26 Oct 2017 09:56:14 +0200 From: martin rudalics MIME-Version: 1.0 References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <59F0413F.8010100@gmx.at> <87wp3js6u9.fsf@gmail.com> In-Reply-To: <87wp3js6u9.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:HKLp8IX/n4WVPVCI7f/cxoUHvvozau5F8woBBkwEiILGwyK72j7 Z8xnZrdAu38rnYm/ClDVygzsQLp7of3bi3P8IXrk9pZ3xRjZH8xmBVrvdJYAEQyj88X+Xrd vw/UmrfN/Wb6WWMgEV5Lxqx+TNi2ondIXdywwmYE55QuXj2qp0lDz1HyIHaoLEUTF7wgk4F 17iugxVmtSZJBThlkqHlQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:q1XomG5613M=:45LaTQtoYyS4Zf0Z7OaBFS BJjATtN0ihvqbP64b6G365FpXaOMJvxdUrdU5Qy7w6KLzzX5rcwiPHNDCmvCzd2TQ2FoJlGtV W1ubpN1PthhPzQIUYF5zfYR5UnO5HEphsOVpgFY9bXw5+w5adNyOROFgudBJChIjNckHwBVJo EYZM1v1exL1vadHcw+FSG8p4S9wPH0I045Ucx6EmudMuSD5/Ojbs864h/JGdu8QcBfjBjXOby 3HQe3YITv1AytkhP7SziffyGM0CCGgaz7CcCTvzFUD7yQJQDwjNmgQ1xh4MW5k/0yV1I2nIMN EPH1ayfpHwxVon9taWqktONKVC75uoTu+l87ebvKx3GpdPoeiuRWG4Gq8URtbkjYuyt13Izem eIGDJeJdI9YZo9lRd1fAOmnX6eBMzfJCOHPwOS/IAHzw1cbyBdQ9bJ0yJY4alPg46EEQ7cAbN SA4V5j4TtxRZwX6rRDGUwderWc7Z5d9hrgKwugMF0l0dvTWtuWA2OFgQdlOa0tER46OAM274d qJjtjSJbqmUrRhEtYEOzZjhFcxaykPIGyJQUNyYCM3VKUkd79Hr91gvtm/EjAyATwyF9vLKgS mXTOmhrgukSIOXAvkB9dwmJLVvuYn7iP2Mgr3ZMzZ27nZn8qxA8xKhxhVuMMlQMUxTLxgpfef Gp/YM3+3qpg6YPZ6hMHgZlVcjIN2lfiN+0V0qFdXjApZzr5XNqHrbvNW1uHQFZUPliwCow0Yc qmIDgGhQTbWBdftrIA1m7H2JaTRtrOOIUWSR0nstzUsPDOrf0i3z3muqrX1a6tGEHqKmkErlp +gUnY8lIOFFyltG3x7EiW55jNnmUvYER1LDxqy31aDadpQ7kmzIdwEgV5CD0yPjQ+6VBVgV X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.5 (---) > Perhaps we could just wait for the (quite improbable in my opinion) > complaints of dedicated window users that expected their split-window > operations to fail in certain extreme situations hence causing > (un)expected frames to pop up? OK. >> In either case, instead of constructing >> =E2=80=98window-list=E2=80=99 please consider using =E2=80=98walk-win= dow-tree=E2=80=99 for that part > > Done. See attached patch. Thanks, martin From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Oct 2017 07:57: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 To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Eli Zaretskii Cc: 28814@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150900460322727 (code B ref 28814); Thu, 26 Oct 2017 07:57:02 +0000 Received: (at 28814) by debbugs.gnu.org; 26 Oct 2017 07:56:43 +0000 Received: from localhost ([127.0.0.1]:33949 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7d1v-0005uV-8W for submit@debbugs.gnu.org; Thu, 26 Oct 2017 03:56:43 -0400 Received: from mout.gmx.net ([212.227.17.20]:53658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7d1t-0005uJ-O7 for 28814@debbugs.gnu.org; Thu, 26 Oct 2017 03:56:42 -0400 Received: from [192.168.1.100] ([46.125.250.87]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LyR1G-1d5EIB3xPK-015sGJ; Thu, 26 Oct 2017 09:56:34 +0200 Message-ID: <59F19526.8070104@gmx.at> Date: Thu, 26 Oct 2017 09:56:22 +0200 From: martin rudalics MIME-Version: 1.0 References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> <87a80fvte2.fsf@gmail.com> In-Reply-To: <87a80fvte2.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:g2HZKWLJz8RQX9EjOApUc8eGUwTozj52aA6LGf7kM9nMv/xTl56 JKl6c06BC/zCKOLCmPlXn934wW0tLDc9qANjTggyCfJlDsuifipB1nIB2wdjHYq/osj0iu3 6OZ1J8WubuB6N3Ws7KFf81PHPmsQkLJAWb3ZQ9qavstt61FKrDd2o0r9W8JUJNe75dT8aCw cD0Gu5qvrIuu1bS8O/nsw== X-UI-Out-Filterresults: notjunk:1;V01:K0:SN7Y4LsfUV4=:MhiTRXaZvexqVQpoOKMi4A r6YYYgGDBBjy6xOjVFXyN/Z8sZS/c5ZVLDzy5VatSsKSVcIfvVDaTkv6pPzFNYDxJo+kD7c7D D3utIDPFkq8Yna/cFZAEqkoSNuAUrLZ/NDs/gT37oNmBD3udqOcsZKPWGgrqGw0Ul4OfZNLJz 6bm/bo/7iiCGIbIUpaekil2cD7SLuQgPZWdEZcpeZsqgCW7PSW/bgbB5W3n9/JEfwSW/FafJN Eh7s2IyjU68xE1R7VL6fkPdgI7J1o0TcOu6aFDrQy8lCpVX7nd76nzUI32H2cNhiFU0/x5QPi IPqmdFnbZXumXmNKr+pceEqtpZyysZuIJSFuEegi4Dm71RKHTT3XUz3JOzciqhwiY+qSUc40/ /KY575QQ/I1jQGF25cFhjhndIp9ZItBOGUDy7hklo1VZBelxTh0CsiXi33NxjrQn7tyR3CHZu 6AVXtF+4uBxbM6AbzB1CKjz15ZlcOt4CV0NUyG2e58juaxOmyK6qGLFI9RD0NNugz7w3UcNtI kXCaAUyKpxJlc3qPaOK59eIiFaKTdNzlMj2wU8c7XniSj+OcjM+nHB67fLYmycF4DA1ODwY9z EXwQNJO6zoAYEO+6Nq8c4/xvcAymHmzpyt8TtAqZsI1+2kUTvdqGXW/y8X5cDJFa+gNdcL/zi AcnAH8lM5H4k7VZta1yYMiqynMiuuoOwA4UJQpc1P4ic/BE7QrABy/gNdw8/nyUQalI78a123 6zvoog8ZDvbZu4CraL92Z/rvpr0SYbkI1HinRjTqWgLyTD9f8x7mTdt/InvKzsOixfdr+BaZc dOCisDISamOiKChcHGTNWLjbg9Khjx8FO6pWkLZxcj6/jtaoobGavNi4VI4yhXGjdOpxU1m X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) > This change generalizes that: it disregards the threshold if the > window to be split is the frame's only _usable_ window (it is either > the only one, as before, or all the other windows are dedicated to > some buffer and thus cannot be touched). "all the other windows" should become "all other windows on this frame" And please add this to the appropriate place (section 28.15 Additional Options for Displaying Buffers) of the Elisp manual. Thanks, martin From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Oct 2017 12:40: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 To: Eli Zaretskii , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150902158130405 (code B ref 28814); Thu, 26 Oct 2017 12:40:02 +0000 Received: (at 28814) by debbugs.gnu.org; 26 Oct 2017 12:39:41 +0000 Received: from localhost ([127.0.0.1]:34077 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7hRl-0007uK-Ff for submit@debbugs.gnu.org; Thu, 26 Oct 2017 08:39:41 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:49956) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7hRk-0007u8-07 for 28814@debbugs.gnu.org; Thu, 26 Oct 2017 08:39:40 -0400 Received: by mail-wm0-f51.google.com with SMTP id b189so7639178wmd.4 for <28814@debbugs.gnu.org>; Thu, 26 Oct 2017 05:39:39 -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=CvzMzVXX+oUpCoycZoFoUjUITWVp7MbNHOFFR+hM0GU=; b=kVizHWGXRXV11M2NeM3zOCCDp0W81nyQBoVrwePoYZj2e2Yum12mOn9VoEhCSkN91d rodsALswwUGS42AuKjD9Y5zCZD+HoYY0mPWSaGbR7/QQl4jTCn0Y6e3tSkba7xs4BAm/ WkOxJXFRb1yV76NP5RolryEnQgpu9Ohv32dAoz9jOZMq2rW3dV4ibyn8xWW7uA+36Z8C o+m/sPBypP4mxOIqZX5bkio/eyFEHd+MoyiX4mE9W9mCOCFaJZJMrdx9LpG9S49ND4vR SXQmk9NPBn/ENTAN9O9MNwVpJBwnJFdI2TXhkg0otoO6XPhamqp+iEiBDZAL7YaH0ZTJ 1JpA== 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=CvzMzVXX+oUpCoycZoFoUjUITWVp7MbNHOFFR+hM0GU=; b=h/mpbkZtiot8dR0fZorKkRWbtqhq8kEL1Fo0LJxjQ4p2YQ8YewQaGkU0lU6KGcFoV3 4HUW3fzebESwgiMrPPMY8bUu5nWT8hULGi59K3409SrlAgbnwuP+cFww70zY9+hlrp1h tHTbVi7Zt5KlqcFpC1ZWfrsBpOiNf5JcRCojMnjVyXWQzq6YiqMPcIsV1yqINrIaewEk HPvDlrapRDA6g2PEXEj2oaheMXsq4R7effC/ZnUE4UrDLazAe4cPOHruIFDT2Gy4u5Km o7bKEv6E1xAzZne8zE1VkOj/zLBcXBFCZvWXDHzLuYfAsoT2eQ7iCg9wbi+9Znj2uJMn H9jg== X-Gm-Message-State: AMCzsaXoP4w/OF9+ZoNWNEYlu23Lhtv42QpEqTLSk++x1Z95A+5mfh9y IyECi8VRSA+xsJmmszz0z+9seGPK X-Google-Smtp-Source: ABhQp+SFtKu657ldUp/qYWbnR43stx0uS0JWvp+plE4GhNpBTblD8laSY6JT3UWzT4/oBCbHaUjtNw== X-Received: by 10.80.174.193 with SMTP id f1mr28670895edd.207.1509021573972; Thu, 26 Oct 2017 05:39:33 -0700 (PDT) Received: from [192.168.0.133] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by smtp.googlemail.com with ESMTPSA id f46sm3622010edd.80.2017.10.26.05.39.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 05:39:32 -0700 (PDT) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> From: Dmitry Gutov Message-ID: <4d11dc8b-0888-fcf8-b90d-8308c3e2219b@yandex.ru> Date: Thu, 26 Oct 2017 15:39:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <83fua78ce9.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) On 10/25/17 6:39 PM, Eli Zaretskii wrote: >> ’q’ is already taken by ’quit-window’ in *xref* buffers. It quits the >> window and does nothing else. I’m looking for a command that quits *and* >> goes to the target. > > How about 'Q'? Isn't it almost as odd? The main goal of the command is to perform navigation. Quitting the window is an important side-effect, but it's still a side-effect. I think 'o' or 'j' would be much better. From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Oct 2017 16:44: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 To: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) Cc: 28814@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150903618828874 (code B ref 28814); Thu, 26 Oct 2017 16:44:01 +0000 Received: (at 28814) by debbugs.gnu.org; 26 Oct 2017 16:43:08 +0000 Received: from localhost ([127.0.0.1]:35343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7lFL-0007Vd-OF for submit@debbugs.gnu.org; Thu, 26 Oct 2017 12:43:07 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40642) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7lFJ-0007VA-OH for 28814@debbugs.gnu.org; Thu, 26 Oct 2017 12:43:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e7lF9-0001wY-NJ for 28814@debbugs.gnu.org; Thu, 26 Oct 2017 12:43:00 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59412) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e7lF9-0001wU-K1; Thu, 26 Oct 2017 12:42:55 -0400 Received: from [176.228.60.248] (port=2234 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1e7lF8-00079w-VE; Thu, 26 Oct 2017 12:42:55 -0400 Date: Thu, 26 Oct 2017 19:42:44 +0300 Message-Id: <83y3nx7tdn.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87a80fvte2.fsf@gmail.com> (joaotavora@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> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> <87a80fvte2.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: joaotavora@gmail.com (João Távora) > Cc: dgutov@yandex.ru, 28814@debbugs.gnu.org > Date: Wed, 25 Oct 2017 21:56:21 +0100 > > > How about 'Q'? > > OK. I used 'Q'. And added 'TAB'. Because it's a bit what happens in > completion, which also selects and quits the transient completions > window. If Dmitry doesn't like 'Q', I'm not wedded to it. Feel free to change the keybinding. > >> It’s a bugfix, so emacs-26. > > > > I'd need to see the patches in their last incarnation (if you already > > posted them, and nothing needs to be changed, a URL will be > > appreciated). In general, this changes user-visible behavior in > > non-trivial ways, so it's borderline between a bugfix and a new > > feature. But if the patches are small and simple enough, I guess they > > could be okay for emacs-26. > > Let's hope they are. Attached are 4 patches. The 2 first are part of the > bugfix. Number 3 is the new xref-quit-and-goto-xref and number 4 are > documentation changes to the .texi manual (also fixed a small bug there) > and NEWS. Thanks. What can I say? the patches are really not trivial, and I hesitate to put them on emacs-26. During development of Emacs 25 it took us some time and effort to stabilize these features, so I'd hate to destabilize them now because of some unintended consequence we don't currently envision. OTOH, we are only at the first pretest. Dmitry, what's your opinion? A few comments to the documentation: . Please proofread the text for UK English spellings (e.g., "honour") and only one space between sentences. . I don't understand the reason for such extensive changes in the manual. Most of them look purely stylistic, and I see no problems with the original text to justify that. What did I miss? . I don't see a need for a NEWS entry. If this is a bugfix, then it doesn't belong there, as we don't describe bugfixes in NEWS (there are too many to describe). From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Oct 2017 22:41: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 To: Eli Zaretskii , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.15090576594933 (code B ref 28814); Thu, 26 Oct 2017 22:41:02 +0000 Received: (at 28814) by debbugs.gnu.org; 26 Oct 2017 22:40:59 +0000 Received: from localhost ([127.0.0.1]:35696 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7qpf-0001HV-3O for submit@debbugs.gnu.org; Thu, 26 Oct 2017 18:40:59 -0400 Received: from mail-wr0-f194.google.com ([209.85.128.194]:43755) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7qpe-0001HG-CY for 28814@debbugs.gnu.org; Thu, 26 Oct 2017 18:40:58 -0400 Received: by mail-wr0-f194.google.com with SMTP id w105so4604555wrc.0 for <28814@debbugs.gnu.org>; Thu, 26 Oct 2017 15:40:58 -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=hEUrhANtj44eok+EzQJRD2lQDBHfJLpyIAdznfr75e8=; b=VmvgSZYAGEK1rcKkCzwoCZwfbDcRVEsK7JOE1+F8Bux9oVgetFEt1bkYqs6MHeiU0O ctJP5UC2xZl/Mz6K2Widqjr6fjgdXEooVbu2J9IFdJJBJBjTlvjr+p61Reg8LhWgbGqZ wKVj2mugsgXbUdN05bWMo7DG9EkrshTrz6NhaxrqWZ7N2yTpl9chzUJT9Jc6QNXBpHkL Q7sszojkp/7lDE1jQpqbiMBFj6PUvMgqVaY19yCwG/Z/GNd2edZ+2mCtvBg9U5dcFdnn 0pC5vXbgFuC/aL88wja3Rh5dFcE2LJlENJGmwjLQ+ViRchE/1Bi6CwcvNHFZ3KW6DtkP 3b3A== 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=hEUrhANtj44eok+EzQJRD2lQDBHfJLpyIAdznfr75e8=; b=ePRV2Q4b4lqwTk2k8WeXuR1cXAsJ/QPR+KDDOnPkk/RFY/7g9cbeR8skut8N4Br76C 8BhY1cvTedtwOwyIJ3onyzB1BeZcnnaXYPuao7ez5QowWGeSvbwEEhIztTd/1iTvccqo UOxkUc0cfy7RoUemqgh5fAgkHjlu11wRtnE7OJmJJkutA117z6D+sRreZ47UJSgd8oE3 ZrLAcYuYAQTkfMAfhNz7etz7WPYh+rHcXB2f5pmrUrE41CYmCSjiAPWPfIPjbEYYr6pp BTsEHagZ/iI/p3bTUic7BU6Fv279fk6eLo8G3SYCHSQ7zqZcI0JXMeZBvji/wVQ5ZU8M xahw== X-Gm-Message-State: AMCzsaV66SmghgIxSu+Os3/CZI3aNrvT5E7CdF4CiQ95pHfOIe4JJksK bpVe6SpETmip9C3au74ZY5UM36u7 X-Google-Smtp-Source: ABhQp+QBGpqjiUwXmGWzNPaUEA/fP6zfyBuu4DDDaiYC9IKvuk1TS3xO8y/QJLyseHaOPpp/SUqsyA== X-Received: by 10.223.176.82 with SMTP id g18mr955924wra.234.1509057652073; Thu, 26 Oct 2017 15:40:52 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id 25sm5618453wrv.8.2017.10.26.15.40.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 15:40:50 -0700 (PDT) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> <87a80fvte2.fsf@gmail.com> <83y3nx7tdn.fsf@gnu.org> From: Dmitry Gutov Message-ID: <73791641-aab2-69ff-6cbb-a9738c868802@yandex.ru> Date: Fri, 27 Oct 2017 01:40:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <83y3nx7tdn.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) On 10/26/17 7:42 PM, Eli Zaretskii wrote: > If Dmitry doesn't like 'Q', I'm not wedded to it. Feel free to change > the keybinding. Thanks. > Dmitry, what's your opinion? IMO, not a bugfix, but I don't mind getting the changes in and seeing how many people disapprove during the pretest. It's your choice, though. From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) 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: Fri, 27 Oct 2017 00:00: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 To: Eli Zaretskii Cc: 28814@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150906238119534 (code B ref 28814); Fri, 27 Oct 2017 00:00:02 +0000 Received: (at 28814) by debbugs.gnu.org; 26 Oct 2017 23:59:41 +0000 Received: from localhost ([127.0.0.1]:35763 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7s3p-00054z-DB for submit@debbugs.gnu.org; Thu, 26 Oct 2017 19:59:41 -0400 Received: from mail-wr0-f180.google.com ([209.85.128.180]:50715) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7s3m-00054l-1z for 28814@debbugs.gnu.org; Thu, 26 Oct 2017 19:59:38 -0400 Received: by mail-wr0-f180.google.com with SMTP id p96so4666438wrb.7 for <28814@debbugs.gnu.org>; Thu, 26 Oct 2017 16:59:37 -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; bh=YvHOIiooQLLYFyUMLCRRl3J+No2eXzQXOLfcYFG1swk=; b=fcRmb0JqK9ExBsAVSKTBl4UeLUlQk8VqBft/MmkzPUtB62hV28e8UWUBK08eF1znCQ iaWdcBWhCdk1nhdHeM4wEEr5hLZvqWcNLQK5d7lDOHHsa8MCpogXkyzaoR9j2ax83/5E da4okiyljlCvPNFNV1rYWhvvkFVwXD4BCpK3ArNyMnbn9F9pO6UGsTmX9pxjwCwynidk ZNfCEKzRrH86924NPHl/4H1NUQhB7cQATzzjqFwMwpOWSGs65qgh54LOlYSiOuOIJtW6 7JLxU0Rg/KA0jdQzh0QWHJ3D5DFAAhr8Le2JmFKfkmQqbaWvaLbb/nD0WfiYh2pOPkrJ vxdA== 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; bh=YvHOIiooQLLYFyUMLCRRl3J+No2eXzQXOLfcYFG1swk=; b=IhnDK4cVCPthFrtFbjHfbb8R+C8KLYfoZueqIooB1AQjbnFFFnkD4yUVgDasvtytrw uNhPMykxPmfSn6JhvgkPpwl/u7t54i2fyHdbpPJ8b0rl+Hl0aSySpojOdtR+oCLYNGY6 WOVQxFH7K++ntCt3t5cWwPgLstvdtYTLyLsYAe5pwZAOHkMOVlqAQH9fhfcpPdx5T8IN TsQOdU8DugvUTNnLM9sMBjiTt+vjFiCX4xxp0IFFKxlID+1na0kbBqPcnc6XG2VT3v8E Xd0dDg8Etdc0dhycyf498hOlTylbx8HtK5UPB4Rzze+sg/BjrwEqPd1+1hbvlzqIKDHH HJ7Q== X-Gm-Message-State: AMCzsaWSsBx7aQpt4scyfQLT9x4EqiexEMF7nSnAQFdoWxHwGiFceBGZ UfluN0NZiQ2JGRMQkMoo1cL5ZGP0 X-Google-Smtp-Source: ABhQp+TE2iu8p12e4YiK8sMvAQEPXk0wTFmkmbuSsadkAaRp5UNbPRLEtd/byvXH0WWAvrDRjM2cVA== X-Received: by 10.223.145.165 with SMTP id 34mr5952931wri.140.1509062371892; Thu, 26 Oct 2017 16:59:31 -0700 (PDT) Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id v15sm647311wmf.25.2017.10.26.16.59.30 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 26 Oct 2017 16:59:31 -0700 (PDT) From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> <87a80fvte2.fsf@gmail.com> <83y3nx7tdn.fsf@gnu.org> Date: Fri, 27 Oct 2017 00:59:28 +0100 In-Reply-To: <83y3nx7tdn.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 26 Oct 2017 19:42:44 +0300") Message-ID: <873765wjdr.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Eli Zaretskii writes: > A few comments to the documentation: > > . Please proofread the text for UK English spellings (e.g., "honour") > and only one space between sentences. Done. > . I don't understand the reason for such extensive changes in the > manual. Most of them look purely stylistic, and I see no problems > with the original text to justify that. Here are the (minor) problems I detected: - In node "Looking up identifiers" there are is a repeated explanation of what motivates a *xref* buffer (lines 1831 and 1863). I think its clearer if this only happens once, so I merged the two. - When the text in the same node talks about RET, I took that opportunity to mention existing C-o binding and the proposed TAB binding. This adds information. - Finally, I changed "To go back to places @emph{from where} you found the definition" to "Once you are at the definition, you may want to go back to places @{from where}". This is indeed purely stylistic, but I thought it was a less abrupt transition from the preceding paragraph that talks about going to definitions. The change looks larger than it really is because of the paragraph filling, but I did only change the first sentence. - A real problem is that the description for RET in the node "Xref Commands" incorrectly states that RET buries the *xref* buffer, which we know it doesn't. > What did I miss? Nothing, I just thought this improved the manual slightly. Tell me which parts, maybe all, you think I should scrap. (though I do believe updates to the "Xref Commands" node are in order) > I don't see a need for a NEWS entry. If this is a > bugfix, then it doesn't belong there, as we don't describe bugfixes in > NEWS (there are too many to describe). I didn't know that, sorry. Apart from the bugfix there is also the new quit-and-jump behaviour, but maybe also not worth it. Your call. From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) 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: Fri, 27 Oct 2017 00:07: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 To: Dmitry Gutov Cc: Eli Zaretskii , 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150906276820193 (code B ref 28814); Fri, 27 Oct 2017 00:07:02 +0000 Received: (at 28814) by debbugs.gnu.org; 27 Oct 2017 00:06:08 +0000 Received: from localhost ([127.0.0.1]:35767 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7sA4-0005Fd-5J for submit@debbugs.gnu.org; Thu, 26 Oct 2017 20:06:08 -0400 Received: from mail-wm0-f47.google.com ([74.125.82.47]:55051) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7sA0-0005F7-6s for 28814@debbugs.gnu.org; Thu, 26 Oct 2017 20:06:04 -0400 Received: by mail-wm0-f47.google.com with SMTP id r68so561554wmr.3 for <28814@debbugs.gnu.org>; Thu, 26 Oct 2017 17:06:04 -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; bh=autRN9S/J58q1mJ5MILIcl7RrE+oP1EDQJUONnyig/w=; b=gEDM6pL7yKAFUuVg4Aufi0i0ZWpYA4o7vVCno+C538yGMZ3DowrDpWJAWccUHpexUj FXr/d87rFXE50wWoqzA51bwNok34n0FGRQU+pli0c8Ui5qeV4gkg0BBNs3jGquMITGft +3vjsPKq2f/A1GSV2EWkV26eedq4pvDlg9+pgOWer9vImw1m78GPynE4te6FFaAvncmI Z4vkTZ2r4Q9wnbTApsbITD0lq/xj6FVTwqgHQEPA8tGBR8GB1iybPwsF3JEnm/23k2iK 3PI+L3NzNUvRR2RTJjtiE8VQjVRPTK2S38H/hWgqY/G6VLnaXA4GiSDmOMVbXprH939H 5Rrw== 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; bh=autRN9S/J58q1mJ5MILIcl7RrE+oP1EDQJUONnyig/w=; b=ZG3xF1GoS9KTeOjVYikFWnfKYMEtQVzfQwmLKN2C4Q3OxdrWx9E8nRGLFeinhK0DmG +UzQ4nUDy/no8a94l4+t2zfW2SbZbCMCHyGQQrD+jImXcJnNcwEUCpV87aYFRZTFBF5/ wa49BDzGRaQKe9y1V8XSnhTLUG73COqm1YSvw9eaJO3VSyDkOLsRxKqFT1TNTZzFi5f0 TK+zyzPWtUCPYljDI8WB+JyygpbPQzuqo/VQaKv8RWSJmX61EE0LZEnfAxkM1ItM74VK BVZGaj9q+HHKxwxKxtV8KDyl2Ia1fMlspsIefORXb3TKzPBpcbryZVQPei7JDzbLtJkU qqMQ== X-Gm-Message-State: AMCzsaVCnFQ8Xouu867pKbemrJ531jGhXBHtk20Qp0ljctSZJPBMSVDq 95DbosRLLVNBx5HE8FrNHuoIL6/X X-Google-Smtp-Source: ABhQp+SZHiVvlL+aNpfeGhGsGwr3Fc0kh8L962VX62LRd0TBJBR+QYQluABOgN1UDyYsn3Pl5lJSDw== X-Received: by 10.28.6.6 with SMTP id 6mr430747wmg.114.1509062758196; Thu, 26 Oct 2017 17:05:58 -0700 (PDT) Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id m126sm441202wmf.31.2017.10.26.17.05.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 26 Oct 2017 17:05:57 -0700 (PDT) From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> <87a80fvte2.fsf@gmail.com> <83y3nx7tdn.fsf@gnu.org> <73791641-aab2-69ff-6cbb-a9738c868802@yandex.ru> Date: Fri, 27 Oct 2017 01:05:54 +0100 In-Reply-To: <73791641-aab2-69ff-6cbb-a9738c868802@yandex.ru> (Dmitry Gutov's message of "Fri, 27 Oct 2017 01:40:48 +0300") Message-ID: <87y3nxv4il.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Dmitry Gutov writes: > On 10/26/17 7:42 PM, Eli Zaretskii wrote: > >> If Dmitry doesn't like 'Q', I'm not wedded to it. Feel free to change >> the keybinding. > > Thanks. OK, scrap 'Q', keep 'TAB'. >> Dmitry, what's your opinion? > > IMO, not a bugfix, but I don't mind getting the changes in and seeing > how many people disapprove during the pretest. I think the C-x 4 . and C-x 5 . thing is indeed a bugfix and should go into emacs-26. The xref-quit-and-goto-xref is just a new feature, so stricly it should go to master. I'm fine either way, really. I think if these things are in emacs-26 they will increase visibility to this relatively new feature, but since I'm mostly scratching my own itch I don't mind if they go to emacs-27. From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Oct 2017 09:42: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 To: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) Cc: 28814@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150918370811385 (code B ref 28814); Sat, 28 Oct 2017 09:42:02 +0000 Received: (at 28814) by debbugs.gnu.org; 28 Oct 2017 09:41:48 +0000 Received: from localhost ([127.0.0.1]:38059 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e8Nci-0002xZ-Et for submit@debbugs.gnu.org; Sat, 28 Oct 2017 05:41:48 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39284) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e8Ncf-0002xM-C4 for 28814@debbugs.gnu.org; Sat, 28 Oct 2017 05:41:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e8NcX-0001dL-1c for 28814@debbugs.gnu.org; Sat, 28 Oct 2017 05:41:40 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46360) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e8NcW-0001dH-Tt; Sat, 28 Oct 2017 05:41:36 -0400 Received: from [176.228.60.248] (port=4501 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1e8NcW-00008w-0z; Sat, 28 Oct 2017 05:41:36 -0400 Date: Sat, 28 Oct 2017 12:41:31 +0300 Message-Id: <83r2tn6244.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <873765wjdr.fsf@gmail.com> (joaotavora@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> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> <87a80fvte2.fsf@gmail.com> <83y3nx7tdn.fsf@gnu.org> <873765wjdr.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: joaotavora@gmail.com (João Távora) > Cc: dgutov@yandex.ru, 28814@debbugs.gnu.org > Date: Fri, 27 Oct 2017 00:59:28 +0100 > > - In node "Looking up identifiers" there are is a repeated explanation > of what motivates a *xref* buffer (lines 1831 and 1863). I think its > clearer if this only happens once, so I merged the two. People who use the manual as a reference seldom read the entire node. Instead, they read the description of the single subject they were looking for, and move on. If the reader was only interested in reading about "M-.", with your version she will not see the description of the XREF buffer, unless she reads on. So I don't think the repetition here is a bad idea, especially since it doesn't really repeat the same text. > - Finally, I changed "To go back to places @emph{from where} you found > the definition" to "Once you are at the definition, you may want to go > back to places @{from where}". This is indeed purely stylistic, but I > thought it was a less abrupt transition from the preceding paragraph > that talks about going to definitions. The change looks larger than it > really is because of the paragraph filling, but I did only change the > first sentence. When the original style is clear and unambiguous, I usually avoid changing it, because style preferences are personal. The additions for the new and changed bindings are, of course, okay, that wasn't what prompted my comment. Please show the final patch with the above comments fixed, and I think it's okay to put this on emacs-26 after all. Thanks. From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) 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: Sat, 28 Oct 2017 19:20: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 To: Eli Zaretskii Cc: 28814@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150921835317353 (code B ref 28814); Sat, 28 Oct 2017 19:20:01 +0000 Received: (at 28814) by debbugs.gnu.org; 28 Oct 2017 19:19:13 +0000 Received: from localhost ([127.0.0.1]:39490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e8WdT-0004Vo-S7 for submit@debbugs.gnu.org; Sat, 28 Oct 2017 15:19:12 -0400 Received: from mail-wm0-f45.google.com ([74.125.82.45]:51217) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e8WdR-0004Va-Kq for 28814@debbugs.gnu.org; Sat, 28 Oct 2017 15:19:10 -0400 Received: by mail-wm0-f45.google.com with SMTP id b9so9226276wmh.0 for <28814@debbugs.gnu.org>; Sat, 28 Oct 2017 12:19:09 -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; bh=8chGTrkbvgfoJ8MEB8rxzJpKTOMRoII5KMP4+FC/6GM=; b=OL14WJtxetJWaWkEMDBcuz0tHuG0gBKLGcPotYkzh8P5Fj5Kw81/uM/fIxtd4Netgv drC8C0wOelz9qLmOAI6YaJBmTymIOjT0u3CvoIkzU7/EQwZEJ04fVjMznUNuWu6+YTAm R7SpD3ITkCQGHq1XlD7iRknv2OZgkkNd7ry4IUUIVOPmlNheYvyilqHHqt7s64Syo8IK LeY5JMeucNR2yJqXUwDd9dZBsFDpPvi5TAbXDykjqR0EMzoPFjOYlPbSa0UngK+yP3oK wxCVUvejKQZ+P6cicFDp2/7/Bd2xGIHVuToqoi3ft7pFxdMHY8XN5iHRK+9BCIr14lp9 Xvlw== 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; bh=8chGTrkbvgfoJ8MEB8rxzJpKTOMRoII5KMP4+FC/6GM=; b=DTiSah7HS0DRK1uHVBhToQQgyRU3sb9Go6IAm1MmArJpcxCwtqXBWJm2JSrhbWXUam QZdJaf4jsE7kVIJrrv4fdCUu2mmLTswsDoCEJ+HIwuuSO1zCfe87DBnfy7O4r8uqJkGV hADK4f05hpbDV3wdBd8FxbgWg0a4RtdzcPKnHedMmaaXFA0BZ13iAQg25HX0v4+GCb3J FFFlSjw2E5GflP0xmljtdXZ46Q709PiE3gwGiaO3Vz6jEOJMSENjyyrB43pG7icbMamp kT44mEdazHUtg66D1bjN2a57ESz7XcEZAe3bxv3nNJKgfuy61luL8CVz8xWOen0TV4ay 3NzQ== X-Gm-Message-State: AMCzsaVY6P8LlYE8WXWx1cKT5bkSXx9bpl5NjOuNxmRUkL5+XALSC8uD KUKGiBvu5Q/vXkZ5vJzRcb42HypJ X-Google-Smtp-Source: ABhQp+RzxNW9h64oQqJX5rWxpr/tk2+Ckx8FxTf/PmPRvrRwNsNppiXW0kpp59x/TWA3t5lUudHh7Q== X-Received: by 10.28.165.150 with SMTP id o144mr76672wme.31.1509218343525; Sat, 28 Oct 2017 12:19:03 -0700 (PDT) Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id w190sm59087wmf.40.2017.10.28.12.19.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 28 Oct 2017 12:19:02 -0700 (PDT) From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> <87a80fvte2.fsf@gmail.com> <83y3nx7tdn.fsf@gnu.org> <873765wjdr.fsf@gmail.com> <83r2tn6244.fsf@gnu.org> Date: Sat, 28 Oct 2017 20:19:00 +0100 In-Reply-To: <83r2tn6244.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 28 Oct 2017 12:41:31 +0300") Message-ID: <87o9orulln.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o?= =?UTF-8?Q?T=C3=A1vora?=) >> Cc: dgutov@yandex.ru, 28814@debbugs.gnu.org >> Date: Fri, 27 Oct 2017 00:59:28 +0100 >> >> - In node "Looking up identifiers" there are is a repeated explanation >> of what motivates a *xref* buffer (lines 1831 and 1863). I think its >> clearer if this only happens once, so I merged the two. > > People who use the manual as a reference seldom read the entire node. > Instead, they read the description of the single subject they were [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [74.125.82.45 listed in list.dnswl.org] 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [74.125.82.45 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.45 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (joaotavora[at]gmail.com) 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.0 FREEMAIL_REPLY From and body contain different freemails X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> From: joaotavora@gmail.com (Jo=C3=A3o T=C3=A1vora) >> Cc: dgutov@yandex.ru, 28814@debbugs.gnu.org >> Date: Fri, 27 Oct 2017 00:59:28 +0100 >>=20 >> - In node "Looking up identifiers" there are is a repeated explanation >> of what motivates a *xref* buffer (lines 1831 and 1863). I think its >> clearer if this only happens once, so I merged the two. > > People who use the manual as a reference seldom read the entire node. > Instead, they read the description of the single subject they were I think nodes are read from top to bottom, especially if they are short, and this is a good thing. It's a small miracle the manual is so good since it is a giant patchwork of many different writers. Nevertheless it suffers from inconsistent style. I think repetition is very often a symptom of bad style. And I think style isn't some abstract and innocuous thing, it's a carrier for content and carries content in itself. And I think this even more of prose than of code. So here ends my minirant :-) and I hope I fixed everything in these patches. Jo=C3=A3o --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Honor-window-switching-intents-in-xref-find-definiti.patch >From 353d2a44169697772cc0a341edc36a72c8abd9d7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Fri, 13 Oct 2017 15:13:14 +0100 Subject: [PATCH 1/3] Honor window-switching intents in xref-find-definitions (bug#28814) When there is more than one xref to jump to, and an *xref* window appears to help the user choose, the original intent to open a definition in another window or frame is remembered when the choice to go to or show a reference is finally made. * lisp/progmodes/xref.el (xref--show-pos-in-buf): Rewrite. (xref--original-window-intent): New variable. (xref--original-window): Rename from xref--window and move up here for clarity. (xref--show-pos-in-buf): Rewrite. Don't take SELECT arg here. (xref--show-location): Handle window selection decision here. (xref--window): Rename to xref--original-window. (xref-show-location-at-point): Don't attempt window management here. (xref--show-xrefs): Ensure display-action intent is saved. --- lisp/progmodes/xref.el | 69 +++++++++++++++++++++++++++++++++++--------------- 1 file changed, 48 insertions(+), 21 deletions(-) diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 80cdcb3f18..63ef901a9e 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -449,43 +449,68 @@ xref--with-dedicated-window (when xref-w (set-window-dedicated-p xref-w xref-w-dedicated))))) -(defun xref--show-pos-in-buf (pos buf select) - (let ((xref-buf (current-buffer)) - win) +(defvar-local xref--original-window-intent nil + "Original window-switching intent before xref buffer creation.") + +(defvar-local xref--original-window nil + "The original window this xref buffer was created from.") + +(defun xref--show-pos-in-buf (pos buf) + "Goto and display position POS of buffer BUF in a window. +Honor `xref--original-window-intent', run `xref-after-jump-hook' +and finally return the window." + (let* ((xref-buf (current-buffer)) + (pop-up-frames + (or (eq xref--original-window-intent 'frame) + pop-up-frames)) + (action + (cond ((memq + xref--original-window-intent + '(window frame)) + t) + ((and + (window-live-p xref--original-window) + (or (not (window-dedicated-p xref--original-window)) + (eq (window-buffer xref--original-window) buf))) + `(,(lambda (buf _alist) + (set-window-buffer xref--original-window buf) + xref--original-window)))))) (with-selected-window - (xref--with-dedicated-window - (display-buffer buf)) + (with-selected-window + ;; Just before `display-buffer', place ourselves in the + ;; original window to suggest preserving it. Of course, if + ;; user has deleted the original window, all bets are off, + ;; just use the selected one. + (or (and (window-live-p xref--original-window) + xref--original-window) + (selected-window)) + (display-buffer buf action)) (xref--goto-char pos) (run-hooks 'xref-after-jump-hook) (let ((buf (current-buffer))) - (setq win (selected-window)) (with-current-buffer xref-buf - (setq-local other-window-scroll-buffer buf)))) - (when select - (select-window win)))) + (setq-local other-window-scroll-buffer buf))) + (selected-window)))) (defun xref--show-location (location &optional select) (condition-case err (let* ((marker (xref-location-marker location)) (buf (marker-buffer marker))) - (xref--show-pos-in-buf marker buf select)) + (cond (select + (select-window (xref--show-pos-in-buf marker buf))) + (t + (save-selected-window + (xref--with-dedicated-window + (xref--show-pos-in-buf marker buf)))))) (user-error (message (error-message-string err))))) -(defvar-local xref--window nil - "The original window this xref buffer was created from.") - (defun xref-show-location-at-point () "Display the source of xref at point in the appropriate window, if any." (interactive) (let* ((xref (xref--item-at-point)) (xref--current-item xref)) (when xref - ;; Try to avoid the window the current xref buffer was - ;; originally created from. - (if (window-live-p xref--window) - (with-selected-window xref--window - (xref--show-location (xref-item-location xref))) - (xref--show-location (xref-item-location xref)))))) + (xref--show-location (xref-item-location xref))))) (defun xref-next-line () "Move to the next xref and display its source in the appropriate window." @@ -727,7 +752,8 @@ xref--show-xref-buffer (xref--xref-buffer-mode) (pop-to-buffer (current-buffer)) (goto-char (point-min)) - (setq xref--window (assoc-default 'window alist)) + (setq xref--original-window (assoc-default 'window alist) + xref--original-window-intent (assoc-default 'display-action alist)) (current-buffer))))) @@ -754,7 +780,8 @@ xref--show-xrefs (t (xref-push-marker-stack) (funcall xref-show-xrefs-function xrefs - `((window . ,(selected-window))))))) + `((window . ,(selected-window)) + (display-action . ,display-action)))))) (defun xref--prompt-p (command) (or (eq xref-prompt-for-identifier t) -- 2.14.2 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0002-Allow-split-window-sensibly-to-split-threshold-in-fu.patch >From ee52f73d441577d1beb48f9d7c5c3ce3f26a48ed Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Mon, 23 Oct 2017 09:05:32 +0100 Subject: [PATCH 2/3] Allow split-window-sensibly to split threshold in further edge case As a fallback, and to avoid creating a frame, split-window-sensibly would previously disregard split-height-threshold if the window to be split is the frame's root window. This change generalizes that: it disregards the threshold if the window to be split is the frame's only _usable_ window (it is either the only one, as before, or all the other windows are dedicated to some buffer and thus cannot be touched). This is required for the fix to bug#28814. * lisp/window.el (split-height-threshold): Adjust doc to match split-window-sensibly. (split-window-sensibly): Also disregard threshold if all other windows are dedicated. --- lisp/window.el | 35 ++++++++++++++++++++++++----------- 1 file changed, 24 insertions(+), 11 deletions(-) diff --git a/lisp/window.el b/lisp/window.el index c0a9ecd093..4814d12400 100644 --- a/lisp/window.el +++ b/lisp/window.el @@ -6465,8 +6465,9 @@ split-height-threshold vertically only if it has at least this many lines. If this is nil, `split-window-sensibly' is not allowed to split a window vertically. If, however, a window is the only window on its -frame, `split-window-sensibly' may split it vertically -disregarding the value of this variable." +frame, or all the other ones are dedicated, +`split-window-sensibly' may split it vertically disregarding the +value of this variable." :type '(choice (const nil) (integer :tag "lines")) :version "23.1" :group 'windows) @@ -6573,15 +6574,27 @@ split-window-sensibly ;; Split window horizontally. (with-selected-window window (split-window-right))) - (and (eq window (frame-root-window (window-frame window))) - (not (window-minibuffer-p window)) - ;; If WINDOW is the only window on its frame and is not the - ;; minibuffer window, try to split it vertically disregarding - ;; the value of `split-height-threshold'. - (let ((split-height-threshold 0)) - (when (window-splittable-p window) - (with-selected-window window - (split-window-below)))))))) + (and + ;; If WINDOW is the only usable window on its frame (it is + ;; the only one or, not being the only one, all the other + ;; ones are dedicated) and is not the minibuffer window, try + ;; to split it vertically disregarding the value of + ;; `split-height-threshold'. + (let ((frame (window-frame window))) + (or + (eq window (frame-root-window frame)) + (catch 'done + (walk-window-tree (lambda (w) + (unless (or (eq w window) + (window-dedicated-p w)) + (throw 'done nil))) + frame) + t))) + (not (window-minibuffer-p window)) + (let ((split-height-threshold 0)) + (when (window-splittable-p window) + (with-selected-window window + (split-window-below)))))))) (defun window--try-to-split-window (window &optional alist) "Try to split WINDOW. -- 2.14.2 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0003-New-xref-quit-and-goto-xref-command-bound-to-TAB-bug.patch >From 6c5191316688ccf50c1874b976b1f66741a900ff Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Fri, 13 Oct 2017 16:37:47 +0100 Subject: [PATCH 3/3] New xref-quit-and-goto-xref command bound to TAB (bug#28814) This is like xref-goto-xref, but quits the *xref* window just before the user jump to ref. * lisp/progmodes/xref.el (xref--show-location): Handle 'quit value for SELECT. (xref-goto-xref): Take optional QUIT arg. (xref-quit-and-goto-xref): New command. (xref--xref-buffer-mode-map): Bind "Q" and "TAB" to xref-quit-and-goto-xref. * doc/emacs/maintaining.texi (Xref Commands): Describe new bindings in *xref*. * etc/NEWS (Xref): Describe new binding. --- doc/emacs/maintaining.texi | 7 +++++-- etc/NEWS | 10 ++++++++++ lisp/progmodes/xref.el | 24 +++++++++++++++++++----- 3 files changed, 34 insertions(+), 7 deletions(-) diff --git a/doc/emacs/maintaining.texi b/doc/emacs/maintaining.texi index dc0a71511f..112f1f4d9e 100644 --- a/doc/emacs/maintaining.texi +++ b/doc/emacs/maintaining.texi @@ -1887,8 +1887,7 @@ Xref Commands @table @kbd @item @key{RET} @itemx mouse-2 -Display the reference on the current line and bury the @file{*xref*} -buffer. +Display the reference on the current line. @item n @itemx . @findex xref-next-line @@ -1903,6 +1902,10 @@ Xref Commands @findex xref-show-location-at-point Display the reference on the current line in the other window (@code{xref-show-location-at-point}). +@item TAB +@findex xref-quit-and-goto-xref +Display the reference on the current line and bury the @file{*xref*} +buffer (@code{xref-quit-and-goto-xref}). @findex xref-query-replace-in-results @item r @var{pattern} @key{RET} @var{replacement} @key{RET} Perform interactive query-replace on references that match diff --git a/etc/NEWS b/etc/NEWS index 82778932ab..561a15dbd7 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1185,6 +1185,16 @@ New user options `term-char-mode-buffer-read-only' and are non-nil by default. Customize these options to nil if you want the previous behavior. +** Xref + ++++ +*** When an *xref* buffer is needed, 'TAB' quits and jumps to an xref + +A new command 'xref-quit-and-goto-xref', bound to 'TAB' in *xref* +buffers, quits the window before jumping to the destination. In many +situations, the intended window configuration is restored, just as if +the *xref* buffer hadn't been necessary in the first place. + * New Modes and Packages in Emacs 26.1 diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 63ef901a9e..623fd5eb25 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -493,11 +493,17 @@ xref--show-pos-in-buf (selected-window)))) (defun xref--show-location (location &optional select) + "Helper for `xref-show-xref' and `xref-goto-xref'. +Go to LOCATION and if SELECT is non-nil select its window. If +SELECT is `quit', also quit the *xref* window." (condition-case err (let* ((marker (xref-location-marker location)) - (buf (marker-buffer marker))) + (buf (marker-buffer marker)) + (xref-buffer (current-buffer))) (cond (select - (select-window (xref--show-pos-in-buf marker buf))) + (if (eq select 'quit) (quit-window nil nil)) + (with-current-buffer xref-buffer + (select-window (xref--show-pos-in-buf marker buf)))) (t (save-selected-window (xref--with-dedicated-window @@ -529,12 +535,19 @@ xref--item-at-point (back-to-indentation) (get-text-property (point) 'xref-item))) -(defun xref-goto-xref () - "Jump to the xref on the current line and select its window." +(defun xref-goto-xref (&optional quit) + "Jump to the xref on the current line and select its window. +Non-interactively, non-nil QUIT says to first quit the *xref* +buffer." (interactive) (let ((xref (or (xref--item-at-point) (user-error "No reference at point")))) - (xref--show-location (xref-item-location xref) t))) + (xref--show-location (xref-item-location xref) (if quit 'quit t)))) + +(defun xref-quit-and-goto-xref () + "Quit *xref* buffer, then jump to xref on current line." + (interactive) + (xref-goto-xref t)) (defun xref-query-replace-in-results (from to) "Perform interactive replacement of FROM with TO in all displayed xrefs. @@ -658,6 +671,7 @@ xref--xref-buffer-mode-map (define-key map (kbd "p") #'xref-prev-line) (define-key map (kbd "r") #'xref-query-replace-in-results) (define-key map (kbd "RET") #'xref-goto-xref) + (define-key map (kbd "TAB") #'xref-quit-and-goto-xref) (define-key map (kbd "C-o") #'xref-show-location-at-point) ;; suggested by Johan Claesson "to further reduce finger movement": (define-key map (kbd ".") #'xref-next-line) -- 2.14.2 --=-=-=-- From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: =?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: Thu, 02 Nov 2017 17:04: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 To: Eli Zaretskii Cc: 28814@debbugs.gnu.org, Dmitry Gutov Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.15096422278293 (code B ref 28814); Thu, 02 Nov 2017 17:04:01 +0000 Received: (at 28814) by debbugs.gnu.org; 2 Nov 2017 17:03:47 +0000 Received: from localhost ([127.0.0.1]:48160 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAIuA-00029g-TM for submit@debbugs.gnu.org; Thu, 02 Nov 2017 13:03:47 -0400 Received: from mail-qk0-f196.google.com ([209.85.220.196]:48935) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAIu9-00029U-Kf for 28814@debbugs.gnu.org; Thu, 02 Nov 2017 13:03:45 -0400 Received: by mail-qk0-f196.google.com with SMTP id d67so234351qkg.5 for <28814@debbugs.gnu.org>; Thu, 02 Nov 2017 10:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9dMi+Y/dpyIFCqAecz7zV58gkFvAne1uxsId9CRJsUM=; b=GALTmO4x6zn4LKLwORO6Rg/KZZ4+r9DnwcYVKlUgB3AAGgL6wXH+X5UGMwJBaPmrF3 W2gee2p6ZBwdTaIdFOpYS063WUk6bUXJUSrvarWpLUIDVRhAeyuG9hnr8XPv90qR0n5i 9e+C45KQlhoeYzd/pbHL9W/+TqspP4CJa0T5GOtYQQWBS/EbjubWym6+OcKTxPinQhAQ O//9mtNDWdWfWbMwWQLllxhiPvsk3HCsN+2dpVoKTj01oB7HDrpcwG5B5fgSwOSlwBZo DKEPpZWRzNe1H6QP5VQU7uITkzpRc47mYG4HwBYQWr9OLzsRUojusz0+nhF6XwCxLAje nehQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9dMi+Y/dpyIFCqAecz7zV58gkFvAne1uxsId9CRJsUM=; b=XVOIgZ8GjYNAocdIzf4sp6nlW7Wj4Ae8bo8H6SLDX53ThV8qKQ/fuSCVssYGIewBX6 cWmORoewXrgBcsaA3VKi4mK+HJEwB3g2eKI/Lzrhe1my3+04ctwHQhMGRXXk6fT3ku1o SdBjyJKSAekcu9i6zVFVVzLRdb4WU9P2R9B+Mf9BQyvnNQVS/jFxD8IoH4fQVyLy2jWE 9EypTVWUIyDhc2jVOeMb70rj1CiaVpyLxTnVs2QX6Xiem7JZ2pOCXDA02Rd/ycEfIPyD Uwwb4qlqukvaJsCnlTX9KfohIhYjRLfhqHDiXcf6MfJmm5Q3/NsX9hgNwqwRDKyYG3m1 VR9w== X-Gm-Message-State: AJaThX4tBSnmgJUh+F1uygv+rZb5haRGQqWxNjg48NSiq4E9V1v61W/8 vhwJF+yh7NslRux/xvraI46dCLLO0imCFAbAeuo= X-Google-Smtp-Source: ABhQp+Q9ubq8ZnJj2HdjaySqV0MiZY9yP+nTlTkrvLCZ5VU89Oo9Oe/vGb7TUIGjTkPnWSO+pbLrE3LHoyvQzbZzRPg= X-Received: by 10.55.167.22 with SMTP id q22mr5711388qke.234.1509642218680; Thu, 02 Nov 2017 10:03:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.145.228 with HTTP; Thu, 2 Nov 2017 10:03:18 -0700 (PDT) In-Reply-To: <87o9orulln.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> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> <87a80fvte2.fsf@gmail.com> <83y3nx7tdn.fsf@gnu.org> <873765wjdr.fsf@gmail.com> <83r2tn6244.fsf@gnu.org> <87o9orulln.fsf@gmail.com> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Thu, 2 Nov 2017 17:03:18 +0000 Message-ID: Content-Type: multipart/alternative; boundary="001a114fbc8c2eb5f2055d02f8da" X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Ping. This was very close to wrapping up and so I wonder if you had a chance to look at the patches... I hope my rant isn't putting you off, because it's just that, an opinion, a data point. I did fix all the parts according to your comments, I believe. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.220.196 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.220.196 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (joaotavora[at]gmail.com) -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.220.196 listed in wl.mailspike.net] 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.0 FREEMAIL_REPLY From and body contain different freemails X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) --001a114fbc8c2eb5f2055d02f8da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ping. This was very close to wrapping up and so I wonder if you had a chance to look at the patches... I hope my rant isn't putting you off, because it's just that, an opinion, a data point. I did fix all the parts according to your comments, I believe. It's only the last patch with the doc changes that changed significantly since the last time you looked. Jo=C3=A3o On Sat, Oct 28, 2017 at 8:19 PM, Jo=C3=A3o T=C3=A1vora wrote: > Eli Zaretskii writes: > > >> From: joaotavora@gmail.com (Jo=C3=A3o T=C3=A1vora) > >> Cc: dgutov@yandex.ru, 28814@debbugs.gnu.org > >> Date: Fri, 27 Oct 2017 00:59:28 +0100 > >> > >> - In node "Looking up identifiers" there are is a repeated explanation > >> of what motivates a *xref* buffer (lines 1831 and 1863). I think its > >> clearer if this only happens once, so I merged the two. > > > > People who use the manual as a reference seldom read the entire node. > > Instead, they read the description of the single subject they were > > I think nodes are read from top to bottom, especially if they are short, > and this is a good thing. It's a small miracle the manual is so good > since it is a giant patchwork of many different writers. Nevertheless > it suffers from inconsistent style. I think repetition is very often a > symptom of bad style. And I think style isn't some abstract and > innocuous thing, it's a carrier for content and carries content in > itself. And I think this even more of prose than of code. > > So here ends my minirant :-) and I hope I fixed everything in these > patches. > > Jo=C3=A3o > > --=20 Jo=C3=A3o T=C3=A1vora --001a114fbc8c2eb5f2055d02f8da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ping. This was very close to wrapping up and so I wonder i= f you=C2=A0
had a chance to look at the patches...

=
I hope my rant isn't putting you off, because it's just t= hat, an=C2=A0
opinion, a data point. I did fix all the parts acco= rding to your comments,=C2=A0
I believe.
It's only the last patch with the doc changes that changed = significantly=C2=A0
since the last time you looked.
Jo=C3=A3o


On Sat, Oct 28, 2017 at 8:19 PM, Jo=C3= =A3o T=C3=A1vora <joaotavora@gmail.com> wrote:
Eli Zaretskii <eliz@gnu.org> writes:

>> From: joaotavora@gmail.com= (Jo=C3=A3o T=C3=A1vora)
>> Cc: dgutov@yandex.ru,=C2= =A0 28814@debbugs.gnu.org
>> Date: Fri, 27 Oct 2017 00:59:28 +0100
>>
>> - In node "Looking up identifiers" there are is a repeat= ed explanation
>> of what motivates a *xref* buffer (lines 1831 and 1863). I think i= ts
>> clearer if this only happens once, so I merged the two.
>
> People who use the manual as a reference seldom read the entire node.<= br> > Instead, they read the description of the single subject they were

I think nodes are read from top to bottom, especially if they are sh= ort,
and this is a good thing.=C2=A0 It's a small miracle the manual is so g= ood
since it is a giant patchwork of many different writers.=C2=A0 Nevertheless=
it suffers from inconsistent style.=C2=A0 I think repetition is very often = a
symptom of bad style.=C2=A0 And I think style isn't some abstract and innocuous thing, it's a carrier for content and carries content in
itself.=C2=A0 And I think this even more of prose than of code.

So here ends my minirant :-) and I hope I fixed everything in these
patches.

Jo=C3=A3o




--
Jo=C3= =A3o T=C3=A1vora
--001a114fbc8c2eb5f2055d02f8da-- From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Nov 2017 17:07: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 To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Eli Zaretskii , 28814@debbugs.gnu.org Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.15096424168577 (code B ref 28814); Thu, 02 Nov 2017 17:07:02 +0000 Received: (at 28814) by debbugs.gnu.org; 2 Nov 2017 17:06:56 +0000 Received: from localhost ([127.0.0.1]:48164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAIxE-0002EH-Hf for submit@debbugs.gnu.org; Thu, 02 Nov 2017 13:06:56 -0400 Received: from mail-wr0-f182.google.com ([209.85.128.182]:47135) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAIxC-0002E6-IJ for 28814@debbugs.gnu.org; Thu, 02 Nov 2017 13:06:54 -0400 Received: by mail-wr0-f182.google.com with SMTP id y39so211048wrd.4 for <28814@debbugs.gnu.org>; Thu, 02 Nov 2017 10:06:54 -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=4wGeN8zNOT7M6rnWIYY6GpNoHpXZVokc52MOHDe9CIM=; b=M6TOnrhbj8W0z5xsWSji1B/G5BxaVhfnfL/eifjBwVsur0QY/CHK8F6UUYIQXGnNBD g5f30veAHr8sbtub/mgXjyuhTLVW3qmbQrydJVZX/nvJsUp/VHLYic3h0CPY+CgKK34i FGRSG8Apw3ttTWTrAPgOSdFertNDCUK5jjZjmWmsoC2LUr1f+FYqueOlGTXswCCPyS9V rkY+LwXE/y/4Sv9F8ri6pGkXU0efCsadDBdSZYdW1w6MTZrSRUtbgH1wyHATZLDQgGH7 Fwe6PCwrQoRRNrEO3dmI5x6gs26Tbx2JDXsbh0UxxvjeHo7C7ggEZydV0B34kvRPVK79 hIrQ== 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=4wGeN8zNOT7M6rnWIYY6GpNoHpXZVokc52MOHDe9CIM=; b=t4P9kumjeV46aC7Q9sviypNzIMR6/HMz+nXWJGpREe9FLvDDGzOM9In6Y75Fd5VdBq EwXeV5xI9p2ZpaIMUwCUFEuASS+EcfzPF8d8N/uotL4ImBDe2Pk9Mhqv4xoGxLyuKXZP Ap2yGITC2JZEfjFyW/IZlpSJlMX683Ne1FHHDFXZEHly1JW/eT7NWzswnRadNPSt1vCr b7dBcOb4GauS83MemQ0+uXRiLKQIwsxTiV6J6hjlR1JM7hU6fsBZDCHM4LZqb8H0Az4I YGft/s+iVHdjVwA8nEwDK+AJSrkWqmm4oxFrqYaIxVIRx2iPhd9sy4RbENPQNRVT3FS4 HECw== X-Gm-Message-State: AMCzsaWswa1DroreBB94eCTBpg+u0n+ioaJZTS2Fwit5dd07hx9YmKsa OEnWy74d2fDgx647M6wnx9GfceWv X-Google-Smtp-Source: ABhQp+Rpnn58jLj7VE2OCjmfdCPOlv9hCe2IFqsGpMo3I/L6iMCYacIvyp3op3YB4QWk04w0Oe1lJA== X-Received: by 10.223.171.161 with SMTP id s30mr3436425wrc.194.1509642408171; Thu, 02 Nov 2017 10:06:48 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id p49sm7921933wrc.61.2017.11.02.10.06.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 10:06:46 -0700 (PDT) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> <87a80fvte2.fsf@gmail.com> <83y3nx7tdn.fsf@gnu.org> <73791641-aab2-69ff-6cbb-a9738c868802@yandex.ru> <87y3nxv4il.fsf@gmail.com> From: Dmitry Gutov Message-ID: <3d7f053a-7861-22d6-1415-eb406e7662f0@yandex.ru> Date: Thu, 2 Nov 2017 19:06:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <87y3nxv4il.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) On 10/27/17 3:05 AM, João Távora wrote: > OK, scrap 'Q', keep 'TAB'. TAB is an interesting choice, BTW. Let's try it. From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Nov 2017 17:09: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 To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 28814@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.15096424898711 (code B ref 28814); Thu, 02 Nov 2017 17:09:01 +0000 Received: (at 28814) by debbugs.gnu.org; 2 Nov 2017 17:08:09 +0000 Received: from localhost ([127.0.0.1]:48168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAIyN-0002GP-Ts for submit@debbugs.gnu.org; Thu, 02 Nov 2017 13:08:09 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60493) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAIyL-0002Ft-Oh for 28814@debbugs.gnu.org; Thu, 02 Nov 2017 13:08:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAIyB-0000Bw-TU for 28814@debbugs.gnu.org; Thu, 02 Nov 2017 13:08:00 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55670) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAIyB-0000Bo-PY; Thu, 02 Nov 2017 13:07:55 -0400 Received: from [176.228.60.248] (port=3673 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eAIyB-00054T-Ak; Thu, 02 Nov 2017 13:07:55 -0400 Date: Thu, 02 Nov 2017 19:07:48 +0200 Message-Id: <83o9okr4m3.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Thu, 2 Nov 2017 17:03:18 +0000) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> <87a80fvte2.fsf@gmail.com> <83y3nx7tdn.fsf@gnu.org> <873765wjdr.fsf@gmail.com> <83r2tn6244.fsf@gnu.org> <87o9orulln.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: João Távora > Date: Thu, 2 Nov 2017 17:03:18 +0000 > Cc: Dmitry Gutov , 28814@debbugs.gnu.org > > Ping. This was very close to wrapping up and so I wonder if you > had a chance to look at the patches... Your opinion on the amount of free time I have is too optimistic... Don't worry, I didn't forget, and will get to this soon. From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: =?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: Thu, 02 Nov 2017 19:08: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 To: Eli Zaretskii Cc: 28814@debbugs.gnu.org, Dmitry Gutov Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150964964919730 (code B ref 28814); Thu, 02 Nov 2017 19:08:02 +0000 Received: (at 28814) by debbugs.gnu.org; 2 Nov 2017 19:07:29 +0000 Received: from localhost ([127.0.0.1]:48242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAKps-00058A-ML for submit@debbugs.gnu.org; Thu, 02 Nov 2017 15:07:28 -0400 Received: from mail-qt0-f175.google.com ([209.85.216.175]:51006) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAKpq-00057x-B0 for 28814@debbugs.gnu.org; Thu, 02 Nov 2017 15:07:26 -0400 Received: by mail-qt0-f175.google.com with SMTP id d9so658104qtd.7 for <28814@debbugs.gnu.org>; Thu, 02 Nov 2017 12:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CTh21rLSrRZGHCHQncaMz/51iZiXVCBuWCpkVeuIBc4=; b=UZPNdHW6Bs/4aAuUHv6HaqX+zH3r8wZSRrY3Ol4twesP/iKdLm4azYiSqznFynhLN/ hOits390YhypsRlB6MPx4OXlYDKv4cuDyymtHGursSlyd91Ngcb8HLmUO8EtlyIiFY/M ngdSKZNN+xlNYru0wNzwvNmTxosMkZUx4GHLuJ9w/2YuznDJ0oAKUAlbRxWWdbKJZCr1 3hiZ0HbBi/iWK6ns0WXRO7bNk07srQNmeGsxriU/2uE3yefOgxbFVnyuBDuipt7mgfRL hf1jbzhta/fDVnb0G6kPag7chc3XDzNRvBco4y5eJYp3ZS15cDSaAFgFZplqzG2q3N3g Njig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CTh21rLSrRZGHCHQncaMz/51iZiXVCBuWCpkVeuIBc4=; b=D7++/DkBYpWMtwvp5TW9jm9pYGEW6azoA2wzebspDl3Omq6Bi9clHrE++WT1Ul6dJ+ hZdE6poUH7P0Zj/iLBclUPV+Wu/R7Ik7GHALlWLWQLS08/77skID5/Kutgtbm32xnVKd jKmTKu37pvDkTqpULYGRBddg4Z9w2erJJkUKHa4VlqJ5B6AYLj0CNSIIko2tThueRCH9 mkTwROO5sRx+yz8nZLJRSTX7RNFWwlsFw+V4BqTsSXSzalF9WfZLGKv0X2YbW1/kVWZJ nxQ/B5g4rkxnJTu6M1HwEdNq4NdExvoGB+GjG2J61kXlqTdpTlsXhhjvDMptbDMh1cvw lQ6A== X-Gm-Message-State: AMCzsaUQtNcqoJ4731alDsS7wIT3MLWRLjqOofGJYKeh/Y8WwJJ+ClAI aD2J3zkBZ6MgZOCOMr+fcZx34tiVsyAcZKF+gdQ= X-Google-Smtp-Source: ABhQp+RdBMg9nbHxihmeJ3WCMjTyYTXsl3KCtCrXy9jKQ3sCmHYNzbSnc0/KvFiQOB+7+sEdeAQvoPGc/hhJ3mpULHA= X-Received: by 10.200.56.215 with SMTP id g23mr6377193qtc.251.1509649640856; Thu, 02 Nov 2017 12:07:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.145.228 with HTTP; Thu, 2 Nov 2017 12:07:00 -0700 (PDT) In-Reply-To: <83o9okr4m3.fsf@gnu.org> References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> <87a80fvte2.fsf@gmail.com> <83y3nx7tdn.fsf@gnu.org> <873765wjdr.fsf@gmail.com> <83r2tn6244.fsf@gnu.org> <87o9orulln.fsf@gmail.com> <83o9okr4m3.fsf@gnu.org> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Thu, 2 Nov 2017 19:07:00 +0000 Message-ID: Content-Type: multipart/alternative; boundary="001a1143610a942114055d04b24d" X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) --001a1143610a942114055d04b24d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 2, 2017 at 5:07 PM, Eli Zaretskii wrote: > > From: Jo=C3=A3o T=C3=A1vora > > Date: Thu, 2 Nov 2017 17:03:18 +0000 > > Cc: Dmitry Gutov , 28814@debbugs.gnu.org > > > > Ping. This was very close to wrapping up and so I wonder if you > > had a chance to look at the patches... > > Your opinion on the amount of free time I have is too optimistic... > Sorry, I indeed took it from the otherwise quick rhythm of the exchange that it had slipped your queue, but I don't have any kind of opinion on your free time (if anything sometimes I wonder if you guys sleep at all). --=20 Jo=C3=A3o T=C3=A1vora --001a1143610a942114055d04b24d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 2, 2017 at 5:07 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com>
> Date: Thu, 2 Nov 2017 17:03:18 +0000
> Cc: Dmitry Gutov <dgutov@yandex.ru>, 2881= 4@debbugs.gnu.org
>
> Ping. This was very close to wrapping up and s= o I wonder if you
> had a chance to look at the patches...

Your opinion on the amount of free time I have is too optimistic...<= br>

Sorry, I indeed took it from the otherw= ise quick rhythm of the exchange=C2=A0
that it had slipped your q= ueue, but I don't have any kind of opinion on your=C2=A0
free= time (if anything sometimes I wonder if you guys sleep at all).
=
--
Jo=C3=A3o T=C3=A1vora
--001a1143610a942114055d04b24d-- From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Nov 2017 19:33: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 To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 28814@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150965115322182 (code B ref 28814); Thu, 02 Nov 2017 19:33:02 +0000 Received: (at 28814) by debbugs.gnu.org; 2 Nov 2017 19:32:33 +0000 Received: from localhost ([127.0.0.1]:48283 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eALE9-0005li-GT for submit@debbugs.gnu.org; Thu, 02 Nov 2017 15:32:33 -0400 Received: from eggs.gnu.org ([208.118.235.92]:33286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eALE7-0005lU-8Q for 28814@debbugs.gnu.org; Thu, 02 Nov 2017 15:32:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eALDy-0004iE-PA for 28814@debbugs.gnu.org; Thu, 02 Nov 2017 15:32:26 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58387) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eALDy-0004i8-Lj; Thu, 02 Nov 2017 15:32:22 -0400 Received: from [176.228.60.248] (port=3736 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eALDw-0007gu-Ol; Thu, 02 Nov 2017 15:32:22 -0400 Date: Thu, 02 Nov 2017 21:32:04 +0200 Message-Id: <83mv44qxxn.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Thu, 2 Nov 2017 19:07:00 +0000) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> <87a80fvte2.fsf@gmail.com> <83y3nx7tdn.fsf@gnu.org> <873765wjdr.fsf@gmail.com> <83r2tn6244.fsf@gnu.org> <87o9orulln.fsf@gmail.com> <83o9okr4m3.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: João Távora > Date: Thu, 2 Nov 2017 19:07:00 +0000 > Cc: Dmitry Gutov , 28814@debbugs.gnu.org > > sometimes I wonder if you guys sleep at all). If you analyze the time stamps of my postings, you will see... From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Nov 2017 13:48: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 To: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) Cc: 28814@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.15097168565746 (code B ref 28814); Fri, 03 Nov 2017 13:48:01 +0000 Received: (at 28814) by debbugs.gnu.org; 3 Nov 2017 13:47:36 +0000 Received: from localhost ([127.0.0.1]:48900 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAcJr-0001Uc-Vl for submit@debbugs.gnu.org; Fri, 03 Nov 2017 09:47:36 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47406) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAcJr-0001UO-9K for 28814@debbugs.gnu.org; Fri, 03 Nov 2017 09:47:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAcJh-0008Fo-Ag for 28814@debbugs.gnu.org; Fri, 03 Nov 2017 09:47:29 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55939) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAcJh-0008Fi-6e; Fri, 03 Nov 2017 09:47:25 -0400 Received: from [176.228.60.248] (port=2067 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eAcJg-0004oc-Hf; Fri, 03 Nov 2017 09:47:25 -0400 Date: Fri, 03 Nov 2017 15:47:22 +0200 Message-Id: <83lgjnv5hx.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87o9orulln.fsf@gmail.com> (joaotavora@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> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> <87a80fvte2.fsf@gmail.com> <83y3nx7tdn.fsf@gnu.org> <873765wjdr.fsf@gmail.com> <83r2tn6244.fsf@gnu.org> <87o9orulln.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: joaotavora@gmail.com (João Távora) > Cc: dgutov@yandex.ru, 28814@debbugs.gnu.org > Date: Sat, 28 Oct 2017 20:19:00 +0100 > > I hope I fixed everything in these patches. Thanks, let's get this into the emacs-26 branch, after fixing the gotchas below. > diff --git a/etc/NEWS b/etc/NEWS > index 82778932ab..561a15dbd7 100644 > --- a/etc/NEWS > +++ b/etc/NEWS > @@ -1185,6 +1185,16 @@ New user options `term-char-mode-buffer-read-only' and > are non-nil by default. Customize these options to nil if you want > the previous behavior. > > +** Xref > + > ++++ > +*** When an *xref* buffer is needed, 'TAB' quits and jumps to an xref Please end this sentence with a period. > +A new command 'xref-quit-and-goto-xref', bound to 'TAB' in *xref* > +buffers, quits the window before jumping to the destination. In many ^^ Two spaces between sentences, please. > (defun xref--show-location (location &optional select) > + "Helper for `xref-show-xref' and `xref-goto-xref'. > +Go to LOCATION and if SELECT is non-nil select its window. If > +SELECT is `quit', also quit the *xref* window." The first line of every doc string should be a single complete sentence. > +(defun xref-goto-xref (&optional quit) > + "Jump to the xref on the current line and select its window. > +Non-interactively, non-nil QUIT says to first quit the *xref* ^^^^ "means", not "says" From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) 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: Fri, 03 Nov 2017 16:19: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 To: Eli Zaretskii Cc: 28814-done@debbugs.gnu.org, 28814@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.150972590520401 (code B ref 28814); Fri, 03 Nov 2017 16:19:01 +0000 Received: (at 28814) by debbugs.gnu.org; 3 Nov 2017 16:18:25 +0000 Received: from localhost ([127.0.0.1]:49764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAefp-0005It-48 for submit@debbugs.gnu.org; Fri, 03 Nov 2017 12:18:25 -0400 Received: from mail-wm0-f47.google.com ([74.125.82.47]:45050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAefm-0005Ic-UY; Fri, 03 Nov 2017 12:18:23 -0400 Received: by mail-wm0-f47.google.com with SMTP id n74so3404838wmi.1; Fri, 03 Nov 2017 09:18:22 -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=cCk+htCyMFaKaJQUOMYas2o7Rg1JGL4ABfA1PvV9ZfA=; b=EondFhP+WKRsX1aRTEb8EEB9p5GZY6fZsGxg/480w3cl1EDq8LWmTRuTNqW6XvQSnp oDa0Ffzb91qtUoigaXMtsVU1KuS8GN5nwNfBeBjF+TLQa3yF7/ZZbvrPrgF7iW0HLr8T p2Lx535R/QsRkrCt15bXV0HpqJ/MLODw1ri8GFyFvY8PtlTZSaftKDdbXaKgyCNGpwLl pzw/20nNi6vu+hQMNCsvfweLdWtgp2EltarQTJ7tUjA5Y4bHLFdT8UQKT/eatVCVyer9 YGhWUQoj/hTGavRqExbKM5P23GCsXtrrT0Y82AUjGh8GIIn98DhqTmqSQbTJQfLH6A0C 3oNw== 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=cCk+htCyMFaKaJQUOMYas2o7Rg1JGL4ABfA1PvV9ZfA=; b=Si6r38ILGQoceGTT+/ZCmja8fQZbWx7/F4DYh5sFD3OeZ+hZrM1kfaJXTtUxfqhmzB cz5OipZqKZA3r2yLSB2LmKTisGiNxhdXQe56V+WRe7W7h7g3GRvJkVuX4aEGIl+92kpa 3cNFY8P8oA03/EhgWzGig+dCNSW1AIuWr69xC/H8KlD6Zgb3LQkrEgmx26RClkHd6exQ j4LISw98gPxTHRmqgebB4mYcX4SKvYPRlt57XCUDaj2BCrPx+ZVaIXFsCjoeeI8ycy37 TcHtXUaA458T55RYlARogcIxKDRIXuiEwApoVxVydX4disY8zOtah7wmn6sxGn6G3Npw 2bOQ== X-Gm-Message-State: AMCzsaVKVOwlzoqqdi03yGn0naTFz0MxzzjXMtD1iVOS2M9628A/S3tB 7/e8IT5II9xMgilS/8RtbHaC8xRKHg0= X-Google-Smtp-Source: ABhQp+QkN55uCex3eHpXCqhudAswBTjYeje0+lG03hlwkWBrdSUCE5CbMH35OZpBN2d5luhkbHXvEg== X-Received: by 10.80.134.135 with SMTP id r7mr9768106eda.152.1509725896993; Fri, 03 Nov 2017 09:18:16 -0700 (PDT) Received: from lolita.yourcompany.com ([2001:8a0:7ad2:3301:ae10:dccf:67:3fc8]) by smtp.gmail.com with ESMTPSA id m7sm6768063eda.91.2017.11.03.09.18.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 03 Nov 2017 09:18:15 -0700 (PDT) From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> <87a80fvte2.fsf@gmail.com> <83y3nx7tdn.fsf@gnu.org> <873765wjdr.fsf@gmail.com> <83r2tn6244.fsf@gnu.org> <87o9orulln.fsf@gmail.com> <83lgjnv5hx.fsf@gnu.org> Date: Fri, 03 Nov 2017 16:18:13 +0000 In-Reply-To: <83lgjnv5hx.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 03 Nov 2017 15:47:22 +0200") Message-ID: <87shdvtjy2.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o?= =?UTF-8?Q?T=C3=A1vora?=) >> Cc: dgutov@yandex.ru, 28814@debbugs.gnu.org >> Date: Sat, 28 Oct 2017 20:19:00 +0100 >> >> I hope I fixed everything in these patches. > > Thanks, let's get this into the emacs-26 branch, after fixing the > gotchas below. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [74.125.82.47 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [74.125.82.47 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (joaotavora[at]gmail.com) -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.47 listed in wl.mailspike.net] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.0 FREEMAIL_REPLY From and body contain different freemails X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Eli Zaretskii writes: >> From: joaotavora@gmail.com (Jo=C3=A3o T=C3=A1vora) >> Cc: dgutov@yandex.ru, 28814@debbugs.gnu.org >> Date: Sat, 28 Oct 2017 20:19:00 +0100 >>=20 >> I hope I fixed everything in these patches. > > Thanks, let's get this into the emacs-26 branch, after fixing the > gotchas below. Done. Pushed 3 commits to emacs-26. >> +buffers, quits the window before jumping to the destination. In many > ^^ > Two spaces between sentences, please. Sigh. This is the hardest for me to remember. Are there any tools to help with this? Jo=C3=A3o From unknown Mon Aug 18 04:43:03 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) Subject: bug#28814: closed (Re: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost )) Message-ID: References: <87shdvtjy2.fsf@gmail.com> <87infjm3p3.fsf@gmail.com> X-Gnu-PR-Message: they-closed 28814 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: patch Reply-To: 28814@debbugs.gnu.org Date: Fri, 03 Nov 2017 16:19:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1509725942-20457-1" This is a multi-part message in MIME format... ------------=_1509725942-20457-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #28814: 26.0.90; When *xref* window is needed, original window-switching in= tent is lost=20 which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 28814@debbugs.gnu.org. --=20 28814: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D28814 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1509725942-20457-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 28814-done) by debbugs.gnu.org; 3 Nov 2017 16:18:25 +0000 Received: from localhost ([127.0.0.1]:49762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAefo-0005Ir-Ss for submit@debbugs.gnu.org; Fri, 03 Nov 2017 12:18:25 -0400 Received: from mail-wm0-f47.google.com ([74.125.82.47]:45050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAefm-0005Ic-UY; Fri, 03 Nov 2017 12:18:23 -0400 Received: by mail-wm0-f47.google.com with SMTP id n74so3404838wmi.1; Fri, 03 Nov 2017 09:18:22 -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=cCk+htCyMFaKaJQUOMYas2o7Rg1JGL4ABfA1PvV9ZfA=; b=EondFhP+WKRsX1aRTEb8EEB9p5GZY6fZsGxg/480w3cl1EDq8LWmTRuTNqW6XvQSnp oDa0Ffzb91qtUoigaXMtsVU1KuS8GN5nwNfBeBjF+TLQa3yF7/ZZbvrPrgF7iW0HLr8T p2Lx535R/QsRkrCt15bXV0HpqJ/MLODw1ri8GFyFvY8PtlTZSaftKDdbXaKgyCNGpwLl pzw/20nNi6vu+hQMNCsvfweLdWtgp2EltarQTJ7tUjA5Y4bHLFdT8UQKT/eatVCVyer9 YGhWUQoj/hTGavRqExbKM5P23GCsXtrrT0Y82AUjGh8GIIn98DhqTmqSQbTJQfLH6A0C 3oNw== 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=cCk+htCyMFaKaJQUOMYas2o7Rg1JGL4ABfA1PvV9ZfA=; b=Si6r38ILGQoceGTT+/ZCmja8fQZbWx7/F4DYh5sFD3OeZ+hZrM1kfaJXTtUxfqhmzB cz5OipZqKZA3r2yLSB2LmKTisGiNxhdXQe56V+WRe7W7h7g3GRvJkVuX4aEGIl+92kpa 3cNFY8P8oA03/EhgWzGig+dCNSW1AIuWr69xC/H8KlD6Zgb3LQkrEgmx26RClkHd6exQ j4LISw98gPxTHRmqgebB4mYcX4SKvYPRlt57XCUDaj2BCrPx+ZVaIXFsCjoeeI8ycy37 TcHtXUaA458T55RYlARogcIxKDRIXuiEwApoVxVydX4disY8zOtah7wmn6sxGn6G3Npw 2bOQ== X-Gm-Message-State: AMCzsaVKVOwlzoqqdi03yGn0naTFz0MxzzjXMtD1iVOS2M9628A/S3tB 7/e8IT5II9xMgilS/8RtbHaC8xRKHg0= X-Google-Smtp-Source: ABhQp+QkN55uCex3eHpXCqhudAswBTjYeje0+lG03hlwkWBrdSUCE5CbMH35OZpBN2d5luhkbHXvEg== X-Received: by 10.80.134.135 with SMTP id r7mr9768106eda.152.1509725896993; Fri, 03 Nov 2017 09:18:16 -0700 (PDT) Received: from lolita.yourcompany.com ([2001:8a0:7ad2:3301:ae10:dccf:67:3fc8]) by smtp.gmail.com with ESMTPSA id m7sm6768063eda.91.2017.11.03.09.18.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 03 Nov 2017 09:18:15 -0700 (PDT) From: joaotavora@gmail.com (=?utf-8?B?Sm/Do28gVMOhdm9yYQ==?=) To: Eli Zaretskii Subject: Re: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> <87a80fvte2.fsf@gmail.com> <83y3nx7tdn.fsf@gnu.org> <873765wjdr.fsf@gmail.com> <83r2tn6244.fsf@gnu.org> <87o9orulln.fsf@gmail.com> <83lgjnv5hx.fsf@gnu.org> Date: Fri, 03 Nov 2017 16:18:13 +0000 In-Reply-To: <83lgjnv5hx.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 03 Nov 2017 15:47:22 +0200") Message-ID: <87shdvtjy2.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> From: joaotavora@gmail.com (João Távora) >> Cc: dgutov@yandex.ru, 28814@debbugs.gnu.org >> Date: Sat, 28 Oct 2017 20:19:00 +0100 >> >> I hope I fixed everything in these patches. > > Thanks, let's get this into the emacs-26 branch, after fixing the > gotchas below. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [74.125.82.47 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [74.125.82.47 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (joaotavora[at]gmail.com) -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.47 listed in wl.mailspike.net] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.0 FREEMAIL_REPLY From and body contain different freemails X-Debbugs-Envelope-To: 28814-done Cc: 28814-done@debbugs.gnu.org, 28814@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Eli Zaretskii writes: >> From: joaotavora@gmail.com (Jo=C3=A3o T=C3=A1vora) >> Cc: dgutov@yandex.ru, 28814@debbugs.gnu.org >> Date: Sat, 28 Oct 2017 20:19:00 +0100 >>=20 >> I hope I fixed everything in these patches. > > Thanks, let's get this into the emacs-26 branch, after fixing the > gotchas below. Done. Pushed 3 commits to emacs-26. >> +buffers, quits the window before jumping to the destination. In many > ^^ > Two spaces between sentences, please. Sigh. This is the hardest for me to remember. Are there any tools to help with this? Jo=C3=A3o ------------=_1509725942-20457-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 13 Oct 2017 16:08:00 +0000 Received: from localhost ([127.0.0.1]:38287 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e32VB-0005Pz-GV for submit@debbugs.gnu.org; Fri, 13 Oct 2017 12:07:57 -0400 Received: from eggs.gnu.org ([208.118.235.92]:45984) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e32V9-0005Pj-0j for submit@debbugs.gnu.org; Fri, 13 Oct 2017 12:07:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e32V2-00025d-7X for submit@debbugs.gnu.org; Fri, 13 Oct 2017 12:07:49 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:55741) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e32V2-00025U-1S for submit@debbugs.gnu.org; Fri, 13 Oct 2017 12:07:48 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e32V0-0005IZ-01 for bug-gnu-emacs@gnu.org; Fri, 13 Oct 2017 12:07:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e32Uw-00023b-Q6 for bug-gnu-emacs@gnu.org; Fri, 13 Oct 2017 12:07:45 -0400 Received: from mail-wr0-x22a.google.com ([2a00:1450:400c:c0c::22a]:56532) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e32Uw-00022o-Cy for bug-gnu-emacs@gnu.org; Fri, 13 Oct 2017 12:07:42 -0400 Received: by mail-wr0-x22a.google.com with SMTP id r79so1395857wrb.13 for ; Fri, 13 Oct 2017 09:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=hUml4e8VmZkFLaI0DuMwzEiipXP8F2WjyjHswnXKxoM=; b=WGBQUg87ow3tKT6jqlCc9E4V1YB010Dn/W+L7ByBPeyijnWUojqHsQo9aoadWjep7J Po9umFRgWHnYrm6V7kj4w05zmlJdzRg2bWfqLorjdqSFf5+1we4v1QqntHqD9chvEIqn +R1M4moskAaD4uSftzzPIera8kgpHLaBQolH+uCJaf9y5fIdzDxYgEC5qs9U3X7DI0bB s5jOoCaTGZBEwbhJzjSQQhB/UwokuYQMtqbWrbkm4UL4CNj3vRWfIo2sQAzhOs/Si4WB YtvR1cUsx90S7iJr8vosG/RAJv2l+fUcRKkjmBAtE6jbYGMqaKWL9/5MJXeWrt12kS5Y RJKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=hUml4e8VmZkFLaI0DuMwzEiipXP8F2WjyjHswnXKxoM=; b=rNI7AiwM0gplG4SwMGS8vyc+rYFzlzIpZZklWNDpdNATZn+eh08syCXIdtxyIzrmfT rXhkkrzftYaXVjWogmPRnoy+DJbmiktpfBceK8+8wpIWeKUpoUGOVw0YZ/aDROgjFRfC l+gvYQ8D3hzAkyvHf30oj5go7lkc9990hj+D8PQ93LpKOHrFbBV8RCH/gBsXQDinfIGH LCkq83OhkxBoGN9DRjVesgRw22RAcCpa0xkK006A+vJQMforFrYZ4kkZhl00MOXsE8bk RLB/WnjdPQbNscx02g9dL7dzSW98xEr/elOSIaV59WqvHxatitMtq6t1Jx6kUZRRqXtX 176A== X-Gm-Message-State: AMCzsaW8P6vmy4pNh/pkJVUVUr2bu/NBsfasVhCZkSL8PIlXNc2asaGt 3DCxhPSr1nfQpVnEUYbOS9Y= X-Google-Smtp-Source: AOwi7QBFrhGJ4Nm61kegV7MF81faXHr+qQqWxbX5VDJXOPHGByJPnY5kPifSNtpfCDD3Pp4XFO16+g== X-Received: by 10.223.151.143 with SMTP id s15mr2062285wrb.7.1507910860006; Fri, 13 Oct 2017 09:07:40 -0700 (PDT) Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id r44sm1658045wrb.37.2017.10.13.09.07.38 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 13 Oct 2017 09:07:38 -0700 (PDT) From: joaotavora@gmail.com (=?utf-8?B?Sm/Do28gVMOhdm9yYQ==?=) To: bug-gnu-emacs@gnu.org, dgutov@yandex.ru Subject: 26.0.90; When *xref* window is needed, original window-switching intent is lost Date: Fri, 13 Oct 2017 17:07:36 +0100 Message-ID: <87infjm3p3.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dmitry, maintainters, Here are two patches to fix what I believe is a small but annoying bug in xref.el. I'll try to explain as clearly as possible: As you know, if the user presses 'M-.' in a single-ref definition, he/she is transported to a new buffer. But there are other situations: when xref-find-definitions finds more than one definition, a list is shown in an *xref* buffer, normally in a new window. When the user selects an "xref" with xref-goto-xref, a buffer and window switch happen. Anyway, so far so good. The problem is there is also 'C-x 4 .' and 'C-x 5 .' for xref-find-definitions-other-window and xref-find-definitions-other-frame respectively. These work just fine when an *xref* buffer isn't needed, but when it is, the original intent of using another window or frame will be lost when the user eventually selects a definition. It shouldn't be so, in my opinion. The first patch I attach (0001-Honor-window....patch) fixes this bug. I hope it is readable enough but I can explain how it works in detail. I also attach a second patch (0002-Quit-the....patch), that does not really fix a bug, but changes the behavior of xref-goto-xref to something much nicer: it quits the *xref* window before going to the reference. This brings a nice result: As always 'M-.' switches buffers if there is only one definition. Now, if there is more than one, the final state after selecting one of these definitions is the same as if there had only been one in the first place. I think this makes sense because it preserves the expectations of the user who probably wants M-. to behave as predictably as possible. Here's hoping you're not really confused by this report, Jo=C3=A3o --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Honor-window-switching-intents-in-xref-find-definiti.patch >From 1cba860d6a2c45e0fa690065b2bf4e6658e87628 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Fri, 13 Oct 2017 15:13:14 +0100 Subject: [PATCH 1/2] Honor window-switching intents in xref-find-definitions When there is more than one xref to jump to, and an *xref* window appears to help the user choose, the original intent to open a definition another window or frame is remembered when the choice to go to or show a reference is finally made. * lisp/progmodes/xref.el (xref--show-pos-in-buf): Rewrite. (xref--original-window-intent): New variable. (xref--original-window): Rename from xref--window and move up here for clarity. (xref--show-pos-in-buf): Rewrite. Don't take SELECT arg here. (xref--show-location): Handle window selection decision here. (xref--window): Rename to xref--original-window. (xref-show-location-at-point): Don't attempt window management here. (xref--show-xrefs): Ensure display-action intent is saved. --- lisp/progmodes/xref.el | 73 +++++++++++++++++++++++++++++++++++--------------- 1 file changed, 52 insertions(+), 21 deletions(-) diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 80cdcb3f18..768fa15a6b 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -449,43 +449,72 @@ xref--with-dedicated-window (when xref-w (set-window-dedicated-p xref-w xref-w-dedicated))))) -(defun xref--show-pos-in-buf (pos buf select) - (let ((xref-buf (current-buffer)) - win) +(defvar-local xref--original-window-intent nil + "Original window-switching intent before xref buffer creation.") + +(defvar-local xref--original-window nil + "The original window this xref buffer was created from.") + +(defun xref--show-pos-in-buf (pos buf) + "Goto and display position POS of buffer BUF in a window. +Honour `xref--original-window-intent', run `xref-after-jump-hook' +and finally return the window." + (let* ((xref-buf (current-buffer)) + (pop-up-frames + (or (eq xref--original-window-intent 'frame) + pop-up-frames)) + (action + (cond ((memq + xref--original-window-intent + '(window frame)) + t) + ((and + (window-live-p xref--original-window) + (or (not (window-dedicated-p xref--original-window)) + (eq (window-buffer xref--original-window) buf))) + `(,(lambda (buf _alist) + (set-window-buffer xref--original-window buf) + xref--original-window)))))) (with-selected-window - (xref--with-dedicated-window - (display-buffer buf)) + (with-selected-window + ;; Just before `display-buffer', place ourselves in the + ;; original window to suggest preserving it. Of course, if + ;; user has deleted the original window, all bets are off, + ;; just use the selected one. + (or (and (window-live-p xref--original-window) + xref--original-window) + (selected-window)) + (display-buffer buf action)) (xref--goto-char pos) (run-hooks 'xref-after-jump-hook) (let ((buf (current-buffer))) - (setq win (selected-window)) (with-current-buffer xref-buf - (setq-local other-window-scroll-buffer buf)))) - (when select - (select-window win)))) + (setq-local other-window-scroll-buffer buf))) + (selected-window)))) (defun xref--show-location (location &optional select) (condition-case err (let* ((marker (xref-location-marker location)) (buf (marker-buffer marker))) - (xref--show-pos-in-buf marker buf select)) + (cond (select + (select-window (xref--show-pos-in-buf marker buf))) + (t + (save-selected-window + (xref--with-dedicated-window + (let (;; save-selected-window doesn't resist frame + ;; raises + (display-buffer-overriding-action + '(nil . ((inhibit-switch-frame . t))))) + (xref--show-pos-in-buf marker buf))))))) (user-error (message (error-message-string err))))) -(defvar-local xref--window nil - "The original window this xref buffer was created from.") - (defun xref-show-location-at-point () "Display the source of xref at point in the appropriate window, if any." (interactive) (let* ((xref (xref--item-at-point)) (xref--current-item xref)) (when xref - ;; Try to avoid the window the current xref buffer was - ;; originally created from. - (if (window-live-p xref--window) - (with-selected-window xref--window - (xref--show-location (xref-item-location xref))) - (xref--show-location (xref-item-location xref)))))) + (xref--show-location (xref-item-location xref))))) (defun xref-next-line () "Move to the next xref and display its source in the appropriate window." @@ -727,7 +756,8 @@ xref--show-xref-buffer (xref--xref-buffer-mode) (pop-to-buffer (current-buffer)) (goto-char (point-min)) - (setq xref--window (assoc-default 'window alist)) + (setq xref--original-window (assoc-default 'window alist) + xref--original-window-intent (assoc-default 'display-action alist)) (current-buffer))))) @@ -754,7 +784,8 @@ xref--show-xrefs (t (xref-push-marker-stack) (funcall xref-show-xrefs-function xrefs - `((window . ,(selected-window))))))) + `((window . ,(selected-window)) + (display-action . ,display-action)))))) (defun xref--prompt-p (command) (or (eq xref-prompt-for-identifier t) -- 2.11.0 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0002-Quit-the-xref-window-if-user-decides-to-go-to-a-ref.patch >From 228cb812197bd68b2fb6eccc60d7956675a728f3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Fri, 13 Oct 2017 16:37:47 +0100 Subject: [PATCH 2/2] Quit the *xref* window if user decides to go to a ref * lisp/progmodes/xref.el (xref--show-location): When SELECT is t, quit window. --- lisp/progmodes/xref.el | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 768fa15a6b..3a5e9e53ed 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -495,9 +495,12 @@ xref--show-pos-in-buf (defun xref--show-location (location &optional select) (condition-case err (let* ((marker (xref-location-marker location)) - (buf (marker-buffer marker))) + (buf (marker-buffer marker)) + (xref-buffer (current-buffer))) (cond (select - (select-window (xref--show-pos-in-buf marker buf))) + (quit-window nil nil) + (with-current-buffer xref-buffer + (select-window (xref--show-pos-in-buf marker buf)))) (t (save-selected-window (xref--with-dedicated-window -- 2.11.0 --=-=-=-- ------------=_1509725942-20457-1-- From unknown Mon Aug 18 04:43:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Nov 2017 19:07: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 To: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) Cc: 28814@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.15097359743312 (code B ref 28814); Fri, 03 Nov 2017 19:07:01 +0000 Received: (at 28814) by debbugs.gnu.org; 3 Nov 2017 19:06:14 +0000 Received: from localhost ([127.0.0.1]:49836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAhID-0000rM-R5 for submit@debbugs.gnu.org; Fri, 03 Nov 2017 15:06:14 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42437) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAhIC-0000r7-AL for 28814@debbugs.gnu.org; Fri, 03 Nov 2017 15:06:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAhI2-0005hO-Ba for 28814@debbugs.gnu.org; Fri, 03 Nov 2017 15:06:06 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33617) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAhI2-0005hK-8K; Fri, 03 Nov 2017 15:06:02 -0400 Received: from [176.228.60.248] (port=2387 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eAhI1-0003vW-NP; Fri, 03 Nov 2017 15:06:02 -0400 Date: Fri, 03 Nov 2017 21:06:00 +0200 Message-Id: <83ineruqqv.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87shdvtjy2.fsf@gmail.com> (joaotavora@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> <83inf38dq2.fsf@gnu.org> <87k1zjs0xa.fsf@gmail.com> <83fua78ce9.fsf@gnu.org> <87a80fvte2.fsf@gmail.com> <83y3nx7tdn.fsf@gnu.org> <873765wjdr.fsf@gmail.com> <83r2tn6244.fsf@gnu.org> <87o9orulln.fsf@gmail.com> <83lgjnv5hx.fsf@gnu.org> <87shdvtjy2.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: joaotavora@gmail.com (João Távora) > Cc: dgutov@yandex.ru, 28814@debbugs.gnu.org, 28814-done@debbugs.gnu.org > Date: Fri, 03 Nov 2017 16:18:13 +0000 > > > Two spaces between sentences, please. > > Sigh. This is the hardest for me to remember. Are there any tools to > help with this? I'd try checkdoc.el.