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: Tue, 26 Jan 2016 11:05:12 +0100 Message-ID: <56A744D8.6040205@gmx.at> References: <83wprimto9.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> <87fuxla27x.fsf@acer.localhost.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1453802756 9136 80.91.229.3 (26 Jan 2016 10:05:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Jan 2016 10:05:56 +0000 (UTC) Cc: Helmut Eller , emacs-devel@gnu.org To: Ingo Lohmar , Dmitry Gutov , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 26 11:05:46 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 1aO0VL-0006wG-Ge for ged-emacs-devel@m.gmane.org; Tue, 26 Jan 2016 11:05:43 +0100 Original-Received: from localhost ([::1]:42727 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aO0VK-0001Ej-O8 for ged-emacs-devel@m.gmane.org; Tue, 26 Jan 2016 05:05:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57541) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aO0V7-0001De-2W for emacs-devel@gnu.org; Tue, 26 Jan 2016 05:05:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aO0V2-0007jU-0o for emacs-devel@gnu.org; Tue, 26 Jan 2016 05:05:29 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:49808) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aO0V1-0007id-N1; Tue, 26 Jan 2016 05:05:23 -0500 Original-Received: from [192.168.1.100] ([212.95.7.23]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0ML72n-1aNjW723X7-000IIR; Tue, 26 Jan 2016 11:05:22 +0100 In-Reply-To: <87fuxla27x.fsf@acer.localhost.com> X-Provags-ID: V03:K0:/JdAnFKzADMqaDeXSRXAcjsRtKldMo1qxx7bODbGGa813zkz8KY nrrDpxWTfY4QZsEcCdbebAg7ProcW6jCM3+93wg6+Uen2+uJgMPW5Y4VsQlN7Df/uU9+1Px 5YuBKRu0imAjhkXlaODUlfkEsmCsLwb2SEmHl+Z5gWAriaY6bybOntzQlZimPiYEEY4ee2l MOzt/EiGRDkjPjwIOyvSQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:eD68xEYusDo=:Z6/LPdbJPmnXy/TX1RRQZ5 llJXjGDM49Ez60igcvAnmoLQkZJl5Qdm3gtLWHMnvHQIdBc5aFEPC8kF3CRkwQqNz5j3DzbsH /f+1KSXyyOOOx9Tmd0abWmCG0URxn1bnAos5wfjBsV5MwptAJa+VLmkvI02CRH+7gw+vwhHpB VBzJrZ1NXgGtVUKqjJH8KkF+q4AMzdVXrT9peuS1FbElkubiWEL1PX4dS28Yw+aitGWczd0Xh 79XvN8fXGCodIAGdJsQInPQtk2mFGeKGug9+fHS7wGs2Ij5zf5eBN7ADO4TbC9njCsmauRrM6 +iitRdoThuJ+fiHjW0KPsE1Zi6ePO5rAL7S+JCZps4Xa2G6f+X3pRIXbSNyvd5tkO1YOdQ4KW 61zWmgZmSRPmSwz7UbNYWjJ8PqMbLn4JSr5vsu4h86wpRoxn8t4b2RODVG0K9eWIzbSDddpYQ El9iQAHzugdF5OV/eeQuy3t1Y4768kHD3PFQGxhhWP0TlqId+Bt4eZheLebHKsucc4dgrDAz8 GnRa5aa5LX9xDrIfPDak7SuBWoAcZKbWFwAeflu3uBycngQqBaTJaAiWcKEVIjWtRfGuUQSVV YOB/1Dov/rIyElsOYwfODFDLEYeIyWqCGXfBS8osDL+6uf4uxagVclSjyuwNTQwD2ARMimqZP VB670ZG/DSFJpCFc06A5Tu5CL6SO3QuuEiO1lqu9AchTypRIT0hTCCpE/6hM5meZSTs0XGIH3 agwJOgUebnLun5UEhFGgt/Py/KksgRC53hE6gyDu+S1ChoW+e/Hh0gxk0CYTdxgTxCGVQiEA 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:198839 Archived-At: >>> ------------ >>> | 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. > > FWIW, I love the overall direction of extending Emacs' IDE-related > facilities, *but* I do not think that it should strive to emulate all > their behavior, particularly not in this respect. AFAICT, you have not > given any argument for *why* these should be guidelines for a window > layout, except that IDEs do it that way. I'm no expert in IDEs, I don't use them and I don't advocate their concepts. So I'm certainly not qualified to give you an adequate response. Anyway. Years ago proposals were made how to turn Emacs into an IDE. You will find a remnant in the Perspectives work well even if you do the equivalent of C-x 4 C-f because of the distinction between view windows vs file windows. In Emacs this is more or less the "dedicated window" feature, but we have never really made it work for this. entry of etc/TODO. Now first we have to agree that in our example above O and T behave as "file windows" and X is a "view window". ECB calls view windows "informational windows". Emacs-IDE IIUC calls file windows "source window" and subdivides view windows into "menu windows" and "output windows". I'm not sure whether X would classify as a menu or output window, maybe it's both. In any case X is not a source window. Keeping file and view windows in a way that file windows form an inner rectangular area and view windows are arranged around that area has the following advantages: - View windows can be easily made persistent (which is what the current thread is about). Creating a file window does not remove them. Displaying a buffer in an existing file window does not affect them. - View windows can be arranged in a predictable way so that the user always finds them in a specified part of the frame. Compare this with the placement of X in the horizontal and vertical variations of our example. - Most IDEs implicitly dedicate view windows to their buffers. So we would not have to worry about how to do that with our X window. - Orthogonally to the before, view windows can be shared by different but related buffers in a predictable way. This means that you can switch view windows' buffers en bloc when switching, for example, from editing to debugging mode and back. - It's easy to switch from a navigational mode where you show view windows, to an editing mode where you expand the file windows area to fill the entire frame and back. Try that with the layout on the top of this reply or your layout below. - View windows can be easily arranged according to their orientation: Vertically oriented windows (like the speedbar, browsers for files, buffers, tags and bookmarks) on the left or right, horizontally oriented ones (like compilation output or the eshell window) at the top or bottom. This minimizes space and is the reason why I asked about the orientation of the *xref* window. - If you have at most one view window on each side of a frame, you can easily fit them to their buffers to additionally minimze space. Fitting windows in the file windows area is much more tricky and may have unwanted side-effects. > I regularly curse at the braindead window management of any IDE I have > had to work with so far. Emacs shines in the flexibility with which I > can use all its features the way *I* want, and with the window layout I > deem suitable. And for me, that's literally *never* a rectangular area > for source files. In the above example, I find the displayed window > layout not only acceptable, but perfectly fine, just like > ------------ > | T | X | > | |------| > | | | > | | O | > ------------ > would be fine for me (not as a result of the described workflow, but as > a layout resulting from any kind of workflow). Just that such layout is quite tricky to set up. You have to (setq X (split-window O nil 'above)) followed by (setq T (split-window (window-parent O) nil 'left)) Most Emacs developers wouldn't even know that such a possibility exist. > I think that it would be more useful if the present elaborate window > management would become more accessible (maybe it's only a matter of > documentation and a few variable settings) to fix a certain layout (or > layout-related guidelines like you described) *should the user want > that*. Wouldn't this eliminate most of the need to code such decisions > into very general features like xref? Personally, I prefer chaos. So I usually split the selected window to display a buffer and when my frame is crowded by too many small windows I kill them off in one rush. I certainly would not recommed this practice to anyone. So all I can do is to refer to layout decisions that have been made and tested elsewhere. martin