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 17:43:42 +0200 Message-ID: <837fiz3rv5.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1453650217 10226 80.91.229.3 (24 Jan 2016 15:43:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Jan 2016 15:43:37 +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 16:43:36 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 1aNMpB-0000MD-GX for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 16:43:33 +0100 Original-Received: from localhost ([::1]:60839 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNMpA-0004lS-QC for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 10:43:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57225) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNMp6-0004kI-R9 for emacs-devel@gnu.org; Sun, 24 Jan 2016 10:43:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNMp5-00070m-R8 for emacs-devel@gnu.org; Sun, 24 Jan 2016 10:43:28 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43103) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNMoy-00070I-Pz; Sun, 24 Jan 2016 10:43:20 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3949 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aNMoy-0007sO-2j; Sun, 24 Jan 2016 10:43:20 -0500 In-reply-to: <56A434A9.6040404@yandex.ru> (message from Dmitry Gutov on Sun, 24 Jan 2016 05:19:21 +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:198706 Archived-At: > Cc: emacs-devel@gnu.org, martin rudalics , > Helmut Eller > From: Dmitry Gutov > Date: Sun, 24 Jan 2016 05:19:21 +0300 > > 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. > If we're allowed to quit the *xref* buffer before jumping to the "final > destination", we can nominally satisfy the contract by using > switch-to-buffer or pop-to-buffer (maybe with pop-up-frames bound to t) > after that. The *xref* buffer and its window are out of the picture by > that point. > > However, now we have the *xref* buffer back in the picture. I think that > means we have to satisfy the this-window/other-window/other-frame > contract while *xref* is displayed. Yes, I think so. It will also fix the above confusion, IMO. > - xref-find-definitions-other-frame seems easiest: just bind > pop-up-frames to t and call pop-to-buffer like before. Right. > - xref-find-definitions promises to show the destination buffer in the > current window. What will RET in *xref* do? Show the buffers in the > window xref-find-definitions was called from? Yes, I think so. > 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? > - xref-find-definitions-other-window should, apparently, pick some > window which isn't the original one, nor the one which displays the > *xref* buffer. Or create a new one, in a pop-to-buffer fashion. Probably, yes. > Is there a function in window.el I can reuse, and/or display-buffer > alist argument that would make it ignore whole two buffers, and not > just the currently selected one? I hope Martin will help you out here. > Alternatively, we *do* treat xref-find-definitions differently, and > don't keep the *xref* buffer visible after the user made their choice. > But if the *xref* buffer looks the same as in other cases, it would be > confusing. So ideally, we'd have a different choice-picking mechanism in > this case (not *xref* buffer like it works and looks right now), but I > really don't know where to start writing it (and don't want to do it now). I think we should try the former route first, it sounds simpler. > Yet alternatively, as soon as we find out that there are several > definitions of the given function, we abandon all that > other-window/other-frame business, and simply make RET always behave the > same in *xref*. That seems like a cop-out. I think this should change, it's a confusing inconsistency if the user asked for another window/frame. Thanks.