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: Sun, 24 Jan 2016 19:12:31 +0100 Message-ID: <56A5140F.2040905@gmx.at> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1453659196 15212 80.91.229.3 (24 Jan 2016 18:13:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Jan 2016 18:13:16 +0000 (UTC) Cc: Helmut Eller , emacs-devel@gnu.org To: Dmitry Gutov , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 24 19:13:07 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 1aNP9u-0004FJ-Q6 for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 19:13:07 +0100 Original-Received: from localhost ([::1]:33020 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNP9t-00014Y-IZ for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 13:13:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNP9e-00014Q-Mg for emacs-devel@gnu.org; Sun, 24 Jan 2016 13:12:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNP9d-00056B-JV for emacs-devel@gnu.org; Sun, 24 Jan 2016 13:12:50 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:64350) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNP9V-00055P-VQ; Sun, 24 Jan 2016 13:12:42 -0500 Original-Received: from [192.168.1.100] ([212.95.7.84]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MGB7j-1aICEB0Izf-00FAFs; Sun, 24 Jan 2016 19:12:40 +0100 In-Reply-To: <56A50514.9040509@yandex.ru> X-Provags-ID: V03:K0:38KF7lbTnbWsKqw3gRnfft/e3TpwhcqpiRA7NcvTVgRRPZClz7V 0pAmKQB9NMkKS4EdHn/q10kU0ksD1T6AWAeYWY2U6zk+9cSqtWl1xiWZkRIF3SDT9uvB/0M HqFSmlX05b2qYvcqDfu0R9ArEZ+b0EnSVot4w35v3NLcytbFLAgFbhVAnl7i5/mZXubUfC0 A7b4qvRHFBr+pQr+JwCow== X-UI-Out-Filterresults: notjunk:1;V01:K0:DrHMY+WdoQI=:5D8H0bgo8OI+MjM00S7xQm one3OBJ7t4gSnC80i8KaUwOZqncfLsW06GeXZl96At3kBnvce9FhHjhxBhOdDYkbJzwPLpqF/ 17tNjLAUuK4cAJ9wDnRokiXfuTCI7WxlZXwrTDGWF4PpoyxB7FFofoswdbS4TY4USQIuKh0mR MGFHjzjb8ZpLJ4ajn04BNlSXbcV/GFSMor3qnRAyDsdvBDTO02wSQO+MQJvqwfGPfG25DwX6C 7kutr9rB8KaqO6CgBBExUdXEiKmnwjNil+NoI1vLQMatBnNI5MjA4ZiXpUFVFkMSjZqIc0kkw Le4YEO6nW8gmKFjUTutiqjpTYbNPa5aDwUYfjb6uUnT70gUN2s+Hx80+qCh4OGZP/zEAqliIp IDFyZzq33O5UPi6RjzPQxylvXy8RBOyZw4QHpUO4ZBjUtbe3VDRUEDZhsbvSabE+DhwYrA+lq zFGOJR9VOh1cfgK205kBldsr4SBs0NFeeFCJmr3PR+bmGa1FsoeVFG1pDQBg1dABmt+L0okXo PxB4Hv5dmbOXXhNC9nVGA3bxuKwWsFPicPgWhB9F0XNhyx+TRytmx+nkYEzHdI+WfkCrBtUPM GQUZyB/OmGX0QeufUXB2GdOsYez1CMaxl4RafR/SNV8YrXspUgmCTYPWvMdWFaZuTrCmxSKlX b4TRRZRPXmf8/myh+0n8Ohc8M2t8+RYczWIusjfX8bhWasxBfaMQiZ+ilipK+PYFc4lwvdnFj mcMBNCiwc23Dylxrp5M4wdvRAtbsOyYCcmAAQOMBn3DHSF1fT8rJazkmUNDhjQDRz6xkyw5u X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.21 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:198716 Archived-At: > 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. Because of "Do not make that buffer current for running the forms in BODY." You have to use =91with-current-buffer=92 around the =91insert=92= =2E > 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. And I'd like to see it always at the same frame position. > 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. But here usually the *xref* buffer never occupies its full _height_. That's where =91temp-buffer-resize-mode=92 would come in handy. > 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. Help windows are also displayed via =91with-temp-buffer-window=92 and don't disappear soon. Some people keep= the help window open all the time. The IMHO important aspect is that *Completions* uses =91display-buffer-at-bottom=92 which calls plain =91split-window=92 and thus is not limited by =91split-height-threshold=92= =2E You can obviously use =91display-buffer-at-bottom=92 with plain =91display-bu= ffer=92 as well. But then =91temp-buffer-resize-mode=92 won't get called. > 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. That's my understanding as well. > 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). But even softly (that's all you need here) dedicated windows sometimes behave erratically. > 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 ;-) >> I asked a couple of times whether this makes any sense but nobody car= ed. > > 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. A threshold that is more than twice as large as the default value? >> Why would she want to do that if you keep *xref* visible as long as i= t's >> needed? If the *xref* window is gone, the user should never switch t= o >> *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. > 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 =91quit-window=92 there is not likely producing good results. The same w= ill hold for =91q=92 in a window where you manually switched to *xref*. Mayb= e some command to "bring back" the *xref* buffer would be more useful than simply switching to it. martin