[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave
From: |
Eli Zaretskii |
Subject: |
bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer |
Date: |
Thu, 06 Apr 2023 22:30:55 +0300 |
> 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.
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Spencer Baugh, 2023/04/06
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Juri Linkov, 2023/04/06
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Spencer Baugh, 2023/04/06
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Juri Linkov, 2023/04/07
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, sbaugh, 2023/04/07
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Eli Zaretskii, 2023/04/08
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, sbaugh, 2023/04/08
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Eli Zaretskii, 2023/04/08
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Juri Linkov, 2023/04/08
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Eli Zaretskii, 2023/04/08