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 19:18:35 +0100 Message-ID: <56A666FB.3080709@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> <56A5EFEE.2080607@gmx.at> <56A6559E.5040301@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 1453745948 3044 80.91.229.3 (25 Jan 2016 18:19:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jan 2016 18:19:08 +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 19:18:58 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 1aNlj7-0003p7-4G for ged-emacs-devel@m.gmane.org; Mon, 25 Jan 2016 19:18:57 +0100 Original-Received: from localhost ([::1]:40186 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNlj6-00045I-BC for ged-emacs-devel@m.gmane.org; Mon, 25 Jan 2016 13:18:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60271) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNlj2-00045C-EN for emacs-devel@gnu.org; Mon, 25 Jan 2016 13:18:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNliz-0000oU-7R for emacs-devel@gnu.org; Mon, 25 Jan 2016 13:18:52 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:55537) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNliy-0000oK-Ts; Mon, 25 Jan 2016 13:18:49 -0500 Original-Received: from [192.168.1.101] ([212.95.7.92]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MIQlv-1aOawD3okx-0049lu; Mon, 25 Jan 2016 19:18:47 +0100 In-Reply-To: <56A6559E.5040301@yandex.ru> X-Provags-ID: V03:K0:mE4yUDzKj9ej/DDRV1TTCpSs0pTbbbC+nQD0fartF1IFjCx2SP9 wa7yOy7kAX5sDIGFGOwsiRl+JEMr32YATRsS11Mj857H1oPl4h1SFfQ/lrFD7oPpdmzEQwv ybs2QjlbASKmvnD+NUQSrA11OWh3D0Os8ZLD/7cA0AJYY0ZlRpMFq7o0BMUzl4zjzKsUeKU Jh+QUR582xGota4n2cDKg== X-UI-Out-Filterresults: notjunk:1;V01:K0:XHGaQe5TV2w=:kTCKznb+2Wu4LDei4tfQwx mVHCkJ8yUHYeyaSNVWSm60QN+ZESa9qx66T6Uk2HyxIKWxYuk/gN1wsfWGLZjKtE/wPckYOlk A3iEGsqLSIxyOnYEr01H/wWB9LgUg9eAT+pdm2o0A1zLfQtSFs7D+lMdAiH8yh8d4HEUteGtV Jd8qIn2qHOxtm+tpUKn6hQ9AWhTGBS2hp5n/vx4u950LCBEZdTH9KBYLLXFTOMT/uIkaiWKkf k6Tu1KuSsG6NFeeMpcl2sk1XQMSgLWU6Qn5aQuD0hDdes2Iptms5/hFfozIqPosS9TYZoHvds wHmKUzsaOv8MKjtBvbPqCYzV3ViYhDmjqm4UmDrObi2pofiX/nO43EfdNYO4cwbHU/sfapShh pWGoVNjzrFsgefIy3TRUZja9SG6ab4A9N5fC3zFKfYlYSlxKfCkeOLHrDjMrR1zovh7E+2/GP FgT7nfjuDzrz4GPdx5zaWblgjAFvIr/Qqbj2oMSRyxQ0Go7Q7FiJ0REA89N1H7MEqubySQK4F 0AF/6iUB6/qpJq4h7ZuwuFvTCBCXVL7FHOMUu3VHntC55BWA85eVy0V7PctTu6onmsIKVjrUl oqH8ngOevxhuv1vhA+zLEFYYrmlkawKRPS1Uh65J3J+TB1/tO+ovl88jnaJcfoyYaKNM+sM6x FDr5ur71wMytj6pCpPcECIDZe4i6Ikypg/wUfNH21vwQkXLyF1rhSQYN+ghC4Ai/hnr1dmdTI wjeRMaDg4b003BhvZCo/HQ6l8Siz1kSBrHdOcuIV0Rw4I/Q7r7l+kVr+Im4DSZmQhlbzyW4v X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.20 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:198803 Archived-At: >> ------------ >> | O | >> | | >> |------------| >> | X | >> ------------ > > That's not so fine: I'd prefer to go to > > ------------ > | O | X | > | | | > | | | > | | | > ------------ > > at this step instead. Which is how Emacs normally allocates windows. > > Note the benefit: as long as the contents of O fit in its width (no ex= ceedingly-long lines), we get to see more of its contents. > > Ideally, on the next step we get a layout like this: > > ------------ > | O | X | > | |------| > | | | > | | T | > ------------ This is no good layout for IDEs. Source/code windows like O and T should always form a rectangle. Auxiliary windows like X should be arranged around that rectangle. And obviously it precludes fitting *xref* to its buffer width. A window fit to its buffer should never impose its width/height on other windows. > But I can live with O being split instead. This would nullify the above benefit. In any case the larger of the two windows will be split. > Having X in the split below O might be even better (giving T a > full-height window), but I don't see a easy way to that configuration.= Neither do I. > Note, however, that from the X-below-O configuration I quoted above > you can't each either of the good target configurations. You could split the parent window of O and X. >> to >> >> ------------ >> | O | T | >> | | | >> |------------| >> | X | >> ------------ > > This would be a waste of space on the right side of X. When X has short lines it could be shown on the left of O like this. ----------------- |X| O | T | | | | | | | | | | | | | | | | | ----------------- >> IIUC these buffers get filled asynchronously. How should >> =91temp-buffer-resize-mode=92 work with such buffers? > > Resize after every bit of output? Admittedly, it can be annoying. Very. >> Do you produce *xref* asynchronously? > > Not yet, we I hope we manage to do that. Only working synchronously is= > one of its drawbacks compared to Grep. Then =91fit-window-to-buffer=92 will be moot anyway. > We'd split one of the windows again and show the target buffer in the > new window. See my diagram at the beginning of this email. Then we're back at the initial problem that by default Emacs never shows more than two windows on a frame :-( >> 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. > > So, then problem will occur when I un-dedicate it at the end, in > unwind-protect? I suppose I can save its dedication status, and then > restore it. Right. I doubt you can do any better. But do it. > Indeed. Anyway, I'd be fine with changing the default, as long as > side-by-side splits are still preferred. It always depends on the size and shape of your frame. > All right, *Compilation*, then? IIRC the original question was where *Grep* and *Compilation* display their targets. Here I practically always create a new window. But by default the target will be usually displayed in the original window, the one selected at the time you called grep or compile. > (I'm not too enamored with your description of Grep solution--too many= > steps--but that's beside the point.) I prefer the first step rather than being overwhelmed by too many hits with too much information. And the second step is the same I use for plain searching in buffers. > Yes. Like I said, when I switch to it manually and press `q', it just > buries the Help buffer. Is there a particular problem scenario you > have in mind? No. I'm always glad if it works as intended. > IMHO, the users won't bother, and will either switch to that buffer > manually, or just repeat the search. So let's not prevent them from doing that ;-) martin