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: Sun, 24 Jan 2016 20:08:36 +0300 Message-ID: <56A50514.9040509@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> 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 1453655340 22213 80.91.229.3 (24 Jan 2016 17:09:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Jan 2016 17:09:00 +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 Sun Jan 24 18:08:59 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 1aNO9q-0004lG-Au for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 18:08:58 +0100 Original-Received: from localhost ([::1]:32919 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNO9p-0004SL-6m for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 12:08:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNO9b-0004SE-0O for emacs-devel@gnu.org; Sun, 24 Jan 2016 12:08:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNO9X-0008O6-QD for emacs-devel@gnu.org; Sun, 24 Jan 2016 12:08:42 -0500 Original-Received: from mail-lb0-x232.google.com ([2a00:1450:4010:c04::232]:35656) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNO9X-0008O2-CC; Sun, 24 Jan 2016 12:08:39 -0500 Original-Received: by mail-lb0-x232.google.com with SMTP id bc4so63075976lbc.2; Sun, 24 Jan 2016 09:08:39 -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=TadoiafRzdL1RQuwEDI1o4nVi4guTw0faFRQ1eun9hM=; b=CuEfLRNCrpSTHh641Ode0dj/YvmusFkXOEv8Vmg1f3Xn3ux0MSQiml5jWwZHkb4P9M XByzAvLvrDxwkV3uJy06lcxPq9gxOm41nOAVqBvvByI+sBlC09isX/QTsE5vm1hLXsAx BDQoNJfurmMoMOuD66+GhspJ+7sbdjT3Uj/yCAgVDK/xaSq5FblkWGlHkhiSf7oaZik2 rxsQ5b5Ct096G8OW2B6jtLcTc9wBjxhVnXaddyMIPMME17/1/fqWNlAZ+W8qjcY5ks40 Q/5LyJYxqhOjOjFbi/YiNB+Ic8Q2vAaCh2Th3nTf///2tDo84YJxFPHSGaTTSsS8C6op C/qw== 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=TadoiafRzdL1RQuwEDI1o4nVi4guTw0faFRQ1eun9hM=; b=WdMAG4C2DL1DqxDYwIQ1hnfNlLNEyeeP9HzSvsIDiKdxj3so/dVuLKJpJ1d1Gb9IPn Ou7joh+7zfigsJ9obNHNmVTpxFvPfjzVkcLyK5KA+FTNHh6yF4IG3pksCuMJ8rlT+hAh AmSL+epvMd2YI4F9k6dWy1NUcaSH6nPo5h/zqROiqXp3eaaCA1lCjbLselBg972S4nR6 aZ0Lo3yR1wCONP2x5YRpzgiGXm7nWCvVVCST6B4NwtQSXTlxjaVEsxb5O+1ZPaGfNyLZ NKxBxzIdOGRUKQp9sANPlLvoVGcIEbkYPSSmopIfEhyDnWOQf3TuBlRZgdoJdznbcx9Q FRTw== X-Gm-Message-State: AG10YOSO+0YA+YJMTQbZcmq6kHF6FmCS2ZQ9mGbmY1GAA+OvS+jPSFO5Af+0WNXFKe9KAQ== X-Received: by 10.112.162.168 with SMTP id yb8mr4599929lbb.36.1453655318521; Sun, 24 Jan 2016 09:08:38 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id 64sm2204599lfx.19.2016.01.24.09.08.37 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jan 2016 09:08:37 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <56A4E1CF.9010002@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::232 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:198709 Archived-At: On 01/24/2016 05:38 PM, martin rudalics wrote: > Ignore ‘standard-output’. The only important thing to know is that > ‘with-temp-buffer-window’ initially erases the buffer it displays, so > you have to ‘insert’ within BODY and never before. That doesn't seem to be true. Try: (with-temp-buffer-window "test" t nil (insert "abc")) It shows the buffer "test" empty, and "abc" gets inserted into the buffer that was current before with-temp-buffer-window call. > 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. Yup. That's about temp-buffer-resize-mode. But it seems orthogonal to the problem I currently have. > I thought it's forest-like. If it's really tree-like then rotating it > will be probably hard :-( Anyway, IME most lines in xref take more than half of its width (which is ~110 here). So rearranging them wouldn't help much. > > 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. The current issue is that people want *xref* to behave less like *Completions* (transient, disappearing soon) and more like *Compilation*, which stays until the user explicitly buries it or kills it or its window. That may be not ideal for xref-find-definitions, but it seems more appropriate for all other commands using the xref UI. > With a wide window, ‘split-window-sensibly’ will probably try to split > 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 ‘xref-find-definitions-other-window’ call. Not nice, but I see > no better choice. You could also temporarily dedicate the original > window to its buffer. Not nice either. I think I need to "not reuse the original window", nor xref's window. And reusing the original window is more preferable than reusing the xref's window. Can I make xref's window temporarily dedicated, and call pop-to-buffer from the original window? > How would we do that? We have already two vertically stacked windows - > the original one and the *xref* window. As a rule, ‘display-buffer’ > refuses to make a third window. The default of ‘split-height-threshold’ > is 80 and we usually start with a total root window height of 34. So if the frame is too narrow, and there are two windows only, the location will be displayed in the original window? OK, that should be fine. > I asked a couple of times whether this makes any sense but nobody cared. What makes sense? Having a split threshold? I think it does. Beyond that, I'd say window management might be too complex for a casual commenter to say whether it makes sense or not. > Now obviously you can use ‘display-buffer-overriding-action’. But the > idea of ‘display-buffer’ based functions is to give users the necessary > 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. Right. I really want to use the standard behavior as much as possible. > > 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. They can press `q', but then switch back to it a while later. I see no reason to prohibit this. Do we prohibit things like that in some other buffers? > 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. That is indeed the whole reason I've written the "I'm stumped" email.