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: Thu, 16 May 2019 01:30:22 +0300 Message-ID: References: <87ftpgu59l.fsf@mail.linkov.net> <56943df5-f366-a8af-cb95-a40c244da837@yandex.ru> <87tvdvpgzj.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="42106"; 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 Cc: 35737@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 16 00:31:19 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 1hR2Qc-000Ah4-2z for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 May 2019 00:31:14 +0200 Original-Received: from localhost ([127.0.0.1]:43609 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hR2Qb-0002dS-39 for geb-bug-gnu-emacs@m.gmane.org; Wed, 15 May 2019 18:31:13 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hR2QR-0002c5-SD for bug-gnu-emacs@gnu.org; Wed, 15 May 2019 18:31:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hR2QQ-0007l4-93 for bug-gnu-emacs@gnu.org; Wed, 15 May 2019 18:31:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40035) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hR2QQ-0007kt-5G for bug-gnu-emacs@gnu.org; Wed, 15 May 2019 18:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hR2QP-0003wI-Ux for bug-gnu-emacs@gnu.org; Wed, 15 May 2019 18:31:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 May 2019 22:31:01 +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.155795943315098 (code B ref 35737); Wed, 15 May 2019 22:31:01 +0000 Original-Received: (at 35737) by debbugs.gnu.org; 15 May 2019 22:30:33 +0000 Original-Received: from localhost ([127.0.0.1]:53579 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hR2Pw-0003vS-Oj for submit@debbugs.gnu.org; Wed, 15 May 2019 18:30:33 -0400 Original-Received: from mail-wm1-f44.google.com ([209.85.128.44]:53985) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hR2Pv-0003vE-C5 for 35737@debbugs.gnu.org; Wed, 15 May 2019 18:30:31 -0400 Original-Received: by mail-wm1-f44.google.com with SMTP id 198so1574474wme.3 for <35737@debbugs.gnu.org>; Wed, 15 May 2019 15:30:31 -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=cvSvguTtMMcDl3h28V8ZOfrkpVs2fM0i/p6V5ZZuoEU=; b=t1KrUPUEXw07rtsB/WwLmGDIx29ext9C6LSCSnEYlKh3Jbv5WTU4V8mH0CaHTvTUFJ 19s1c9R1Y5qPDAQ9gUBxwjwWRp+sTMmGEfMWxIx31mSrvM5V6qHuOpnyHBo11tEIlnYN lYi6zW4SgPH14a4NFukAv0NwJVX+cIaGa5TX+6ktnN4jiyIzAcbhVfWXuLBMr8tR6VEN bwh/ODHNXk+xmgoSRt4PdyprwkYQTVw6nSMQiexSzhK0XtMmpQrOnUDUCeaR8VBpvFAU mmyBb+QxLoNDWKdv42pp+mojdZOhfhnbubha2ZOoeTJCYkUEk27op1OOEvHAAsowJPMt /K5g== 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=cvSvguTtMMcDl3h28V8ZOfrkpVs2fM0i/p6V5ZZuoEU=; b=nET6vj/QsL6rc/Qr7D7MvaFzNY8PlH8989cJ11NxMxWjasr7rmmfAyI+YM4i4/VNEQ N9i4PKFIjyWc0P2fokNuekT/EpYLZVm2VPnY+rYX9hKRO3db8OxJIDP8B5lvEpb16wNV aBvi2+VQDAEcm5oMnhMV/TLNQvd/rSX25+I4yKRDCAGTJ4csh0WOM5n3V0XuJ5YGDK2m y1/XTVDnFKAWoOaPSkxby8wb/iKOhno9nS8EEuvw62/SLUawZtROVgwCWkk/nPL1RZT+ b8UgeCbw6Y3WCYCHzxwR04xvTb5xt+GIhkpynGXkdv/ILTDVZ04JzxB96g0/tVWY58rx mYxA== X-Gm-Message-State: APjAAAWthkqqqGEd/DLQkjpuQphhw7MkTdxyyHzv0nEdlA9i6Q5llzry MTVSFWyz68QU6qqWvaY86W2S4H0I X-Google-Smtp-Source: APXvYqy8RoDbHwEJHyidirxKdAAgn9putBeFqEBjQ/yYZO7onpHgrEWr5QkwNvqlcp3dDwQXVzhKGA== X-Received: by 2002:a1c:e90f:: with SMTP id q15mr26005926wmc.1.1557959425055; Wed, 15 May 2019 15:30:25 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id y7sm7246056wrg.45.2019.05.15.15.30.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 May 2019 15:30:24 -0700 (PDT) In-Reply-To: <87tvdvpgzj.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:159366 Archived-At: On 16.05.2019 0:04, Juri Linkov wrote: > I don't propose to change its default behavior. Just allowing its > customization would be good. OK. But please wait a little, I'd like to show a patch for bug#35702 that can also provide a basic for the same distinction in functionality but without this variable. >> Having two buffers that looks basically the same but react to RET >> differently is not great for usability. > > Using display-buffer-in-direction, they don't look the same: after > customization xref-find-definitions can display the xref buffer below, > whereas other xref command can display in the side window. OK. Still look very similar, but at least the behavior appears different from the outset. If you look at Atom's behavior, it actually shows regexp search results in a pane below the main area. The same direction where you want to show the definitions search result. Just something to keep in mind. >> 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. > > Emacs has side windows too. You mean like Speedbar? That's the part which I didn't exactly like. >> 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. BTW, there's a third-party package that implements something like that for LSP users: https://github.com/emacs-lsp/lsp-ui#lsp-ui-peek Not sure how likely we are to have this contributed to the core, though. >> 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. > > We have Completions for the same purpose. Except we have a UI for it which is expected to be usable without using arrow keys. And the completion entries in this case can contain spaces, parens, and basically any other characters. They can also be fairly long. So completing-read doesn't seem to fit the bill. I'm open to ideas.