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: Mon, 25 Jan 2016 20:04:30 +0300 Message-ID: <56A6559E.5040301@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> 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 1453741503 23015 80.91.229.3 (25 Jan 2016 17:05:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jan 2016 17:05:03 +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 18:04:57 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 1aNkZU-0004jS-UY for ged-emacs-devel@m.gmane.org; Mon, 25 Jan 2016 18:04:57 +0100 Original-Received: from localhost ([::1]:39893 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNkZR-0000dn-0J for ged-emacs-devel@m.gmane.org; Mon, 25 Jan 2016 12:04:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39622) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNkZC-0000dJ-CN for emacs-devel@gnu.org; Mon, 25 Jan 2016 12:04:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNkZ8-00012d-AY for emacs-devel@gnu.org; Mon, 25 Jan 2016 12:04:38 -0500 Original-Received: from mail-lf0-x234.google.com ([2a00:1450:4010:c07::234]:34472) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNkZ7-00012B-TS; Mon, 25 Jan 2016 12:04:34 -0500 Original-Received: by mail-lf0-x234.google.com with SMTP id 17so88764812lfz.1; Mon, 25 Jan 2016 09:04:33 -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=0vZi5FHNrqQKbYc2mXph1N+ZsW9t7d2cAaDUvm0VN8U=; b=W1YFWRnjAC8tBoAU87ipsQbMLLNOQK/8/xqlv98IkC1EUFKvwv00N+veO5OQ0Rcyj0 YcR/YE91rJ9KdYV+P3mVF3nP6RXQy8W06iBSeMHbUNKqsQpfUS512Fzdw4gl3p+O88BX rJde0AblNONz3/o4JhQMwB7i0b2ajcjA4QG6pdUjbsvC8nKQwF8aZPNo84mGwuLDtgE6 Ojt2olSwe7WCV3HnZIeaegzfCPIIscqel2JT6YF3DqKdeb/7Q+OLfTLhZO0ihrqzAjhh O/focxuUk35fwRFZNEZs+ekdOMyatOLIWiu+uHLfGsIPqH5bTG5zUMODFoZG/14wcU4t 03zw== 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=0vZi5FHNrqQKbYc2mXph1N+ZsW9t7d2cAaDUvm0VN8U=; b=ljb+CbF/PEtrlQ66E3Cymn4pKT3GEu484XATPlo9eoTy7YkVmhri91dm70HPZzQcNr iu4PnxzdHnNZk1OBPVFsPMpVeoB8JOYdcZTIZNNNDla6J2nC7URVHG/ahQtTgJ/290LK AIeUj5q979AFauc4CJ97qFckYY/mTzBR2WbXUSpK/fhZZgQmhqan+ay3hYnftNaCVWGk yIZYHQXr6JWSpkEDxpUWBKYAn3bbvL0QpKqDYggSyEU5lY8i250qQnL9xvmPmOARZ3ma 9AkwbSlJ8uMw8ICUPjYodhXibIGkdsuWiruDNEqVVawODYY05vilCfEXy9UTX/D35Waj bTbQ== X-Gm-Message-State: AG10YOTBdASy9Xhhr5sRd0IHlsJygis7NuCD+XCfz09Tommo2GN72oPvJUX2lAi9u3qZjQ== X-Received: by 10.25.78.66 with SMTP id c63mr5806043lfb.18.1453741472838; Mon, 25 Jan 2016 09:04:32 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id q8sm2857296lbf.24.2016.01.25.09.04.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jan 2016 09:04:31 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <56A5EFEE.2080607@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::234 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:198797 Archived-At: On 01/25/2016 12:50 PM, martin rudalics wrote: > If the *xref* buffer usually fills its window in both dimensions there's > no need to do anything. Usually or not, depends on which commands you use, and what you search for. Probably not most of the time. > ----- > | O | > |-----| > | T | > |-----| > | X | > ----- > > and subsequently T should be reused for the remaining targets. This > will work when the user has customized ‘split-height-threshold’ > appropriately - otherwise O will be used for showing T. That's fine. > In a "horizontally" orientd frame you would go from > > ------------ > | O | > | | > | | > | | > ------------ > > via > > ------------ > | 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 exceedingly-long lines), we get to see more of its contents. Ideally, on the next step we get a layout like this: ------------ | O | X | | |------| | | | | | T | ------------ But I can live with O being split instead. 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. Note, however, that from the X-below-O configuration I quoted above you can't each either of the good target configurations. > to > > ------------ > | O | T | > | | | > |------------| > | X | > ------------ This would be a waste of space on the right side of X. > Now suppose that both O and N exist. In this case you would, in the > vertically oriented case, go from > > ----- > | O | > | | > |-----| > | N | > | | > ----- > > via > > ----- > | O | > |-----| > | N | > |-----| > | X | > ----- > > to > > ----- > | O | > |-----| > | T | > |-----| > | X | > ----- This is also fine. > The second tricky case is to make sure that for a new target always the > previous T window gets used via ‘display-buffer-use-some-window’. To > make this happen you will either have to mark the O and X windows as > dedicated or make sure the T window is the LRU window when displaying > the next target. (I silently assumed that N will be automatically used > for displaying T initially because O was selected and X would have to be > selected by you when it's created.) Dedicated it is, then. > > 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. > > At least that's how I would customize the display of *xref*. Whatever > you choose for the default might be entirely different based on the > needs of a majority of users. Unless someone would like to send a patch, I'll hold off on implementing this, because we've not really stabilized on anything, including the calling convention of xref-show-xrefs-function. And the above feature would be closely related to that variable. > > We don't use temp-buffer-resize-mode in Compilation or Grep buffers, > > right? Even though Grep likewise might return only a few matches. > > IIUC these buffers get filled asynchronously. How should > ‘temp-buffer-resize-mode’ work with such buffers? Resize after every bit of output? Admittedly, it can be annoying. > 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. > > Were the Help windows actually _temporary_ sometime? > > Depends on the semantics of "temporary". I'd only call that a window that usually disappears before the next command. But that's just me. > > 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. > > I thought the other window is where you eventually wanted to show the > target buffer. I don't think that when the user calls any other-window command, they have a specific window in mind (for that, they'd have to know the window numbering somehow). IMHO, -other-window just means "some other window in the current frame". > > 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. > > Once more: Where would you show the target buffer then? 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. > > Instead of having the "split below" performed, and seeing *xref* use > > full width, and only half the height of the current frame. > > Hopefully less than half the height when you fit the window to its > buffer. Like mentioned, xref's contents can be long (even if they usually aren't, in xref-find-definitions output). > >> 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? > > I thought about people who work with one and only one window. We > shouldn't create a no-way-out situation for them. I'm accepting suggestions on what to do in this case. We should handle the more common ones first, however. > 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. > > 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. > > ‘display-buffer’ can't split it. The very first example above will work > only if the user has customized ‘split-height-threshold’. Otherwise, T > will be shown in the O window. Indeed. Anyway, I'd be fine with changing the default, as long as side-by-side splits are still preferred. > > But *Grep* works fine in that situation, doesn't it? > > I never use it. My grep hits appear in a side window where I just list > the files where at least one hit occurred. Selecting a file shows all > hits in that file. Selecting a particular hit shows that hit in the > window on the right. All right, *Compilation*, then? (I'm not too enamored with your description of Grep solution--too many steps--but that's beside the point.) > > 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. > > Did you try it after manually switching to such a buffer? 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? > > I can easily imagine having several *xref* buffers at the same time > > (we'll just have to add more coherent naming). > > Then I'd say: Maybe some prefixed command to "bring back" an existing > *xref* buffer would be more useful than simply switching to it. IMHO, the users won't bother, and will either switch to that buffer manually, or just repeat the search.