From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#35737: xref--original-command Date: Wed, 15 May 2019 04:07:53 +0300 Message-ID: <56943df5-f366-a8af-cb95-a40c244da837@yandex.ru> References: <87ftpgu59l.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="215742"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 To: Juri Linkov , 35737@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 15 03:09:17 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hQiQ0-000u1m-IV for geb-bug-gnu-emacs@m.gmane.org; Wed, 15 May 2019 03:09:16 +0200 Original-Received: from localhost ([127.0.0.1]:57230 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQiPz-0002os-EZ for geb-bug-gnu-emacs@m.gmane.org; Tue, 14 May 2019 21:09:15 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQiPo-0002ol-3q for bug-gnu-emacs@gnu.org; Tue, 14 May 2019 21:09:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hQiPm-0004c8-Q7 for bug-gnu-emacs@gnu.org; Tue, 14 May 2019 21:09:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36919) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hQiPm-0004c0-Jd for bug-gnu-emacs@gnu.org; Tue, 14 May 2019 21:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hQiPm-0005Z7-D9 for bug-gnu-emacs@gnu.org; Tue, 14 May 2019 21:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 May 2019 01:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35737 X-GNU-PR-Package: emacs Original-Received: via spool by 35737-submit@debbugs.gnu.org id=B35737.155788248621324 (code B ref 35737); Wed, 15 May 2019 01:09:02 +0000 Original-Received: (at 35737) by debbugs.gnu.org; 15 May 2019 01:08:06 +0000 Original-Received: from localhost ([127.0.0.1]:50460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hQiOs-0005Xs-8o for submit@debbugs.gnu.org; Tue, 14 May 2019 21:08:06 -0400 Original-Received: from mail-lj1-f196.google.com ([209.85.208.196]:46371) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hQiOp-0005XK-RG for 35737@debbugs.gnu.org; Tue, 14 May 2019 21:08:05 -0400 Original-Received: by mail-lj1-f196.google.com with SMTP id h21so891306ljk.13 for <35737@debbugs.gnu.org>; Tue, 14 May 2019 18:08:03 -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=VnpFUbsAiO9LS+jnFs3pXOSnlDVgNK0ExQa6Pj37pU4=; b=Z8sY233GRvJOjxA1pL6KpXO1W6W87Om6I9W2hsUIC2uGjj1GVB5jAo6jstcfuEkWaC SfasOtq4o2pIL3vwyL2VaIHHf+Nby7WJ84leoL8rON5awndqVAh4HJWpK8lbpWnfMsq5 X9QmA3DWYYFW4gB9yDdpPdV0ZKfnczg3tnk5zQOCwoZmjCRIExw+T/7/8YwGhY2dHBJ1 iTbujbcUvOlO5XxbXUMJylA08jyQj9ZJZdCAmRJY+kLlw9XpoicoPbAIOZvXDQ1Vc7Lf vq47zQK7bMlQnaj5Ik/aqrt216XArHeGgCOqr+oxtzEBZXpRBW2rB1hMUc8sd7P8MJ4m NORg== 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=VnpFUbsAiO9LS+jnFs3pXOSnlDVgNK0ExQa6Pj37pU4=; b=jrHjHixsWQ20NbqePQ2eCjf/meTNxz4gqh7mCtMEQIGJuMEKPI4pfe0+hBm5FytXuy /zSSZootZ6jTeQCXpn/tZQmVTdjBFdK5LHtZfMzlcGyWtaLYACewPc0o+TFPRA/TiB+v 8Fn7OZAH+vSoR40lJvSMkni95HAPT7mx6SaII6oyVFnnbecDeWSbtTIxfZXpWu150/5o Vs6YlAOLHwpUaf7VgeQNStqtIHXx6TIscpTSHw2xw8lx/93+kCNqqMxIWpNa+cDJVGPn KJxq0tVMuCR49sIuxFXbEUPDaIAdejBLxLgb1WEs2VX1NerwxOcUR2wCZsmEmfbAs3Ct 7cCA== X-Gm-Message-State: APjAAAV/SQmM4yGpzU9Ig4FnBBZzIFuGJ41UL68gq53YRR0Do9IO5PsP K/X1xu6gIJQ9TGorZsjP10AeZmYJ X-Google-Smtp-Source: APXvYqxkaW9Af2tW2Yy6I8TplhiO07b2uDQ2yqWDwsa7bzaD6UAcimWiyaRE2NfZ4laKDTw3LA4cqA== X-Received: by 2002:a2e:9e96:: with SMTP id f22mr12197125ljk.141.1557882477489; Tue, 14 May 2019 18:07:57 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id f189sm80837lfe.66.2019.05.14.18.07.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 May 2019 18:07:56 -0700 (PDT) In-Reply-To: <87ftpgu59l.fsf@mail.linkov.net> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:159305 Archived-At: On 14.05.2019 23:53, Juri Linkov wrote: > Remembering the command that created the *xref* buffer > will allow such customization to treat RET differently, > i.e. it makes sense for RET to quit the transient xref buffer > displayed momentarily while navigating code with xref-find-definitions, > whereas leaving the xref buffer visible while navigating matches > in the xref buffer created by e.g. project-find-regexp: > > (define-key xref--button-map [(control ?m)] > (lambda () > (interactive) > (if (memq xref--original-command '(xref-find-definitions)) > (call-interactively 'xref-quit-and-goto-xref) > (call-interactively 'xref-goto-xref)))) I'm all for customizability, but as I said in a past discussion on the subject, I don't think this by itself would be a good default behavior. Having two buffers that looks basically the same but react to RET differently is not great for usability. > Better ideas? Ideally, the "transient" buffer should look differently from the "persistent" one. To take VS Code as an example (I just to see how it behaves exactly), a search for references opens search results in the sidebar. Whereas for definitions they have both "Go To Definition" and "Peek Definition". The latter shows the definitions kind of inline, in a not-exactly-a-popup kind of way (https://stackoverflow.com/questions/55599177/go-to-definition-in-vscode-preview-window-ruins-the-edito), and there, if you type RET, that triggers navigation to the selected definition. "Go To Definition", when there are several definitions, also switches to "Peek" mode by default. Not sure how best to implement this different kind of display in Emacs, but the idea makes a lot of sense to me. In Sublime, IIRC, for this they used the dropdown from their top-of-the-window command line, the same one that becomes active once one presses Ctrl-P. > diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el > index bf999aeb0d..5c38cac164 100644 > --- a/lisp/progmodes/xref.el > +++ b/lisp/progmodes/xref.el > @@ -477,6 +477,9 @@ xref--original-window-intent > (defvar-local xref--original-window nil > "The original window this xref buffer was created from.") > > +(defvar-local xref--original-command nil > + "The original command that created this xref buffer.") > + > (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' > @@ -777,7 +788,8 @@ xref--analyze > (pop-to-buffer (current-buffer)) > (goto-char (point-min)) > (setq xref--original-window (assoc-default 'window alist) > - xref--original-window-intent (assoc-default 'display-action alist)) > + xref--original-window-intent (assoc-default 'display-action alist) > + xref--original-command this-command) > (current-buffer))))) I'm good with this patch, though, if you find it helpful for personal customization. When we implement two different display strategies, though, we might choose between them inside xref--show-xrefs straight away, instead of saving the original command for later.