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 22:01:56 +0300 Message-ID: <56A51FA4.5020807@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> 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 1453662159 29323 80.91.229.3 (24 Jan 2016 19:02:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Jan 2016 19:02:39 +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 20:02:34 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 1aNPvk-0004ey-3K for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 20:02:32 +0100 Original-Received: from localhost ([::1]:33106 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNPvj-0002ON-B1 for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 14:02:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNPvI-00024D-QS for emacs-devel@gnu.org; Sun, 24 Jan 2016 14:02:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNPvD-0006aJ-Q3 for emacs-devel@gnu.org; Sun, 24 Jan 2016 14:02:04 -0500 Original-Received: from mail-lf0-x22f.google.com ([2a00:1450:4010:c07::22f]:34668) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNPvD-0006ZQ-Do; Sun, 24 Jan 2016 14:01:59 -0500 Original-Received: by mail-lf0-x22f.google.com with SMTP id 17so72958573lfz.1; Sun, 24 Jan 2016 11:01:59 -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=EQBqQe/E3TZV4WkYPGOYlQPgXLSW3+pgU9R8GgiF6KQ=; b=r7u8k06sqhu6/OSCpIY9t8qgjZmp5r4Cmyjp01yunH/5tWkGNNDxC8JP7XIZ0RNl/X nFUqxvhTzzSMIjinfemlSieOkTDU/zwUs+EcB4uHtzDKBe7xUMEm/m3pfOUrfzOTZmqA AHoRTJsEsHXz4fryrWQpQbyagKC7NqKN0wQV4/NjTBuGN6Dy5ybEgR99k4rMHGKMysmB NMVIXxLwFuEQbMN4+hlu/Zs36dAb1pCiGWi4AI80utKswu4+a5X5Vxjgs6+aGwfzSI89 Sz/C/GAtmPrY+5CyTdQgcFjYi6em9XcSWmPvy3xIax+1ounHyfhbuXO47rp01+tUCSBY IUlA== 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=EQBqQe/E3TZV4WkYPGOYlQPgXLSW3+pgU9R8GgiF6KQ=; b=RdE8J3tm9X45FzAbR63Z8Oia/qt09ZPs21YUWwMXh5xOhVMbHEpJ5Mdz2duiu8TbzS NT22KfiGU2VC4RktTX1n5dq0kMXrA81lUWlc9C/O3rvlRaJ7kRHjJPORBPFb/XaJomwc 2C5bK989Mp/3CNAZMAGoAA2UeW+R2kUb66v6Jm2b2PRD+IOgkxEBJUhDYk/bQHx95SSY n8lCix3AIFilJSQLM7UKAA3+cdwLl+tcYWfOBa1gS+4ELbhvYIbiZ047oTN0nJTDLNzB frjJ0d/IFVjxj0EuTMGipU5Fj9tKimGXiVegqX6au5zHm2apZJ+6+5tua5B7kgnO/psG 6nag== X-Gm-Message-State: AG10YOQ8FggoIVioyk/2SV1gKeOzEUffy1OGg1zD9RZPpvFVRap+XQAyld2LbTD/63xn+Q== X-Received: by 10.25.157.74 with SMTP id g71mr4992652lfe.80.1453662118590; Sun, 24 Jan 2016 11:01:58 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id l129sm2189736lfl.37.2016.01.24.11.01.56 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jan 2016 11:01:57 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <56A5140F.2040905@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::22f 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:198720 Archived-At: On 01/24/2016 09:12 PM, martin rudalics wrote: > Because of "Do not make that buffer current for running the forms in > BODY." You have to use ‘with-current-buffer’ around the ‘insert’. 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? > > Yup. That's about temp-buffer-resize-mode. But it seems orthogonal to > > the problem I currently have. > > Not entirely. I'd make the *xref* window as small as possible so it > doesn't get split. If won't make any difference if *xref* is tall enough (like when we display Grep results in it). And anyway, *xref* window getting split is not a problem, as far as I'm concerned. Keeping *xref* buffer visible is the goal. > And I'd like to see it always at the same frame position. 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. > > Anyway, IME most lines in xref take more than half of its width (which > > is ~110 here). So rearranging them wouldn't help much. > > With a maximized frame I get 200 columns here. Anyway. Don't bother > about laying out its contents. I get ~230, but the first thing I do is a side-by-side split. :) While we can do space-saving layout in *Completions*, most buffers, like file-visiting ones, don't have that luxury anyway. > But here usually the *xref* buffer never > occupies its full _height_. It might, if you call xref-find-references, or project-find-regexp, depending on what you're searching for. > > 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. > > This should be of no importance. We don't use temp-buffer-resize-mode in Compilation or Grep buffers, right? Even though Grep likewise might return only a few matches. > Help windows are also displayed via > ‘with-temp-buffer-window’ and don't disappear soon. Some people keep > the help window open all the time. Were the Help windows actually _temporary_ sometime? > The IMHO important aspect is that > *Completions* uses ‘display-buffer-at-bottom’ which calls plain > ‘split-window’ and thus is not limited by ‘split-height-threshold’. You > can obviously use ‘display-buffer-at-bottom’ with plain ‘display-buffer’ > as well. But then ‘temp-buffer-resize-mode’ won't get called. I don't know if it's that important. Also consider this: 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. 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. Instead of having the "split below" performed, and seeing *xref* use full width, and only half the height of the current frame. > > Can I make xref's window temporarily dedicated, and call pop-to-buffer > > from the original window? > > 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 display > the other buffer). Wouldn't she want a new frame anyway? > 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. > > 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. > > 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? > A threshold that is more than twice as large as the default value? (frame-height) evaluates to 58 here. 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. > >> 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. > > Neither do I. But in a sense this is a bit like an ediff user deleting > the control panel and switching back to it later. The ideal layout may > have gone at that time. But *Grep* works fine in that situation, doesn't it? > > Do we prohibit things like that in some other buffers? > > Not to my knowledge. I just wouldn't call it good user practice. For > example, switching to *Help* in an arbitrary window and doing > ‘quit-window’ there is not likely producing good results. The same will > hold for ‘q’ in a window where you manually switched to *xref*. 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. > Maybe > some command to "bring back" the *xref* buffer would be more useful than > 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).