unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@linkov.net>
To: Ergus <spacibba@aol.com>
Cc: Philip Kaludercic <philipk@posteo.net>, emacs-devel@gnu.org
Subject: Re: [PATCH] Re: Other details about completion.
Date: Wed, 06 Apr 2022 10:35:36 +0300	[thread overview]
Message-ID: <86a6cyiqlt.fsf@mail.linkov.net> (raw)
In-Reply-To: <20220405232013.5y5jnr4ykzqgxqla@Ergus> (Ergus's message of "Wed,  6 Apr 2022 01:20:13 +0200")

> 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	other threads:[~2022-04-06  7:35 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220401153839.idrzrbfl2yfzga3y.ref@Ergus>
2022-04-01 15:38 ` Other details about completion Ergus
2022-04-01 16:21   ` Eli Zaretskii
2022-04-01 16:43   ` Juri Linkov
2022-04-01 16:45     ` Ergus
2022-04-01 20:24     ` [PATCH] " Ergus
2022-04-02 18:09       ` Juri Linkov
2022-04-03  0:39         ` Ergus
2022-04-04 19:35       ` Ergus
2022-04-04 19:45         ` Juri Linkov
2022-04-04 20:31           ` Philip Kaludercic
2022-04-05 11:06             ` Ergus
2022-04-04 22:33           ` Ergus
2022-04-05 19:22             ` Juri Linkov
2022-04-05 23:20               ` Ergus
2022-04-06  7:35                 ` Juri Linkov [this message]
2022-04-06 13:21                   ` Ergus
2022-04-06 16:48                     ` Juri Linkov
2022-04-06 17:45                       ` [External] : " Drew Adams
2022-04-06 18:25                         ` Juri Linkov
2022-04-06 20:01                           ` Drew Adams
2022-04-06 17:45                       ` Ergus
2022-04-06 18:29                         ` Juri Linkov
2022-04-06 19:50                           ` Ergus
2022-04-07  7:35                             ` Juri Linkov
2022-04-07  9:16                               ` Ergus
2022-04-07 16:53                                 ` Juri Linkov
2022-04-07 17:38                                   ` Ergus
2022-04-07 18:04                                     ` Juri Linkov
2022-04-07 18:35                                       ` Ergus
2022-04-08  7:40                                         ` Juri Linkov
2022-04-08  8:42                                           ` Ergus
2022-04-08 16:20                                             ` [External] : " Drew Adams
2022-04-08 16:46                                             ` Juri Linkov
2022-04-08  9:31                                           ` Philip Kaludercic
2022-04-08 16:20                                             ` [External] : " Drew Adams
2022-04-08 16:51                                             ` Juri Linkov
2022-04-08 20:12                                               ` Philip Kaludercic
2022-04-06 23:55                           ` Ergus
2022-04-06 18:13                       ` Ergus
2022-04-06 18:34                         ` Juri Linkov
2022-04-06 20:34                           ` Ergus
2022-04-07  7:39                             ` Juri Linkov
2022-04-07  9:08                               ` Ergus
2022-04-07 16:50                                 ` Juri Linkov
2022-04-07 17:22                                   ` Ergus
2022-04-07 17:57                                     ` Juri Linkov
2022-04-07 18:27                                       ` Ergus
2022-04-08  7:45                                         ` Juri Linkov
2022-04-08  8:46                                           ` Ergus
2022-04-08 16:20                                             ` [External] : " Drew Adams
2022-04-08 16:53                                             ` Juri Linkov
2022-04-06  9:07                 ` Lars Ingebrigtsen
2022-04-06 16:43                   ` Juri Linkov
2022-04-07 11:09                     ` Lars Ingebrigtsen
2022-04-07 16:46                       ` Juri Linkov
2022-04-08 12:59                         ` Lars Ingebrigtsen

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=86a6cyiqlt.fsf@mail.linkov.net \
    --to=juri@linkov.net \
    --cc=emacs-devel@gnu.org \
    --cc=philipk@posteo.net \
    --cc=spacibba@aol.com \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).