From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: xref and displaying locations in appropriate window or frame Date: Sun, 24 Jan 2016 05:19:21 +0300 Message-ID: <56A434A9.6040404@yandex.ru> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1453601984 25932 80.91.229.3 (24 Jan 2016 02:19:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Jan 2016 02:19:44 +0000 (UTC) Cc: martin rudalics , Helmut Eller , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 24 03:19: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 1aNAH9-0000LT-MM for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 03:19:35 +0100 Original-Received: from localhost ([::1]:59020 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNAH5-00031E-Jy for ged-emacs-devel@m.gmane.org; Sat, 23 Jan 2016 21:19:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36200) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNAH1-00030U-L3 for emacs-devel@gnu.org; Sat, 23 Jan 2016 21:19:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNAGy-0003I8-Ee for emacs-devel@gnu.org; Sat, 23 Jan 2016 21:19:27 -0500 Original-Received: from mail-lf0-x22f.google.com ([2a00:1450:4010:c07::22f]:34000) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNAGy-0003I3-0O; Sat, 23 Jan 2016 21:19:24 -0500 Original-Received: by mail-lf0-x22f.google.com with SMTP id 17so66979110lfz.1; Sat, 23 Jan 2016 18:19:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=faTH4RBqYmxwgFwKY1PdwL1HEaTcgPnIskdHcusOP/M=; b=Kk581IsZ1Yt4CUwP0KXq8CET78gpvKRDVrkm9vSN2olw3ygSPgn+bfYLvE/Gfezre5 PMPVvio8k3VTV6FCoYLRz0dMMmSUjyohjvBdNVf5atte9fAV6bgwUAS9c/rR6FJ5KDc4 o4WIh5ueVjoArq8jGzqxyv1nshsmM7dLvTRzGJUojzmACbrTGBDEVWV+fvc/vcX7sMfp IkWDFftI0l8npcp3qjA8k14cYCUWXZIRxsLNOorjlvpCV4DlNRoS9DCRNtY4pe3/oQ8t Ia9Er+jcCf8R6duVc8qixtmnTWbO8o97uY14zUbbzEIwyPgXAbjs2aWz8BSCvp/gc+B9 eoeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=faTH4RBqYmxwgFwKY1PdwL1HEaTcgPnIskdHcusOP/M=; b=MG/pY9msmwW0CPG7flNrXIFrwd1D5+wjGr4QYDIK6chXurw+3PidsIwc7/rEqIVj14 IA41dcmhD0ZAOUL8Vhdd0TXLpqxtgbo2q5kB/giiGYQenht4HupAD5Sxio8komMXt5Im MroMlI6TWoXGvza9laMYq2AEwmedoFr/RbAsxhzM2GGdQtQH6c+RI5tQ5DkPk/GQnP36 LCkeEqxEl8VpXD+RqgsTthOcws9CgINlAj/tifP+lOaY0/6tgB9y8Hqpip7E2MYNebcQ 4rVZbX4zDWSHNeCB3gkmsqu5LVrNGemqhi0mTM8w7h8Zfrnx31nE2j33OF6kIUmsHvCM hhJA== X-Gm-Message-State: AG10YORuZOAiyaKA0CTXyYOz2lC79nBRaAU9O8tbtNTXtO3UHU/ljTOhI3PGfVPGmyBdYw== X-Received: by 10.25.77.203 with SMTP id a194mr4298889lfb.62.1453601962983; Sat, 23 Jan 2016 18:19:22 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id k3sm1814596lbp.9.2016.01.23.18.19.21 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Jan 2016 18:19:21 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <83r3ha97yu.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::22f 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:198678 Archived-At: On 01/21/2016 08:07 PM, Eli Zaretskii wrote: > I think having the *xref* buffer visible is _the_ reason we could get > rid of tags-loop-continue. Here's where I'm currently stumped: 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. 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. - xref-find-definitions-other-frame seems easiest: just bind pop-up-frames to t and call pop-to-buffer like before. - 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? 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? - 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. 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? Compilation has no such contract, so there's nothing corresponding in there that I could borrow. 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). 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. But maybe it's what we should do anyway until someone implements the second option (the previous paragraph). > No, I think all the matches that the user saw already, whether she > accepted the replacement or not, should be marked in some way, so that > continuing the replacement goes to the first unseen one. Good, that should be easier to do.