From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: xref and displaying locations in appropriate window or frame Date: Sun, 24 Jan 2016 15:38:07 +0100 Message-ID: <56A4E1CF.9010002@gmx.at> 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> <56A4ADA5.4070607@gmx.at> <56A4CB54.90808@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1453646331 17040 80.91.229.3 (24 Jan 2016 14:38:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Jan 2016 14:38:51 +0000 (UTC) Cc: Helmut Eller , emacs-devel@gnu.org To: Dmitry Gutov , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 24 15:38:42 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 1aNLoP-0007VC-Bi for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 15:38:41 +0100 Original-Received: from localhost ([::1]:60674 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNLoL-00048A-J3 for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 09:38:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNLo6-000483-VP for emacs-devel@gnu.org; Sun, 24 Jan 2016 09:38:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNLo1-0001uE-VR for emacs-devel@gnu.org; Sun, 24 Jan 2016 09:38:22 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:64684) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNLo1-0001u9-Ky; Sun, 24 Jan 2016 09:38:17 -0500 Original-Received: from [192.168.1.100] ([212.95.7.84]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LtIdP-1ZzkI01XUh-012sTG; Sun, 24 Jan 2016 15:38:15 +0100 In-Reply-To: <56A4CB54.90808@yandex.ru> X-Provags-ID: V03:K0:5XcIFAk12SnnlbpGCmIxtuzU2GlpE0gqxN1Mr484Mji+7H45SSs vei0Q1/bq7ZTe4DCelYNvv6XAcRNydguDt9lrxnSrP4dlcEhanO16B+iDNN0RQrOrbWMlls 4RnOARQyVEsHNklxLFDLI/p0FyKQIHLVVcEvb076OK29e69T7J/cG+Q7SbM8C+OqvA3ESVD FS5HqG3q9iTm+jj7Q6CdQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:i2enWrGfMoM=:OIWfT2XC3x6ndDO4u6KXR7 8KF9Uro0dFxIFM/s7elVQ014iR0h3UL6mDv7H2X9+mbQ1cOVLU5waVVFBeWrVoqWYC3KnvmPi lcWIRQIjqUaHkbl96qOZs2shcM7UVfA2kvCDn4mFaTwkQEwLNOudmDifGXWlPvCEEE97RexNU uDpHukApKcUi2eTJ6PqT/RABTuZU1Nzcp9/kbFVv57ifZ1R1dZMG6Vnl8cSodzD5TLJJ6BEYI JJpL9sxT9wwdAs49cXKk7hVqtyUPsFAabyQ5vUhN6gE28tEhSGThDukcgxiS63B8kb+C8SkOX kGKsm1tMyWkTeydjo/Ve8Pp+flbo7FCNZS8wBlwcTAp4P+Adfv//2ZFm3fV0a7jjdCyUD+V6M TDLQt3HI5WhgqU2PuAQ7qpoNNPSzdnq/lo7SteZaP8sSS74HkvGw7eir/95phODLbGczf4dZ2 POpN9LLw5irjWvG3by4p2/G7xNdSA/bT39QYY+PsJQZ0YTLmALf/5JKmU8IrKRqsR8IbxyxVN reYnlQ6pW9svxTducSGW4I4a4p1mnheZFUcpCayMb/PHyitnvR2QQWWaX4Pw0ra7I+My95OQM gw96HLsz1yVCe9hkz9o1NGRElvTT4E762uIWYVGqYO3BQaBZC97lacigAw3ttfeY9ytdKxSsf zBPGbuNOr178N6815ib5Xgy0QiLWzzUKt9s1AH0BXNAry1poF+1dagpwwcrCF4PnQwKKpRnMx XQGn9E1QjVvBs82r4iFxx1W2h59+qWtRnZZG7OgAWNTSxqZne7FCawD4LPdxMrkro38r/lBZ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.18 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:198698 Archived-At: > With its standard-output binding, with-temp-buffer-window is a kind of= > weird beast. Why would I prefer to use the low-level printing > primitives, instead of `insert'? Ignore =91standard-output=92. The only important thing to know is that =91with-temp-buffer-window=92 initially erases the buffer it displays, so= you have to =91insert=92 within BODY and never before. > Otherwise, I'd be happy to make temp-buffer-resize-mode work. But > anyway, it seems orthogonal to my question: after *xref* is displayed > already, how do I show locations from it? Currently the *xref* window occupies one half of my screen and usually wastes lots of screen space. So making it smaller should give users more space for the buffers they eventually want to show. > > By default *xref* would be shown at > > the bottom of the frame with columns arranged as in the *Completion= s* > > buffer. > > xref's output is tree-like. It seems hard to arrange it in multiple co= lumns. I thought it's forest-like. If it's really tree-like then rotating it will be probably hard :-( > What if the original window is already at the bottom of the frame? > And, say, isn't tall enough to split? Then *xref* will reuse the window on the top that cannot be resized and we lose. I wonder whether this happens often with the *Completions* window though. >> Conceptually, this should allow to split the "original" window into t= wo >> side-by-side windows where the left one would continue to display the= >> original buffer and the right one would display the buffer chosen by >> =91xref-find-definitions-other-window=92. If there's already another= window >> on the side of the original window, that window would be reused by >> =91xref-find-definitions-other-window=92. > > How will this happen? With a wide window, =91split-window-sensibly=92 will probably try to spli= t that window into two side-by-side windows based on the assumption that it didn't do so before when displaying *xref* (that's why I would try to display *xref* on the bottom). As for the "not reusing the original window part" this will happen only if the original window is not the larger one. So you would have to temporarily select the original window in the =91xref-find-definitions-other-window=92 call. Not nice, but I se= e no better choice. You could also temporarily dedicate the original window to its buffer. Not nice either. >> Obviously, if the frame is too narrow, splitting will fail and the >> buffer will be shown in the original window. But, as mentioned above= , >> there's nothing you can do about this. The doc-string of >> =91xref-find-definitions-other-window=92 should probably mention it. > > I imagine then the user might expect it to be shown above or below the= > original window. Won't they? How would we do that? We have already two vertically stacked windows - the original one and the *xref* window. As a rule, =91display-buffer=92 refuses to make a third window. The default of =91split-height-threshold= =92 is 80 and we usually start with a total root window height of 34. I asked a couple of times whether this makes any sense but nobody cared. Now obviously you can use =91display-buffer-overriding-action=92. But th= e idea of =91display-buffer=92 based functions is to give users the necessa= ry means to tweak the behavior to their working environment (display size, frame/window preferences, maximized/normal-sized frames, etc.). So you want to have a good reason for overriding the user. > Yes, displaying the buffers in the original window is not hard, we > just have to save a reference to it (although it'd be bad if the user > switches to *xref* in that window manually). Why would she want to do that if you keep *xref* visible as long as it's needed? If the *xref* window is gone, the user should never switch to *xref* manually but ask you to redisplay it. Note: Everything I wrote here is based on your initial assumption to keep *xref* visible all the time. If you don't do that, the three windows rule doesn't apply and you shouldn't have any of the problems I cited. martin