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: Wed, 09 Jan 2019 11:04:08 +0100 Message-ID: <5C35C718.6000706@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> <5C346C49.6060003@gmx.at> <8736q2ka0h.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: 7bit X-Trace: blaine.gmane.org 1547028187 12506 195.159.176.226 (9 Jan 2019 10:03:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 9 Jan 2019 10:03:07 +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 Wed Jan 09 11:03:02 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 1ghAhR-00037R-QW for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Jan 2019 11:03:02 +0100 Original-Received: from localhost ([127.0.0.1]:39920 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ghAjY-0001vS-Lk for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Jan 2019 05:05:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ghAjS-0001vN-7p for bug-gnu-emacs@gnu.org; Wed, 09 Jan 2019 05:05:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ghAjO-00076g-DR for bug-gnu-emacs@gnu.org; Wed, 09 Jan 2019 05:05:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51547) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ghAjN-00076H-Sn for bug-gnu-emacs@gnu.org; Wed, 09 Jan 2019 05:05:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ghAjN-0006sP-Mc for bug-gnu-emacs@gnu.org; Wed, 09 Jan 2019 05:05: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: Wed, 09 Jan 2019 10:05: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.154702826826391 (code B ref 33870); Wed, 09 Jan 2019 10:05:01 +0000 Original-Received: (at 33870) by debbugs.gnu.org; 9 Jan 2019 10:04:28 +0000 Original-Received: from localhost ([127.0.0.1]:50828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ghAiq-0006ra-0h for submit@debbugs.gnu.org; Wed, 09 Jan 2019 05:04:28 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:45547) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ghAio-0006rM-KF for 33870@debbugs.gnu.org; Wed, 09 Jan 2019 05:04:27 -0500 Original-Received: from [192.168.1.101] ([46.125.250.87]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MP1PX-1gbxOY3ErX-006RAK; Wed, 09 Jan 2019 11:04:17 +0100 In-Reply-To: <8736q2ka0h.fsf@mail.linkov.net> X-Provags-ID: V03:K1:whkCNyE2im23edN51KoPREoXtLga7lHwDo1q+8zZdLRvGWwK6ZT KLnWAeAwh8GljsQMTHZL8NdtQ++ubd/UTbq/vaIuuutDnp8bHd4oqvrYFAXhl27pKUAzMtZ g/YjevUHnFzy8IkkS29vaU9dkcQ1uSS6BT8rN6K2rvF6tu+N8ft2ftFcQURjdcCL6fgZQJF QoP5Px0a3tisVMBtv+UKw== X-UI-Out-Filterresults: notjunk:1;V03:K0:ItY4YlgsLxc=:nByuGq1iSyqhucI7JHepm2 WAyjf323RY2uwdGtmYPHVHkZMhXxhd3chTlXwWwKUDbB5Z6RPX7xHi0Nsahex0YkOiXwL5BVo zPr8XgXbQWK/My3T941eyT1m7FzVfvWEoXLN602k/w5oggAniLNzkpx3XeCb5QXNGUzrKa2Um 7+7TMYBxTsYjHcNpnB1ZNy0NHy/l5xuuC+48SRRoZORV4Y2sgRYM4Ivht2rV7rYwsunLyO4N5 NVXFZvs0yi5PfvRUoGEIugZiKmwG4y9Qw02OfnWg9JACe0FADzvk6iN2resibkqhbNvt5FakQ pQf+x52RK4rk8f4DYj3HeZ8NxsNu+78ofKbDkLAHfy9ojLfLV3lvd6rBbvMM3A9c0cGNeHLVw Zkl+x2QMLMdMxiidd+bwBp2mb9hs1DnfceXPJuU9INYlHK4FQCwVsFZsCUoYLkPm9+PHWixTP Btu6Bwwqa7IHY20q27bXX7rYdCFm/uotoRK61xGHzQgelbeMVpYdVJbFEeznN8Fu7J5NynW5e I3xZVWtdiGfZloXS5jQ997Mq0g/KvSvWiUabCQzSqF5mLI5UjjTYw3NfhLfmMs31x74IbgWHn 3/qDfgzntWE18+ZJA7QcYoESIs/Bh1GlyLpIJIN4UGmm80wukMh9zoS7/+CWrDX19Uy2OWmRw eV1bVXcPpLV5LAv7OTnEmoT9Oc6kXBqU/E6mWwHexSyY7dnygU87R/8SHUMVXPKh/5YG3nDKw /Tv4+AiWANEXa5zP7cjlptFb+vYvv2L+pMWRCj2+BVezbFx3zaoWe2Gs0L3aGQD6RWpoOFBe 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:154286 Archived-At: >>> 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? > > I meant to make it shorter in any possible way, so using something like > '(window-height . resize)' seems to achieve this goal. 'resize' is too short IMHO. 'resize-to-fit' maybe. > Exactly. There is a long list of actions in display-buffer--maybe-at-bottom > before calling the main action 'display-buffer-at-bottom', so it makes sense > to move them somewhere to a common place. But running a "fallback" action before the others doesn't sound very intuitive. >> I now always display completions in a child frame so I never run into >> practical problems with it. > > Then what problems are possible with binding 'split-width-threshold' > or 'split-height-threshold' to nil? I can't tell because I'm not sure what we want here. And if you say that with your setup this part is never executed, things get even more obscure. So let's leave everything as it is until someone files a "real" complaint. >> 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? > > This makes sense. Even more, maybe it would be possible to use only > an alist '(side . bottom)' instead of specyfying the action > 'display-buffer--maybe-at-bottom'? We could use the six abbreviations we have ('left', 'top', 'above', 'right', 'bottom' and 'below') to make a window on the respective side either of the selected window or the frame. Then we would need one action function say 'display-buffer-beside' and yet another action alist entry say 'beside' with the values 'selected' (on any side of the selected window), 'main' (on any side of the main window) and a window (on which side this would have to be created). martin