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: Tue, 26 Jan 2016 01:39:23 +0300 Message-ID: <56A6A41B.20001@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> <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> <56A666FB.3080709@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1453761593 3191 80.91.229.3 (25 Jan 2016 22:39:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jan 2016 22:39:53 +0000 (UTC) Cc: Helmut Eller , emacs-devel@gnu.org To: martin rudalics , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 25 23:39:44 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 1aNpnT-0004Ue-Az for ged-emacs-devel@m.gmane.org; Mon, 25 Jan 2016 23:39:43 +0100 Original-Received: from localhost ([::1]:41112 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNpnS-0006BW-M6 for ged-emacs-devel@m.gmane.org; Mon, 25 Jan 2016 17:39:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37437) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNpnF-0006AV-HD for emacs-devel@gnu.org; Mon, 25 Jan 2016 17:39:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNpnC-0002M5-91 for emacs-devel@gnu.org; Mon, 25 Jan 2016 17:39:29 -0500 Original-Received: from mail-lb0-x22a.google.com ([2a00:1450:4010:c04::22a]:32864) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNpnB-0002M0-SK; Mon, 25 Jan 2016 17:39:26 -0500 Original-Received: by mail-lb0-x22a.google.com with SMTP id x4so83203442lbm.0; Mon, 25 Jan 2016 14:39:25 -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=ec00ydcvC/rbC5laQGn+nwSNR/ZL+VytZJtYJmO5PFs=; b=x7n7PJ/9le9EVlwh+v0z3PQY9AnI7UIsrfMNfSoAVp1E6ABddNVLUd0MI292Kvtz8N 8Jryn9eeM4KBTOUMhyJmowWs9uBdbCi05+nfw3PRV/XqvO+JdM90BKkQyw44XZgKG2nA dqjCtp0gmFBXB5KYFyq35y4BnYl9tsJVRY3pQ/4jMyxEBtAk92I3FNhO1f11fxZ74AhI brgDSZ1I0Tu5u9CAoqLzYy8IYjRYwDtOlAYOyeZa1zia7U0EMlXGeyGbPaKohVhBc/Z0 eH9CnMcc4RUs0od9QWikntCj52/59Km9R8Ae04/SrgjzbSmFXjG1vWZMekWS61el3ggV Unbg== 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=ec00ydcvC/rbC5laQGn+nwSNR/ZL+VytZJtYJmO5PFs=; b=Rm0DFROo2H56lz06SoRQ7m8WGix+veekzWDbvkA99tTSX6INT0564Mac4dPPrnoUZb 3u3mbZwr+svf8toEtmyTe3Vv8Yk/VSwIaBz2nMR+dcU/sDpb8i84U9rd/5mkwzVpSV8o jcT3XH9V/MUSflri+ZWAcgnhAn1dQYmHw53oIrl2Rzv6IS65z3ppLZUgaR3WIX1MHWGu wm42nEunq5QRPBFTxGSZbcsgIZv9fZrgUxuI0CMVXQjN7qEOMUnkaMn1IxMNc1XchH8K RLE7qMsp9hNEYBa5+LupQfbapg+jiLTXu8fu8nybR5PlxWlHbqYriDDxkeV2bCzGPv6w H3PQ== X-Gm-Message-State: AG10YOTLtDI+9utKIVLc6o/wygRMzCguiiwV3cDhy9ORS4w9Eph2iHT/nZSYERxFv6+wJQ== X-Received: by 10.112.136.136 with SMTP id qa8mr7342193lbb.51.1453761564843; Mon, 25 Jan 2016 14:39:24 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id c192sm3097493lfb.16.2016.01.25.14.39.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jan 2016 14:39:23 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <56A666FB.3080709@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c04::22a 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:198820 Archived-At: On 01/25/2016 09:18 PM, martin rudalics wrote: > 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. IDE-like window layout is not one of my goals here. I think I've explained how it would be less than idea. That's not to say that the users shouldn't be able to choose this window management strategy (using display-buffer-alist?), but let's not bake this choice into xref. > > 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. It might be handy to split the window that shows the shortest buffer, if all other parameters are equal. But that's tangential to this discussion. > > 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. Very well (they have a parent window?). But that seems to imply manual layout management, instead of using e.g. pop-to-buffer. > When X has short lines it could be shown on the left of O like this. > > ----------------- > |X| O | T | > | | | | > | | | | > | | | | > | | | | > ----------------- Let's say that the lines in X are about half of the frame's width. At least, that's my usual experience. > >> 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 ‘fit-window-to-buffer’ will be moot anyway. Yes, sorry. It could still be useful in the alternative presentation method for xref-find-definitions, to be written by somebody, sometimes later. > > 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 :-( I suppose so. But its resolution should be orthogonal to what I do. > >> 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. Thanks! > > 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. Ok, always preferred on my machine (229x58), then. :) You might want to initiate a separate discussion about that. I'm not the person to make this choice, and nobody else is responding, this deep into this thread. > > 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. The question was about the user being able to bury *Grep*, then switch back to it, and continue using it without issue. But indeed, *Grep* and *Compilation* have it easier. > > 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 ;-) All right.