emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Re: Other details about completion.


From: Juri Linkov
Subject: Re: [PATCH] Re: Other details about completion.
Date: Wed, 06 Apr 2022 10:35:36 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu)

> Thanks for this... Sadly after trying it for a while I find it very
> uncomfortable. :( maybe we can do something to improve it please??

This is not surprising.  This explains why we still had no such feature
for a long time.  It's because there are too many different expectations
how it should work.  But maybe it would be possible to find a set of
customizable options that will cover most use cases.  As least we could try.

> 1) I think it is more intuitive to invert and use the M-S-<arrow>
> minibuffer-choose-** and M-<arrow> for
> minibuffer-{previous|next}-completion for not insert commands...

Easier to type M-<arrow> were intended as the primary way to use this feature.
Whereas more hard to type M-S-<arrow>/M-RET as a rarely used alternative.

> Alternatively (IMHO much better one):
>
> Maybe you could consider to insert the candidate, but keep the cursor in
> the same place and add a shadowed suffix after the cursor in the
> minibuffer.  So M-<arrow> navigates, and inserts suffix but if the user
> types a letter the suffix disappears and the letter is inserted in the
> right place. In contrast if the user press RET, as the candidate is
> already inserted the current behavior is unchanged.

Isn't this behavior too confusing?  When the suffix is shadowed,
do you think the user will have the clear idea what will happen
after typing RET?  How will it indicate that typing
a self-inserting character will delete the suffix?
Maybe better to activate the region over the suffix?
Then it will follow rules of delete-selection where
a self-inserting character is expected to remove the suffix region.

> 2) The M-<up>/M-<down> is not intuitive when completions are not in
> one-column format,

M-<up>/M-<down> could be rebound to call next-line in the
completions buffer.

> and the M-<left>/M-<right> cannot be used because
> they are already taken.. Do we have any other alternative?

Indeed, horizontal navigation is a problem since M-<left>/M-<right>
can't be used by default, only after enabling a new option.

> I think there is a problem any way because 2d navigation with this
> is impossible...

Why 2d navigation is impossible?  It's possible in the completions
buffer where <right> is next-completion, and <down> is next-line.

> 3) I think that the bindings in the minibuffer must be enabled in the
> completions buffer as well, otherwise it becomes unconfortable;
> specially with completion-auto-select.

Agreed, M-<up>/M-<down> can be bound in the completions buffer.
But what about M-<left>/M-<right> for not one-column format?

>>I noticed that your patch broke some corner cases:
>>when using minibuffer completion navigation commands,
>>it fails to go to the previous completion at the top.
>>But since this is now in master, you can see it yourself.
>
> My patch can only affect the TAB and backtab commands (look at the if
> condition)... So I don't see how it could affect you commands ;(... I
> will give it a look tomorrow...

Sorry, now I can't reproduce the previous problem, it seems to work fine,
except the problem reported in bug#54374.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]