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

[Ergus]

On Thu, Apr 07, 2022 at 07:50:28PM +0300, Juri Linkov wrote:
> > > So C-g in the minibuffer could be two-step as well:
> > > first C-g closes the completions window and clears the suffix,
> > > second C-g exits the minibuffer.
> >
> > The most I go into this the most convinced I get that
> > completion-auto-select and selecting the Completions windows is the
> > simplest and cleaner way to go.
>
> Earlier you said that it should work like zsh.  But does zsh
> really select the Completions window?  I see that typing a letter
> while a completion candidate is highlighted in zsh, inserts both
> the highlighted completion candidate and the letter.
> This looks like it never leaves the command line
> that corresponds to the minibuffer in Emacs.
> So why do you think that switching to the Completions window
> is required to select a completion candidate?
Basically because we don't need that exact behavior in all the details
as our use case is a bit different different (and simpler). we use
single commands most if the time. I mean, most of the completion we need
are for single commands/candidates/files because we can't do things
like: "M-x find-file /my/file/path" in a single line. (there are some
exceptions line shell-commands or so... but those are the exception, not
the rule)

But also because emulating that from completions is straight forward
considering that Completions is read-only and any edit attempt (insert a
letter) will emit an error we can handle moving to the minibuffer and
executing there whatever we need.

zsh adds an extra space before the letter so even if it does not leave
the command line completely there is a switch to a state where arrows
navigate, a letter inserts a space and C-g restores to the initial... So
there is a mode and context change.


> > > > Then it should probably be line-move but forward-line goes to column zero.
> > >
> > > Neither of them wraps to the beginning like next-completion does.
> >
> > The wrap behavior is only set for tab and backtab commands (yes, it is
> > hardcoded there... don't blame me) not even for all next-completion
> > uses. I prefer not to touch that code anymore or add more stuff
> > there... At some point we will decide to fix/replace the mouse-face
> > approach there and all this will be a nightmare to support the legacy
> > behavior. >This means we need a new command next-completion-vertical.
> >
> > I already tried that in the first version of zcomplete I did long time
> > ago. And you said (and I agreed) that it was too complicated.
>
> But in zsh <up> and <down> wrap to the top/bottom of the same column.
Yes, I already implemented that and you didn't liked because it was a
bit long ;p... Now this is getting longer and longer....

> Also in zsh TAB moves vertically when columns are sorted vertically.
> Shouldn't TAB in Emacs move vertically too when 'completions-format'
> is 'vertical'?
Actually yes... But implementation will be long and ugly... I don't
think it worth it...

The ideal case may be to have some modes completions-vertical,
completions-horizontal and completions-one-column that will handle all
the pack together (bindings, order, formats)... but may break some of
the external packages. Otherwise we will end with a code full of if-else
and hard to maintain or extend...