From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: xref and displaying locations in appropriate window or frame Date: Sun, 24 Jan 2016 19:58:57 +0200 Message-ID: <83vb6i3llq.fsf@gnu.org> References: <83wprimto9.fsf@gnu.org> <56916C10.6050004@yandex.ru> <83oacumqmj.fsf@gnu.org> <56917246.1010800@yandex.ru> <5691795E.9010008@yandex.ru> <83lh7ym725.fsf@gnu.org> <5691D768.3020908@yandex.ru> <83bn8tmnvq.fsf@gnu.org> <56928356.2000609@yandex.ru> <8360z1mkfc.fsf@gnu.org> <5696EE9D.2090708@yandex.ru> <838u3si22k.fsf@gnu.org> <5697C7A8.6060601@yandex.ru> <83wprcgjxk.fsf@gnu.org> <5697DA3B.3070706@yandex.ru> <83io2wggh8.fsf@gnu.org> <5697EC73.6040302@yandex.ru> <83fuy0gf2j.fsf@gnu.org> <5697F3C9.5040702@yandex.ru> <83bn8ogd8c.fsf@gnu.org> <56980073.7050604@yandex.ru> <838u3rhpzk.fsf@gnu.org> <569D3ADC.5060803@yandex.ru> <83si1sa47q.fsf@gnu.org> <56A06965.7050501@yandex.ru> <83r3ha97yu.fsf@gnu.org> <56A434A9.6040404@yandex.ru> <837fiz3rv5.fsf@gnu.org> <56A50981.7070809@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1453658341 2667 80.91.229.3 (24 Jan 2016 17:59:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Jan 2016 17:59:01 +0000 (UTC) Cc: rudalics@gmx.at, eller.helmut@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 24 18:59:01 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aNOwG-0005CG-FI for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 18:59:00 +0100 Original-Received: from localhost ([::1]:33001 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNOwG-00079Q-2Q for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 12:59:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNOw1-00079J-S8 for emacs-devel@gnu.org; Sun, 24 Jan 2016 12:58:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNOw0-00016u-G1 for emacs-devel@gnu.org; Sun, 24 Jan 2016 12:58:45 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45842) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNOvs-00016Y-6Q; Sun, 24 Jan 2016 12:58:36 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4211 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aNOvr-0001Z1-A7; Sun, 24 Jan 2016 12:58:35 -0500 In-reply-to: <56A50981.7070809@yandex.ru> (message from Dmitry Gutov on Sun, 24 Jan 2016 20:27:29 +0300) 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-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:198713 Archived-At: > Cc: emacs-devel@gnu.org, rudalics@gmx.at, eller.helmut@gmail.com > From: Dmitry Gutov > Date: Sun, 24 Jan 2016 20:27:29 +0300 > > On 01/24/2016 06:43 PM, Eli Zaretskii wrote: > > >> xref-find-definitions has a family of commands (namely -other-window and > >> -other-frame) which promise to display the location somewhere else than > >> the current window. > > > > But AFAICS they only do that if there's a single candidate for the > > definition, i.e. if the *xref* buffer is not displayed at all. Which > > confused the heck out of me the first time I tried "C-x 5 .", btw. > > They do it for the final destination, but not for buffers temporarily > displayed when you press `n' or `p'. E.g.: > > Press `C-x 4 .', type log-edit-menu, pick an element, press RET - and > you'll see its location displayed in the "other" window. Same with `C-x > 5 .', though to see the expected effect the destination buffer must not > be already displayed in the current frame. With RET, yes. But this doesn't happen with '.'. Isn't that confusing? > But if we're not allowed to hide *xref* on RET either, xref-goto-xref > and xref-show-location-at-point's behavior should be close to this, and > only differ in which window ends up being selected. RET runs xref-goto-xref, so whatever RET does, xref-goto-xref will do the same, no? What am I missing? As for xref-show-location-at-point, it doesn't bury the *xref* buffer when I try it now, so it looks like it already avoids hiding *xref*. I have a terrible feeling that I'm missing something important here. > >> That seems to make the most sense, but it will obscure the original > >> code. Maybe we'd want to consult it while picking the exact option > >> among the suggested definitions? > > > > I don't think I understand you here. By "obscure the original code" > > do you mean the code will be harder to read? Or do you mean something > > else? > > > > And what do you mean by "consult" -- consult what? > > I only mean that the original buffer will be hidden, and the user won't > be able to look at its contents while making the choice. Which might be > considered bad, for the default behavior. Maybe not too terrible, though. No, I don't think it's terrible. There's always xref-pop-marker-stack, right? > (When there's only one option, jumping to it in the current window seems > best to me I agree.