From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#33870: 27.0.50; xref-goto-xref not configurable Date: Tue, 08 Jan 2019 10:24:25 +0100 Message-ID: <5C346C49.6060003@gmx.at> References: <87a7ktqqx7.fsf@mail.linkov.net> <9215183d-0a44-88b5-5b3c-d0da31f749ad@yandex.ru> <878t02egph.fsf@mail.linkov.net> <878t011lch.fsf@mail.linkov.net> <83lg403o9c.fsf@gnu.org> <87r2dq8z9n.fsf@mail.linkov.net> <5C31C477.9040108@gmx.at> <874laluz3g.fsf@mail.linkov.net> <5C3315E6.9010709@gmx.at> <87wongazxq.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1546939386 24809 195.159.176.226 (8 Jan 2019 09:23:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 8 Jan 2019 09:23:06 +0000 (UTC) Cc: 33870@debbugs.gnu.org, joaotavora@gmail.com, dgutov@yandex.ru To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 08 10:23:01 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ggnbA-0006Kl-ET for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Jan 2019 10:23:00 +0100 Original-Received: from localhost ([127.0.0.1]:55244 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ggndH-00057K-AX for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Jan 2019 04:25:11 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47929) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ggndA-000571-Ig for bug-gnu-emacs@gnu.org; Tue, 08 Jan 2019 04:25:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ggnd8-0002wy-6E for bug-gnu-emacs@gnu.org; Tue, 08 Jan 2019 04:25:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49960) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ggnd8-0002wk-2l for bug-gnu-emacs@gnu.org; Tue, 08 Jan 2019 04:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ggnd7-0002CH-Oh for bug-gnu-emacs@gnu.org; Tue, 08 Jan 2019 04:25:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Jan 2019 09:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33870 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33870-submit@debbugs.gnu.org id=B33870.15469394848417 (code B ref 33870); Tue, 08 Jan 2019 09:25:01 +0000 Original-Received: (at 33870) by debbugs.gnu.org; 8 Jan 2019 09:24:44 +0000 Original-Received: from localhost ([127.0.0.1]:49241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ggncp-0002Bh-Sa for submit@debbugs.gnu.org; Tue, 08 Jan 2019 04:24:44 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:60839) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ggncn-0002BT-DL for 33870@debbugs.gnu.org; Tue, 08 Jan 2019 04:24:41 -0500 Original-Received: from [192.168.1.101] ([212.95.5.97]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LqALY-1hBkj92RHM-00dmXB; Tue, 08 Jan 2019 10:24:31 +0100 In-Reply-To: <87wongazxq.fsf@mail.linkov.net> X-Provags-ID: V03:K1:gO11kgxS2DLco/QdPhTxJH7qBm1GSNsmSjxX6TB/2DLyohRbuSr 17i7S1/cAKtyKAkMyzSgP56RnV1qbzim92vEDoqWxT/u5klbO6539DyIC3/OXSUW8IMQGcE AiqJGvPe1qMPSMZzEJQALfjwjh6Sse2EESBxDJNj7DBgWlihnxs7lIUR7KSawPZKGE9pRhH 9a7OEGBSFJzIUVsjaPYJQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:poPigmr3ANo=:VldSY+Bw48UUjPe/NREZhv JEXuCZ8m9MhxKWTLyXx3z7cShqCicm7snGRuYKVDVub00Ix32VfsW1iQagkgblJQ9CDSg6GUY Gf8bIM4rEVTvLZMef+xa8N0FvBzVHMTThL0/t+g+io3xYhPbN5fzBJwY1Qr3JmVd0ZQiUTqhj xTsoOXiqM6nq5FIRFpRbZ123BhyXM1g+I7d1v1EIRmjYohBY3FU/OMprgBJBeetlZIOSp2zXO IyZ/FK0YVb+5NGyRDVsi8CAOjVoKoKPRz76wKVJNxP/CBZy88siGjgkehzU9QB8niPg7uk7Be 27DMdj/vnZftyZEbrssJkmZ1s769gWnqLAzLQNky+NqfHt9ZaiRL4l/nrbhPaG61XTVB/fCsv m0Xu38KIFTZhbg/A3cEJ6vWpt36msEeFSWW9pRfQDbPptrcwrSBjfZxts1izUxCXi95RygX1z ImD0gJ/2V1w4tWIrhNVLx3R/Wk3uPUnBRiEZn1hWXI5nkF2JFVLdTgqWl4OMKq4LGf6D0e1On eigWAn/0TtdAkfeXSoLNicBk5t6CvkhHgxO59nBnxrBlnHW+KVeAuzqUgnhHmB+yRO3CqRyKV 5yZ/pHnOlR9htSe8LmAQmD9A0Oj00x53FO5aLSJqsUH4RtMLc+t8D20WvAFgOKqIY3/TMrzGU yoFtHD3Mkgey8AKyioEopfiEjvqepYp+ATzwxEIzgt3ABQinEQSQMz8nyDqDe6eSWPb3QS3vI iizZQ4o4CkTqnWgegRKjbsOSPnp9Zhh0bgnosJukt28E4nC8FoVtSHJXsHhbP/eRJOyw9qvz X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:154250 Archived-At: > I understand that the word =E2=80=9Cmaybe=E2=80=9D indicates it's not = guaranteed that > the function will do what it's intended to do. IOW, these functions > are conditional. Like 'display-buffer'. But we don't call it 'display-buffer-maybe'. > Since we can't lightly rename old functions, I have a question only > about functions added in Emacs 27, namely, display-buffer--maybe-at-bo= ttom. > Its current body: > > (let ((alist (append alist `(,(if temp-buffer-resize-mode > '(window-height . resize-temp-buffer-window) > '(window-height . fit-window-to-buffer)) > ,(when temp-buffer-resize-mode > '(preserve-size . (nil . t))))))) > (or (display-buffer--maybe-same-window buffer alist) > (display-buffer-reuse-window buffer alist) > (display-buffer--maybe-pop-up-frame buffer alist) > (display-buffer-in-previous-window buffer alist) > (display-buffer-at-bottom buffer alist))) > > I propose to remove this function and replace its parts with > more alists, i.e. this blob > > `(,(if temp-buffer-resize-mode > '(window-height . resize-temp-buffer-window) > '(window-height . fit-window-to-buffer)) > ,(when temp-buffer-resize-mode > '(preserve-size . (nil . t)))) > > with something shorter like `(fit-to-buffer . t)' Can't we add this via a special value for the 'window-height' alist entry? Where we explicitly state that it obeys 'temp-buffer-resize-mode' if that is active and the buffer qualifies as temporary and so on ... Or is that what you mean already? > And also to replace a long list of display-buffer-* that is a copy of > `display-buffer-fallback-action' with something shorter like an alist > `(pre-action . display-buffer-fallback-action). I'm not sure I understand you. 'display-buffer-fallback-action' is always tried after everything else failed. Would you want to run it _before_ something else? >> A single window frame where the buffer is not displayed runs this >> part. > > You are lucky if you can invoke its second branch. I always get only > its third branch in all tried configurations when testing with > completions of `C-x C-f TAB TAB'. I now always display completions in a child frame so I never run into practical problems with it. > After resizing an initial frame to 12 lines, so every vertically split= > window gets 6 lines, typing `C-x C-f TAB TAB' displays *Completions* i= n > the upper window, when a previous window where *Completions* was > previously displayed was moved to the upper window, e.g. > > 0. emacs -Q > 1. resize the frame to 12 lines > 2. C-x 2 > 3. C-x C-f TAB TAB C-g ;; *Completions* were displayed in the bottom= window > 4. C-x 0 > 5. C-x 2 > 6. C-x C-f TAB TAB C-g ;; *Completions* displayed in the upper window= that was previous Your bag of tricks is fathomless :-) Basically, this means that 'display-buffer-in-previous-window' and 'display-buffer-at-bottom' are inherently irreconcilable when a window was at bottom once and moved upwards. We could abuse the existing 'side' action alist entry for not-atomic, non-side windows in the following sense: If 'side' equals 'bottom', a window is eligible for reuse if and only if it appears on that side of the frame. To be obeyed by 'display-buffer-reuse-window' and 'display-buffer-in-previous-window', I presume. WDYT? martin