bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Juri Linkov <juri@linkov.net>
>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Date: Thu, 06 Apr 2023 13:56:35 -0400
>> 
>> 6. C-h v -path
>> 7. C-a to move point to before -path
>> 8. <tab> to show completions of variables ending in -path
>> 9. Use M-<up> and M-<down> to switch between completions.  Now as you
>> switch completions, they are inserted at point, *without* replacing the
>> text already in the buffer.  So e.g. the minibuffer will contain
>> "load-path-path".
>> 10. Likewise, if you (setq minibuffer-completion-auto-choose nil), M-RET
>> inserts the completion string at point, without replacing the text in
>> the minibuffer, so you will get "load-path-path".
>> 
>> I think this is basically just a bug.
>
> I think it's the intended behavior.  In this case, it looks not
> useful, because the string you typed before starting to use M-<UP> and
> M-<DOWN> happens to be at the end of each completion candidate.  But
> this is not the only situation possible.  Basically, completion always
> modifies only the text before point, leaving what's after point
> intact, so that the user could have after point stuff that completion
> should ignore, and that eventually will be appended to the selected
> candidate.

Could you give an example of when this would be desirable?

>> Hopefully we can fix this before Emacs 29 is released, because this
>> is the last thing which stops these new commands from being a really
>> great improvement to the Emacs completion defaults.
>
> Why did you need to move point to the beginning of what you typed to
> begin with?  Unless you explain that, I don't see how we can consider
> this issue important enough to fix at all, let alone for Emacs 29.
>
>> If this is intentional for some reason, I think the behavior should
>> definitely be changed before Emacs 29 is released.  Moving point around
>> in the minibuffer while completing is an important part of using the
>> default completion-styles
>
> It is? why?

"basic" and "emacs22" are default completion-styles, and they both treat
text after point differently from text before point.

For example, suppose I wanted to wanted to complete filenames starting
with x and ending in .c.  The way I would do this with the default
completion-styles is enter "x.c", placing point just before ".", and hit
TAB.  (I could equivalently do x*.c and hit TAB, but that will move
point to right after the "*" and run into this same issue!)

Actually, * is another good example.  If I input a * in my string to be
completed (which is provided by partial-completion, a default
completion-style), then when I hit TAB point is moved back to the site
of the *.  This makes * very hard to use at the same time as
minibuffer-{previous,next}-completion, because of their behavior of not
modifying the text after point.