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

[Eli Zaretskii <eliz@gnu.org>]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: 62700@debbugs.gnu.org,  juri@linkov.net
> Date: Thu, 06 Apr 2023 14:58:42 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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?

When completing on shell commands, for example: the text after point
is usually the command-line arguments to the command, and the
completion is on command names or on some file name.

> >> 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.

This is intentional, AFAIK.

> For example, suppose I wanted to wanted to complete filenames starting
> with x and ending in .c.

I don't think the default completion supports such functionality, at
least not with the styles we have by default in completion-styles.

But maybe I'm missing something; adding Stefan to the discussion.