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: Re: xref and displaying locations in appropriate window or frame Date: Sun, 21 Feb 2016 02:24:26 +0200 Message-ID: <56C903BA.8050006@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> <56A434A9.6040404@yandex.ru> <837fiz3rv5.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 1456014303 2029 80.91.229.3 (21 Feb 2016 00:25:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Feb 2016 00:25:03 +0000 (UTC) Cc: rudalics@gmx.at, eller.helmut@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 21 01:24:51 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 1aXHpR-00062P-Jo for ged-emacs-devel@m.gmane.org; Sun, 21 Feb 2016 01:24:49 +0100 Original-Received: from localhost ([::1]:36608 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXHpQ-0003vd-Ru for ged-emacs-devel@m.gmane.org; Sat, 20 Feb 2016 19:24:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXHpB-0003vV-Q8 for emacs-devel@gnu.org; Sat, 20 Feb 2016 19:24:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aXHp8-0000sA-JP for emacs-devel@gnu.org; Sat, 20 Feb 2016 19:24:33 -0500 Original-Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230]:34961) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXHp8-0000s2-8m; Sat, 20 Feb 2016 19:24:30 -0500 Original-Received: by mail-wm0-x230.google.com with SMTP id c200so124114617wme.0; Sat, 20 Feb 2016 16:24:29 -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=tpXsikFuFmRc+y8/cPhhH7dzsyw3l9Z5BYw7LzS7YQs=; b=BjoXtQdQQjzQHh0j2A5Gr7qZ0dNdsvF2sQ96TY7lKyin4l4Ak3IlPihhHCw93Yc8rf zs5KgCJLu0l1/H5qqVfm8R3R0GqAx3gdRIMvRKRo7p27XhPP8b5yg+YlfoD5a5QuX3a7 yWYkULkPodyXYvWbQMLfHwJdX6WbVU/wM4TyALgrd3BC0kL48JTVMJxJ3hwW9+9kyoiu 9J/IHf1cc5Y2bnsCT8WDUm/Mnng0s17HHkVZZMWshncYBUroviNCGgsTA9Lsudr3BoLy 3wouHXpM4AVeULH+WYfK+JNtDWM36rEZTt/+B8W2uGTd6+m0GL3zzYgYF3LnapTgWEhV PM5Q== 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=tpXsikFuFmRc+y8/cPhhH7dzsyw3l9Z5BYw7LzS7YQs=; b=eXWWf1L6U3Ly66vTs1XyYLvuJuGHnE30UcpiJmGyf+rR2A6oMbXya0Bloyg3STboj/ QiIsIX46PVIYjv4m5bZ3sEWf7KAC9XFoLmcXpO8aUPomGGFKNsH1xE7LTyBnHxITYoRW ntUMON0FMdDkvaI6Z8ier12e0M50GhxGxNO+xVo1TYqQdWOVDPIh7QJsLUzt1GQfnYi2 KGtAbeQfwuYxKPG/zbhc9O8V+pwWPppSCTcZ9knjrzGepBYNBkZVP5/NdKBldCM8xmGW taHHXRpUBspdz5aGItXggd3ziRj+uv7C6kPcbDy9oB2mnvJ339tGjJcvyYjzXYa493G4 M1cQ== X-Gm-Message-State: AG10YOTWJ668NafemZ3nzc23G7lWST/fgOYfw3tOxKwyl+UzrymS15RwV6KABt8gBqrxlQ== X-Received: by 10.194.205.8 with SMTP id lc8mr19716930wjc.177.1456014269099; Sat, 20 Feb 2016 16:24:29 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id v2sm14175173wmd.24.2016.02.20.16.24.27 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 20 Feb 2016 16:24:27 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <837fiz3rv5.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::230 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:200345 Archived-At: On 01/24/2016 05:43 PM, Eli Zaretskii wrote: >> 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. Having tried this, I don't think this is feasible. First, if xref-show-location-at-point (called when ./,/n/p is pressed) tries to satisfy the "other frame" contract, if the user hasn't done some special frame-related configuration, doesn't use a tiling window manager, etc, we get the location buffer displayed in a new, selected frame on top of the current one. There's no way to keep pressing "n" or "p" to jump through the locations. Second, we shouldn't use one strategy in xref-show-location-at-point, and another in xref-goto-xref: even if the user wanted to see the target in a new frame, they are unlikely to appreciate seeing it both in "some other" window in the current frame, and in the new frame as well after they press RET. So, retaining the other-frame contract is out. other-window is easier, but, like Martin noted, the approach available to us (show in some window that's not the original one, and not the xref one) is also iffy, because it might be not _the_ "other window" respective to the original one. The xref buffer could very well be displayed in that window, so we can't use it. Further, even though the user asked to display the destination using a particular approach, by the time they choose the location from the list, they might have forgotten their original request: several commands will have passed by that time. Overall, when the xref buffer gets to be displayed, I think always using the "some other window" seems best after. We could also implement the this-window/other-frame modifiers for xref-goto-xref later. >> ...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. The inconsistency is unfortunate, but it stems from our attempt to shoehorn the xref buffer into two different use cases. Ultimately, I think the multiple-choice xref-find-definitions case would be better served by a selection UI that emphasizes its transitiveness, goes away as soon as the user made their choice, and itself has no long-term impact on the window configuration. It's probably best implemented using an overlay of some sort on top of the current frame. See the similar feature in Atom (who inherited it from Sublime) on the screenshots here: https://atom.io/docs/latest/using-atom-moving-in-atom I went in that direction in xref previously, when all changes made to the window configuration by ,/./n/p were being undone before the next command. But that was a half-measure anyway, and the "transient" interface doesn't serve other commands well (those where you usually want to operate on several locations from the list, and not just pick one and forget the other matches). It's worth noting that SLIME uses its xref buffer exactly in a transient fashion, and Helmut's contribution had that behavior, but I've come to believe it's a mistake.