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: Mon, 25 Jan 2016 10:50:38 +0100 Message-ID: <56A5EFEE.2080607@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> <56A4E1CF.9010002@gmx.at> <56A50514.9040509@yandex.ru> <56A5140F.2040905@gmx.at> <56A51FA4.5020807@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 1453715481 6461 80.91.229.3 (25 Jan 2016 09:51:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jan 2016 09:51:21 +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 Mon Jan 25 10:51:10 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 1aNdnh-0004zg-F3 for ged-emacs-devel@m.gmane.org; Mon, 25 Jan 2016 10:51:09 +0100 Original-Received: from localhost ([::1]:36637 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNdng-00063y-OQ for ged-emacs-devel@m.gmane.org; Mon, 25 Jan 2016 04:51:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNdnW-00060a-LQ for emacs-devel@gnu.org; Mon, 25 Jan 2016 04:51:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNdnT-0002Ox-32 for emacs-devel@gnu.org; Mon, 25 Jan 2016 04:50:58 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:51640) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNdnN-0002It-Ae; Mon, 25 Jan 2016 04:50:49 -0500 Original-Received: from [192.168.1.101] ([212.95.7.92]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LwZtX-1a2mDJ1P6l-018O9x; Mon, 25 Jan 2016 10:50:46 +0100 In-Reply-To: <56A51FA4.5020807@yandex.ru> X-Provags-ID: V03:K0:869G68vIM+wyM0atYvEOLGSUxCwrSr13TfWT07vJY6T0gYC+Qse 4jiBZ/d/nHhW/tFfOkPY0WgcODCn146esQWC/Q/hhcxoTp4OXovpI8nGBwtC5BJqzg67YjN rWqBVN+iMy5w883k/cgpsqVzugqgY77M6RUiOOoinPSd4JxpQW2e35aszpJzcDPyrkK0eNh iM0G7O0QOOUxHOTpoAhEA== X-UI-Out-Filterresults: notjunk:1;V01:K0:mVpVs4LQq3A=:vY33k/oOc0XiVxKdh0cOJA 5wSvC3SWCvAnXrSx1lu9GPa7VWF67o/7c5J+BmqlUgrGXGzkb3dimad2yFN3vqwtdxao9Z8zu PFj8HGWYr5Jtfz7imSB8FS3kM9GW+h1EeENdQM0OIghJ3R+iHVFWngWFd2fhlKzSmIwBBODSM ybwifvCkL3WF60wxsUiDivP9EXGZatrHL+pIFZdwQPs3huu2HrRDkFjQSMImxCGt46kciKpjy tthBkBfAgcyLpnXvsPKN1Knitd6qckJNUnPU8QDeEYFqrtSXOeWlJXRbX4d1eVaVi8cRMVXhn yskMX+TC8dvCGT+INzmFEeXpoRIBS9AllryR6mWG4vphC2qOrSCGCeyrRA2prJl+/Xw+4h2yu NeLk25xbxHncGT9S5A2arV/OSaKZ1AmVpWzaX8DIP1PtqDvptmOQh6aXSqD+bV6F0mjTHU2b6 GwAgi43ylTCQxp5xKshiGOM9tI3InbclnBxVVVFqNLHiZ7ccbFCjaZPcExzC5zXjMwEXKZsX6 eoOGXXRCKHCg5cFoSu9VgCkdJLVbvZDgdyeDSp/9iuitFn/01ynidxhVPMm7kEo2NfxeEq4dm HXWzfVjGVQZ5mKDTe9G/8HL5bp1RKAjoAJGrM5c3feJqZWXqAeDo+AnWaczdTZFbLsyqjsVFa 9Qga+bHqcyOCwL19814pcRiWSVl1giQar/D1F0DLyOOPalZlp7lxp6E7BGR3gPT/5W5mFPAol 4KK9Yj0cpuDczYl4zMCpzEcbGL1kjJoMQ1FiP0xLzboc2Lj5nhE6sItMXLBCqXBLiychX/f/ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.19 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:198754 Archived-At: > Could we decouple temp-buffer-resize-mode from the "write to > standard-output" mode of operation? Can I just call > resize-temp-buffer-window once after the xref buffer is displayed? Hopefully. Just add (when temp-buffer-resize-mode (resize-temp-buffer-window window)) at some suitable place. > If won't make any difference if *xref* is tall enough (like when we > display Grep results in it). If the *xref* buffer usually fills its window in both dimensions there's no need to do anything. > And anyway, *xref* window getting split is not a problem, as far as > I'm concerned. Keeping *xref* buffer visible is the goal. So the main problem is that showing the target buffer uses the *xref* window and you want to avoid that. In the following let's assume that "O" is the originally selected window, "X" is the *xref* window, "T" is the target window that shows the defined object and "N" is some other non-selected window. Suppose O is the sole window on its frame. In a "vertically oriented" frame you would go from ----- | O | | | | | | | | | ----- via ----- | O | | | | | |-----| | X | ----- to ----- | O | |-----| | T | |-----| | X | ----- and subsequently T should be reused for the remaining targets. This will work when the user has customized =91split-height-threshold=92 appropriately - otherwise O will be used for showing T. In a "horizontally" orientd frame you would go from ------------ | O | | | | | | | ------------ via ------------ | O | | | |------------| | X | ------------ to ------------ | O | T | | | | |------------| | X | ------------ This will usually work with the default =91split-width-threshold=92, otherwise O gets used for showing T. Now suppose that both O and N exist. In this case you would, in the vertically oriented case, go from ----- | O | | | |-----| | N | | | ----- via ----- | O | |-----| | N | |-----| | X | ----- to ----- | O | |-----| | T | |-----| | X | ----- Horizontally from ------------ | O | N | | | | | | | | | | ------------ via ------------ | O | N | | | | |------------| | X | ------------ to ------------ | O | T | | | | |------------| | X | ------------ One tricky case is to set up X when O and N exist already. If you reuse N for showing X you will find it difficult to subsequently show T without reusing X. That's why I would try to always create a new, hopefully smaller, window for X. The second tricky case is to make sure that for a new target always the previous T window gets used via =91display-buffer-use-some-window=92. To= make this happen you will either have to mark the O and X windows as dedicated or make sure the T window is the LRU window when displaying the next target. (I silently assumed that N will be automatically used for displaying T initially because O was selected and X would have to be selected by you when it's created.) Hopefully, this covers the most common cases we will see in the wild. > Maybe the actual solution is indeed to use a different display > mechanism for xref-find-definitions with several options. Then it > could use an actual temporary electric window at the bottom of the > current window that gets deleted as soon as we're done. At least that's how I would customize the display of *xref*. Whatever you choose for the default might be entirely different based on the needs of a majority of users. > We don't use temp-buffer-resize-mode in Compilation or Grep buffers, > right? Even though Grep likewise might return only a few matches. IIUC these buffers get filled asynchronously. How should =91temp-buffer-resize-mode=92 work with such buffers? Do you produce *xr= ef* asynchronously? > Were the Help windows actually _temporary_ sometime? Depends on the semantics of "temporary". > If I have a frame with two full-height windows side-by-side, and I'm > calling project-find-regexp which returns a lot of results, I'd want > it to be displayed in the "other" window, rather than necessarily > split the current one. I thought the other window is where you eventually wanted to show the target buffer. > Or, if I have just one window in a maximized frame, and do the search,= > and I've customized the split thresholds appropriately, I want > split-window-right to be called, and see *xref* to the right. Once more: Where would you show the target buffer then? I think what you say makes perfect sense in a setup where the *xref* buffer is replaced by the target buffer. But we're talking about the scenario where the *xref* buffer should remain visible after displaying the target buffer. > Instead of having the "split below" performed, and seeing *xref* use > full width, and only half the height of the current frame. Hopefully less than half the height when you fit the window to its buffer. >> Yes. But the one-window-per-frame user might get a new frame then. >> She's not your target (because of the assumption that the original >> window and the *xref* window are already there when you want to displ= ay >> the other buffer). > > Wouldn't she want a new frame anyway? I thought about people who work with one and only one window. We shouldn't create a no-way-out situation for them. >> But even softly (that's all you need here) dedicated >> windows sometimes behave erratically. > > Can we fix that? So far using dedicated buffers sounds like the most > appropriate solution. One problem with dedicated windows is that if an application and the user both start dedicating the same window to its buffer there might be conflicts. I doubt that such conflicts can be "fixed" easily. >> If the other window is the *xref* window and the *xref* window was >> "used" later. You might have to "touch" it from time to time ;-) > > That doesn't sound like something a display-buffer consumer should > do. Should it? It's a hack, indeed. >> A threshold that is more than twice as large as the default value? > > (frame-height) evaluates to 58 here. Less than 80, still. > Maybe it does make sense, maybe it doesn't. I'm fine with it, though, > because I don't mind doing doing my vertical splits manually. =91display-buffer=92 can't split it. The very first example above will w= ork only if the user has customized =91split-height-threshold=92. Otherwise,= T will be shown in the O window. > But *Grep* works fine in that situation, doesn't it? I never use it. My grep hits appear in a side window where I just list the files where at least one hit occurred. Selecting a file shows all hits in that file. Selecting a particular hit shows that hit in the window on the right. > quit-window is different, and it works as expected anyway, I'd say: if= > the window configuration hasn't changed too much, it will undo the > action that displayed it. If the window configuration did change too > much, it will just bury the current buffer. Everybody happy. Did you try it after manually switching to such a buffer? >> Maybe >> some command to "bring back" the *xref* buffer would be more useful t= han >> simply switching to it. > > I can easily imagine having several *xref* buffers at the same time > (we'll just have to add more coherent naming). Then I'd say: Maybe some prefixed command to "bring back" an existing *xref* buffer would be more useful than simply switching to it. martin