all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ergus <spacibba@aol.com>
To: Philip Kaludercic <philipk@posteo.net>
Cc: Protesilaos Stavrou <info@protesilaos.com>, emacs-devel@gnu.org
Subject: Re: [PATCH] completions-max-height
Date: Tue, 8 Mar 2022 11:32:27 +0100	[thread overview]
Message-ID: <20220308103227.olrz7dvajgieyeep@Ergus> (raw)
In-Reply-To: <878rtk3k6m.fsf@posteo.net>

On Tue, Mar 08, 2022 at 08:47:13AM +0000, Philip Kaludercic wrote:
>Ergus <spacibba@aol.com> writes:
>
>> I understand your intention, but in practice making this more complex
>> is useless. The mini buffer is always down and making the completions
>> to move somewhere else is uncomfortable and may require more
>> lisp/emacs knowledge to change the default behavior from the
>> user. Which is completely the opposite to my intention. Actually this
>> same result may be reached with an advise as I discussed on yesterday
>> on emacs help. But a simple custom is better.
>>
>> I am totally fine if you propose something else more general if that don't forces the user to write a function to change a simple height.
>
>What I proposed would just require something like
>
>    (setq completion-display-buffer-option '(display-buffer-at-bottom (window-height . 10)))
>
I got the point but if you look at the original code there are
conditions that will need to be set to not change the current default
behavior (because that always ends in arguments from long time users
that want some specific detail of the previous behavior), for example:
temp-buffer-resize-mode or (eq (selected-window) (minibuffer-window)).

We can go around them, but it may be a more complex patch I am not
willing to do because I don't see the utility of a completions window in
any other place than where it goes now (next to the minibuffer).

In a best case the new variable will need to be something like:
`completion-display-from-minibuffer-options` and parse them with some
if-else here and there to apply the position only when (eq
(selected-window) (minibuffer-window)) but provide a default value in
case the user didn't specify it and the height only when not
temp-buffer-resize-mode (or condition it as the new function does).



>> On March 8, 2022 6:13:13 AM GMT+01:00, Protesilaos Stavrou <info@protesilaos.com> wrote:
>>>On 2022-03-07, 22:10 +0000, Philip Kaludercic <philipk@posteo.net> wrote:
>>>
>>>> Ergus <spacibba@aol.com> writes:
>>>>
>>>>> Hi:
>>>>>
>>>>> Do you think that this may be added to vanilla?
>>>>
>>>> IMO it would be better if this could be generalised to something like
>>>> completion-display-buffer-action, so that you can decide where and how
>>>> the completion buffer is displayed.  Though I am uncertain if this might
>>>> have unintended side effects, as the behaviour seems to have been
>>>> hard-coded for a while.
>>>
>>>I agree with Philip.  Or go a step further and just let the Completions
>>>behave like other buffers so the user can contol its placement and
>>>parameters via the display-buffer-alist.
>
>You can do so now too, but I don't think that that would be an argument
>to just have the completion buffer behave like other buffers,
>considering that there are certainly many who are used to its current
>behaviour.
>
>>>--
>>>Protesilaos Stavrou
>>>https://protesilaos.com
>>>
>
>-- 
>	Philip Kaludercic
>



  reply	other threads:[~2022-03-08 10:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220307210740.veiocemir46mmerk.ref@Ergus>
2022-03-07 21:07 ` [PATCH] completions-max-height Ergus
2022-03-07 22:10   ` Philip Kaludercic
2022-03-08  5:13     ` Protesilaos Stavrou
2022-03-08  8:05       ` Ergus
2022-03-08  8:47         ` Philip Kaludercic
2022-03-08 10:32           ` Ergus [this message]
2022-03-08 13:29           ` Ergus
2022-03-09 11:34             ` Ergus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220308103227.olrz7dvajgieyeep@Ergus \
    --to=spacibba@aol.com \
    --cc=emacs-devel@gnu.org \
    --cc=info@protesilaos.com \
    --cc=philipk@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.