vertical fido-mode

vertical fido-mode

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

Hi Joao.
The last 2 days I have been wondering if it will be too complex (or potentially error prone) to customize fido to show the candidates vertically (like in ivy).

In ido mode it was more or less easy to do just changing the separator, but that created so many issues that multiple packages were created to "fix" them. I could be interested in this feature ONLY if it doesn't add too much complexity to fido-mode.
Just now I tried:

(fido-mode t)

(setq icomplete-separator "\n"         icomplete-hide-common-prefix nil         icomplete-in-buffer t)

So far it seems to be working with some expected tiny issues no so complex to fix:

1) An extra '{' and missing new line (see picture) that overlaps the cursor and in vertical mode is confusing. (There is not separator between the cursor and the list of candidates)
2) The arrows could need to change bindings as in vertical mode <up> and <down> should do what <left> and <right> are doing now.
3) Maybe TAB should complete the current candidate in place (the first candidate or the common part of all candidates), in any case not open the *Completions* buffer? Because the completion candidates are already there (this is in general for fido mode), it will be more familiar for Bash users for example.

Best,Ergus

[-- Attachment #2: Type: text/html, Size: 2583 bytes --]

Re: vertical fido-mode

[Stefan Monnier]

BTW,

I think the icomplete-vertical functionality could/should be supported
directly by complete.el.


        Stefan


Ergus [2020-06-10 16:27:18] wrote:

> Hi Joao.
> The last 2 days I have been wondering if it will be too complex (or
> potentially error prone) to customize fido to show the candidates vertically
> (like in ivy).
>
> In ido mode it was more or less easy to do just changing the separator, but
> that created so many issues that multiple packages were created to "fix"
> them. I could be interested in this feature ONLY if it doesn't add too much
> complexity to fido-mode.
> Just now I tried:
>
> (fido-mode t)
>
> (setq icomplete-separator "\n"         icomplete-hide-common-prefix nil     
>    icomplete-in-buffer t)
>
> So far it seems to be working with some expected tiny issues no so complex to fix:
>
> 1) An extra '{' and missing new line (see picture) that overlaps the cursor
> and in vertical mode is confusing. (There is not separator between the
> cursor and the list of candidates)
> 2) The arrows could need to change bindings as in vertical mode <up> and
> <down> should do what <left> and <right> are doing now.
> 3) Maybe TAB should complete the current candidate in place (the first
> candidate or the common part of all candidates), in any case not open the
> *Completions* buffer? Because the completion candidates are already there
> (this is in general for fido mode), it will be more familiar for Bash users
> for example.
>
> Best,Ergus

Re: vertical fido-mode

[Dmitry Gutov]

On 10.06.2020 19:53, Stefan Monnier wrote:
> I think the icomplete-vertical functionality could/should be supported
> directly by complete.el.

Someone could contact the author of 
https://github.com/oantolin/icomplete-vertical for copyright assignment 
(and either incorporate the mode, or just some parts of it), in order 
not to have to solve the same problems all over again.

Re: vertical fido-mode

[Basil L. Contovounesios]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 10.06.2020 19:53, Stefan Monnier wrote:
>> I think the icomplete-vertical functionality could/should be supported
>> directly by complete.el.
>
> Someone could contact the author of
> https://github.com/oantolin/icomplete-vertical for copyright assignment 
> (and either incorporate the mode, or just some parts of it), in order not to
> have to solve the same problems all over again.

Done, but note that icomplete-vertical modifies icomplete to achieve
this goal, whereas I think Stefan is talking about making vertically
listed completions in the minibuffer more of a first class citizen.

-- 
Basil

Re: vertical fido-mode

[Basil L. Contovounesios]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think the icomplete-vertical functionality could/should be supported
> directly by complete.el.

+1.

-- 
Basil

Re: vertical fido-mode

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

Yes, that's a good.idea. 
But as I see the code in icomplete-vertical-mode; it relies in a hook (icomplete-vertical-minibuffer-setup) and an advice (icomplete-vertical-format-completions) which in principle we don't need with a very simple modification of icomplete-completions and icomplete-minibuffer-setup. If icomplete-completions produces the formated output it will be more efficient and clean than adding an advice or do a reformat.

There are also some customizable options that for a simple working vertical mode we shouldn't need (like icomplete-vertical-separator-alist or a face icomplete-vertical-separator) unless we want to add them now.
So in my opinion maybe we can provide the vertical mode in a simpler way just improving icomplete-completions and some other small changes here and there. WDYT?
-----Original Message-----
From: Dmitry Gutov <dgutov@yandex.ru>
To: Stefan Monnier <monnier@iro.umontreal.ca>; Ergus <spacibba@aol.com>
Cc: emacs-devel@gnu.org <emacs-devel@gnu.org>
Sent: Wed, Jun 10, 2020 9:01 pm
Subject: Re: vertical fido-mode

On 10.06.2020 19:53, Stefan Monnier wrote:
> I think the icomplete-vertical functionality could/should be supported
> directly by complete.el.

Someone could contact the author of 
https://github.com/oantolin/icomplete-vertical for copyright assignment 
(and either incorporate the mode, or just some parts of it), in order 
not to have to solve the same problems all over again.


[-- Attachment #2: Type: text/html, Size: 2370 bytes --]

Re: vertical fido-mode

[Dmitry Gutov]

On 11.06.2020 00:54, Ergus wrote:
> So in my opinion maybe we can provide the vertical mode in a simpler way 
> just improving icomplete-completions and some other small changes here 
> and there. WDYT?

It could also add a different way to "select" a previous or next 
completion: instead of rotating the list, move the highlight (and some 
fringe indicator, maybe).

I'm not sure of the extra complexity that would bring, though.

Re: vertical fido-mode

[Juri Linkov]

>> So in my opinion maybe we can provide the vertical mode in a simpler way
>> just improving icomplete-completions and some other small changes here 
>> and there. WDYT?
>
> It could also add a different way to "select" a previous or next
> completion: instead of rotating the list, move the highlight (and some 
> fringe indicator, maybe).

Or show vertical completions in the *Completions* buffer and use the
current icomplete keys to navigate the *Completions* list from the minibuffer.

Re: vertical fido-mode

[Dmitry Gutov]

On 11.06.2020 02:08, Juri Linkov wrote:
> Or show vertical completions in the*Completions*  buffer and use the
> current icomplete keys to navigate the*Completions*  list from the minibuffer.

I could be wrong (not having seen the result), but IMHO that's not what 
the majority of icomplete-vertical users are expecting. They/us expect 
something more like Ivy.

Re: vertical fido-mode

[Omar Antolín Camarena]

Hi! I'm the author of icomplete-vertical. I'd be very happy to see the icomplete-vertical functionality included in Emacs, and Ergus is completely correct:

> But as I see the code in icomplete-vertical-mode; it relies in a hook (icomplete-vertical-minibuffer-setup) and an advice (icomplete-vertical-format-completions) which in principle we don't need with a very simple modification of icomplete-completions and icomplete-minibuffer-setup. If icomplete-completions produces the formated output it will be more efficient and clean than adding an advice or do a reformat.

That's exactly what should be done: not include the icomplete-vertical package as is, but instead make small modifications of the existing icomplete package to incorporate the changes.

> There are also some customizable options that for a simple working vertical mode we shouldn't need (like icomplete-vertical-separator-alist or a face icomplete-vertical-separator) unless we want to add them now.

Again, Ergus is completely right! Those, with the benefit of hindsight, are over-engineered and shouldn't be included in Emacs. Heck, they shouldn't even be in icomplete-vertical. (I've learned that lesson and although I subsequently wrote a few more completion UIs, I didn't include options analogous to those.)

-- 
Omar Antolín Camarena

Re: vertical fido-mode

[Ergus]

Hi Omar!

Good to know that you agree with the needed changes as I proposed
them. Are you willing to implement them? If so, do you have a copyright
assignment?

I am available to help you with anything you need (I am not a good
lisper any way). But I am really interested into see this functionality
in vanilla for fido-mode.

Best,
Ergus

On Wed, Jun 10, 2020 at 07:55:09PM -0500, Omar Antol�n Camarena wrote:
>Hi! I'm the author of icomplete-vertical. I'd be very happy to see the icomplete-vertical functionality included in Emacs, and Ergus is completely correct:
>
>> But as I see the code in icomplete-vertical-mode; it relies in a hook (icomplete-vertical-minibuffer-setup) and an advice (icomplete-vertical-format-completions) which in principle we don't need with a very simple modification of icomplete-completions and icomplete-minibuffer-setup. If icomplete-completions produces the formated output it will be more efficient and clean than adding an advice or do a reformat.
>
>That's exactly what should be done: not include the icomplete-vertical package as is, but instead make small modifications of the existing icomplete package to incorporate the changes.
>
>> There are also some customizable options that for a simple working vertical mode we shouldn't need (like icomplete-vertical-separator-alist or a face icomplete-vertical-separator) unless we want to add them now.
>
>Again, Ergus is completely right! Those, with the benefit of hindsight, are over-engineered and shouldn't be included in Emacs. Heck, they shouldn't even be in icomplete-vertical. (I've learned that lesson and although I subsequently wrote a few more completion UIs, I didn't include options analogous to those.)
>
>-- 
>Omar Antol�n Camarena
>

Re: vertical fido-mode

[Ergus]

On Thu, Jun 11, 2020 at 02:08:56AM +0300, Juri Linkov wrote:
>>> So in my opinion maybe we can provide the vertical mode in a simpler way
>>> just improving icomplete-completions and some other small changes here
>>> and there. WDYT?
>>
>> It could also add a different way to "select" a previous or next
>> completion: instead of rotating the list, move the highlight (and some
>> fringe indicator, maybe).
>
>Or show vertical completions in the *Completions* buffer and use the
>current icomplete keys to navigate the *Completions* list from the minibuffer.
>
Yes, that's like a zsh completion experience. But in my opinion it is
more like a *Completions* buffer functionality right? (add bindings and
autoinsert to the Complete buffer)

I am not sure it should be in icomplete. Personally I consider that the
*Completions* buffer conflicts with the completion list shown from fido
or icomplete and shouldn't be shown when using icomplete, fido, ido as
it is not shown in ivy or helm.

Re: vertical fido-mode

[Ergus]

On Thu, Jun 11, 2020 at 02:23:06AM +0300, Dmitry Gutov wrote:
>On 11.06.2020 02:08, Juri Linkov wrote:
>>Or show vertical completions in the*Completions*  buffer and use the
>>current icomplete keys to navigate the*Completions*  list from the minibuffer.
>
>I could be wrong (not having seen the result), but IMHO that's not 
>what the majority of icomplete-vertical users are expecting. They/us 
>expect something more like Ivy.
>
I agree with the expected (ivy like) experience, but I would prefer not
to add too much complexity to icomplete. Ivy started as a simplified
version of icomplete (< 800 lines) and it grow up to thousands of
lines (>7000).

So for the moment I think that vertical layout could be enough right? If
the user wants ivy there is ivy (btw: maybe ivy should be in elpa but
that's another topic).

Re: vertical fido-mode

[Noam Postavsky]

On Thu, 11 Jun 2020 at 09:22, Ergus <spacibba@aol.com> wrote:

> (btw: maybe ivy should be in elpa but that's another topic).

Looks like it already is in GNU ELPA: https://elpa.gnu.org/packages/ivy.html

Re: vertical fido-mode

[Ergus]

On Thu, Jun 11, 2020 at 09:28:50AM -0400, Noam Postavsky wrote:
>On Thu, 11 Jun 2020 at 09:22, Ergus <spacibba@aol.com> wrote:
>
>> (btw: maybe ivy should be in elpa but that's another topic).
>
>Looks like it already is in GNU ELPA: https://elpa.gnu.org/packages/ivy.html
>
Right, sorry. I thought it was in melpa. Better then.

If we want some of the ivy functionalities in icomplete should we contact
the ivy maintainer for contribution? 

Re: vertical fido-mode

[Omar Antolín Camarena]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

Yes, I'd be happy to make the changes. What does that look like
logistically? Sending patches to this mailing list asking for review?
(Sorry, I know this must be explained somewhere but I haven't done much
research about how to contribute to Emacs yet.)

I don't have a copyright assignment yet, but some kind folks are educating
me about how to procure it over at the icomplete-vertical repo.

https://github.com/oantolin/icomplete-vertical/issues/14

As an aside, have you tried non-fido icomplete? There is one simple change
that makes it infinitely better in my opinion: fido forces a
completion-style choice on you, icomplete gives you freedom to choose for
yourself! (I shouldn't say so because I'm the author but I love the
orderless completion-style: https://github.com/oantolin/orderless.)

[-- Attachment #2: Type: text/html, Size: 1104 bytes --]

Re: vertical fido-mode

[Ergus]

On Thu, Jun 11, 2020 at 08:44:47AM -0500, Omar Antol�n Camarena wrote:
>Yes, I'd be happy to make the changes. What does that look like
>logistically? Sending patches to this mailing list asking for review?
>(Sorry, I know this must be explained somewhere but I haven't done much
>research about how to contribute to Emacs yet.)
>
Once you have the copyright Eli will give you write access to the main
repo if you have a contribution to add.

Usually you create a feature/something branch where you add your
changes. Once the big guys (Eli, Stefan, Basil) approves/correct the
changes; you merge your branch into the master branch.

You could also send patches to the mailing list, but you'll need a
copyright to be accepted, but they can be reviewed.

Usually a completed feature requires the implementation, some lines in
the NEWS file and some lines in the manual... but don't worry the guys
will help you in the process.

In the mean time I recommend you to create an emacs fork somewhere else
to start working if you prefer (because the copyright sometimes last
for some days/weeks).

>I don't have a copyright assignment yet, but some kind folks are educating
>me about how to procure it over at the icomplete-vertical repo.
>
>https://github.com/oantolin/icomplete-vertical/issues/14
>
Good, just fill the form, you will receive an email with a document to
sign, scan and resend and in some days you will receive the copyright.

>As an aside, have you tried non-fido icomplete? There is one simple change
>that makes it infinitely better in my opinion: fido forces a
>completion-style choice on you, icomplete gives you freedom to choose for
>yourself! (I shouldn't say so because I'm the author but I love the
>orderless completion-style: https://github.com/oantolin/orderless.)

Fido is actually a "simple package". It is almost a config with some
custom defaults for icomplete The idea behind fido was to create a fully
functional ido substitutor based on icomplete so Joao tried to reproduce
ido's behavior as much as possible..

Welcome on board!

Re: vertical fido-mode

[Protesilaos Stavrou]

Ergus <spacibba@aol.com> [2020-06-11, 15:40 +0200]:

> If we want some of the ivy functionalities in icomplete should we contact
> the ivy maintainer for contribution? 

For the sake of completeness, Omar Antolín Camarena already develops
packages that extend Icomplete in ways that make it more Ivy-like.

* 'orderless' pattern matching :: Completion style that offers
  out-of-order matches, while also supporting multiple methods (regexp,
  flex, string, initials).[0]

* 'embark' contextual custom actions :: Minibuffer commands that act on
  the current candidate or the entire list of candidates.  These are
  implemented as keymaps.[1]

[0]: https://github.com/oantolin/orderless
[1]: https://github.com/oantolin/embark

-- 
Protesilaos Stavrou
protesilaos.com

Re: vertical fido-mode

[Omar Antolín Camarena]

[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

I just want to add that there is nothing icomplete-specific in either
orderless or embark. Indeed, they can both be used with the default
minibuffer completion or even with 3rd party completion UIs such as
Selectrum.

On Thu, Jun 11, 2020 at 10:49 AM Protesilaos Stavrou <public@protesilaos.com>
wrote:

> Ergus <spacibba@aol.com> [2020-06-11, 15:40 +0200]:
>
> > If we want some of the ivy functionalities in icomplete should we contact
> > the ivy maintainer for contribution?
>
> For the sake of completeness, Omar Antolín Camarena already develops
> packages that extend Icomplete in ways that make it more Ivy-like.
>
> * 'orderless' pattern matching :: Completion style that offers
>   out-of-order matches, while also supporting multiple methods (regexp,
>   flex, string, initials).[0]
>
> * 'embark' contextual custom actions :: Minibuffer commands that act on
>   the current candidate or the entire list of candidates.  These are
>   implemented as keymaps.[1]
>
> [0]: https://github.com/oantolin/orderless
> [1]: https://github.com/oantolin/embark
>
> --
> Protesilaos Stavrou
> protesilaos.com
>


-- 
Omar Antolín Camarena

[-- Attachment #2: Type: text/html, Size: 1894 bytes --]

Re: vertical fido-mode

[Andrew Schwartzmeyer]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

Funnily enough:

> On Jun 11, 2020, at 9:00 AM, emacs-devel-request@gnu.org wrote:
> 
> As an aside, have you tried non-fido icomplete? There is one simple change that makes it infinitely better in my opinion: fido forces a completion-style choice on you, icomplete gives you freedom to choose for yourself! (I shouldn't say so because I'm the author but I love the orderless completion-style: https://github.com/oantolin/orderless <https://github.com/oantolin/orderless>.)

I came to emacs-devel a few weeks ago for a way to use orderless in fido, and João kindly showed me:

(add-hook 'icomplete-minibuffer-setup-hook
            (lambda ()
              (setq-local completion-styles '(orderless partial-completion))))

Which makes fido-mode use different completion styles. So it’s not necessarily forced, it’s just not as easy as modifying a defcustom.

Cheers,

Andy

P.S. I’m replying from the digest for the first time, hoping the threading isn’t screwed up.

[-- Attachment #2: Type: text/html, Size: 2968 bytes --]

Re: vertical fido-mode

[Basil L. Contovounesios]

Ergus <spacibba@aol.com> writes:

> Once the big guys (Eli, Stefan, Basil) approves/correct the changes;
> you merge your branch into the master branch.

I've indeed been eating a bit too much junk lately but I wouldn't call
myself big. ;)  Unless there's a fellow herb around I haven't noticed?

-- 
Basil

Re: vertical fido-mode

[Basil L. Contovounesios]

Protesilaos Stavrou <public@protesilaos.com> writes:

> Ergus <spacibba@aol.com> [2020-06-11, 15:40 +0200]:
>
>> If we want some of the ivy functionalities in icomplete should we contact
>> the ivy maintainer for contribution? 
>
> For the sake of completeness, Omar Antolín Camarena already develops
> packages that extend Icomplete in ways that make it more Ivy-like.
>
> * 'orderless' pattern matching :: Completion style that offers
>   out-of-order matches, while also supporting multiple methods (regexp,
>   flex, string, initials).[0]
>
> * 'embark' contextual custom actions :: Minibuffer commands that act on
>   the current candidate or the entire list of candidates.  These are
>   implemented as keymaps.[1]
>
> [0]: https://github.com/oantolin/orderless
> [1]: https://github.com/oantolin/embark

And for even more complete completeness: in general Ivy does its own
thing rather than trying to reuse core completion tools, so its
desirable features can be copied without necessarily needing to import
much, if any, code.

-- 
Basil

Re: vertical fido-mode

[Juri Linkov]

> So for the moment I think that vertical layout could be enough right?

Actually the hardest question is to decide what keys to use
to navigate completions in the vertical layout.  It would be
natural to use arrow keys and M-p/n, but there keys are used
for history navigation in the minibuffer.

Re: vertical fido-mode

[Dmitry Gutov]

On 18.06.2020 00:50, Juri Linkov wrote:
> Actually the hardest question is to decide what keys to use
> to navigate completions in the vertical layout.  It would be
> natural to use arrow keys and M-p/n, but there keys are used
> for history navigation in the minibuffer.

I think C-n/P-n is what users would expect. See Ivy, Helm, etc.

Arrow keys, too.

Re: vertical fido-mode

[João Távora]

On Wed, Jun 17, 2020 at 11:09 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 18.06.2020 00:50, Juri Linkov wrote:
> > Actually the hardest question is to decide what keys to use
> > to navigate completions in the vertical layout.  It would be
> > natural to use arrow keys and M-p/n, but there keys are used
> > for history navigation in the minibuffer.
>
> I think C-n/P-n is what users would expect. See Ivy, Helm, etc.
>
> Arrow keys, too.

But those already have meaning in navigating history. So
before a potentially compatibility-breaking decision is made,
we must understand exactly what we're gaining and losing.

Contrary to what I believed C-n and C-p should be fine,
though.  I personally want to never lose C-s/C-r because
that's what Ido uses.

In fact, I hope this discussion (of which I've missed a
few mails) is now concentrating on adding this to Icomplete,
not Fido specifically.

João

Re: vertical fido-mode

[Juri Linkov]

>> Actually the hardest question is to decide what keys to use
>> to navigate completions in the vertical layout.  It would be
>> natural to use arrow keys and M-p/n, but there keys are used
>> for history navigation in the minibuffer.
>
> I think C-n/P-n is what users would expect. See Ivy, Helm, etc.
>
> Arrow keys, too.

I can't believe - these keys are so handy for history navigation.
Or maybe it's possible to navigate history using completion lists?
Then history can be navigated using completion keys.

RE: vertical fido-mode

[Drew Adams]

> Contrary to what I believed C-n and C-p should be fine,
> though.  I personally want to never lose C-s/C-r because
> that's what Ido uses.
> 
> In fact, I hope this discussion (of which I've missed a
> few mails) is now concentrating on adding this to Icomplete,
> not Fido specifically.

Please don't add any bindings for C-n/C-p to any
standard minibuffer keymaps.  If you localize the
bindings, so they apply only to IDO, FIDO, Icomplete,
or whatever, e.g. `ido-completion-map', then OK -
I don't care about the bindings for those.

But the minibuffer is much more general than such
uses of it.  In general it's an editing buffer, and
in particular it can have multiple lines.  In the
standard minibuffer keymaps, C-n/C-p need to keep
their usual bindings of `(next/previous)-line',
please.

Re: vertical fido-mode

[João Távora]

On Wed, Jun 17, 2020 at 11:31 PM Drew Adams <drew.adams@oracle.com> wrote:
>
> > Contrary to what I believed C-n and C-p should be fine,
> > though.  I personally want to never lose C-s/C-r because
> > that's what Ido uses.
> >
> > In fact, I hope this discussion (of which I've missed a
> > few mails) is now concentrating on adding this to Icomplete,
> > not Fido specifically.
>
> Please don't add any bindings for C-n/C-p to any
> standard minibuffer keymaps.  If you localize the
> bindings, so they apply only to IDO, FIDO, Icomplete,
> or whatever, e.g. `ido-completion-map', then OK -
> I don't care about the bindings for those.

Noted. I think that is the plan, so you needn't worry much.
But anyway, how often do you come across cases of
multi-line completing-read?  At any rate, what's being
proposed is a multi-line minibuffer, if I understand correctly.

João

Re: vertical fido-mode

[Dmitry Gutov]

On 18.06.2020 01:22, Juri Linkov wrote:
> I can't believe - these keys are so handy for history navigation.

M-n/M-p would still be there.

As for arrow keys, I'd designate C-<up> and C-<down> for this purpose.

 > Or maybe it's possible to navigate history using completion lists?

I'm not sure how that would look.

Re: vertical fido-mode

[Juri Linkov]

>> Contrary to what I believed C-n and C-p should be fine,
>> though.  I personally want to never lose C-s/C-r because
>> that's what Ido uses.
>
> Please don't add any bindings for C-n/C-p to any
> standard minibuffer keymaps.

What keys would be better for vertical completions navigation?
Maybe M-up and M-down like in web browsers?

RE: vertical fido-mode

[Drew Adams]

> > Please don't add any bindings for C-n/C-p to any
> > standard minibuffer keymaps.  If you localize the
> > bindings, so they apply only to IDO, FIDO, Icomplete,
> > or whatever, e.g. `ido-completion-map', then OK -
> > I don't care about the bindings for those.
> 
> Noted. I think that is the plan, so you needn't worry much.
> But anyway, how often do you come across cases of
> multi-line completing-read?

Often.

For one thing, some common uses of completion in Icicles
allow for "multi-completion", which means providing
any of a number of possible subpatterns to match.

Those are separated by a separator string, whose default
value is "^G^J", that is, the two chars Control-G and
Control J.  Those chars are unlikely to be used in most
patterns.  (That string is inserted by hitting `C-M-j'.)
And the ^J is a newline char, of course.

For another thing, it's often the case that completion
candidates in Icicles are multiline.  Because you can
use various kinds of pattern matching, you can easily
match against multiple lines.  And you can cycle among
candidates (which fills the minibuffer with a candidate,
which can be multiline).

Whenever you have multiline text in the minibuffer, you
can want to edit that as a pattern to match, and C-n/C-p
are a good way to move among lines.

> At any rate, what's being proposed is a multi-line
> minibuffer, if I understand correctly.

I haven't been following this thread.  But if the content
of the minibuffer can/will be multiline, then I should
think that you would want to keep C-n/C-p with their
usual bindings.

Re: vertical fido-mode

[Dmitry Gutov]

On 18.06.2020 01:52, Dmitry Gutov wrote:
> On 18.06.2020 01:22, Juri Linkov wrote:
>> I can't believe - these keys are so handy for history navigation.
> 
> M-n/M-p would still be there.
> 
> As for arrow keys, I'd designate C-<up> and C-<down> for this purpose.

Just like in M-x shell and M-x eshell.

RE: vertical fido-mode

[Drew Adams]

> > As for arrow keys, I'd designate C-<up> and C-<down> for this purpose.
> 
> Just like in M-x shell and M-x eshell.

Whatever keys you use, please don't bind them in the
standard minibuffer keymaps.

RE: vertical fido-mode

[Drew Adams]

>  > Or maybe it's possible to navigate history using completion lists?
> 
> I'm not sure how that would look.

FWIW, in Icicles you can do all of these things to
"navigate history using completion":

1. Use `M-o' when in the minibuffer (not necessarily
   for completion), to use completion to insert any
   number of history elements in the minibuffer at
   its cursor.

   This enters a recursive minibuffer, to complete
   input against the current history list.  `RET' after
   inserting any number of history elements ends that
   recursive minibuffer (and you can use `M-o' again,
   to insert more).

   (`M-o' is a multi-command, which means you can act
   on any number of candidates in the same command
   invocation.)

2. Use `M-h' during completion, to match your current
   input pattern against the minibuffer history (only).

3. Use `M-<pause>' during completion, to restrict the
   current set of completion candidates to those in
   the current history list.

`M-h' and `M-<pause>' are similar.  `M-<pause>' takes
the current set of matching candidates into account,
filtering them to only those used as previous input.
It's a completion-candidates _set_ operation.  `M-h'
matches input against anything in the current history,
regardless of whether it belongs to the current set
of matching candidates.

https://www.emacswiki.org/emacs/Icicles_-_History_Enhancements

RE: vertical fido-mode

[Drew Adams]

> > Please don't add any bindings for C-n/C-p to any
> > standard minibuffer keymaps.
> 
> What keys would be better for vertical completions navigation?
> Maybe M-up and M-down like in web browsers?

Don't know/care.  Whatever keys you choose, please
just don't bind them in a standard minibuffer keymap
(`minibuffer-local-*').

Re: vertical fido-mode

[Kévin Le Gouguec]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 18.06.2020 00:50, Juri Linkov wrote:
>> Actually the hardest question is to decide what keys to use
>> to navigate completions in the vertical layout.  It would be
>> natural to use arrow keys and M-p/n, but there keys are used
>> for history navigation in the minibuffer.
>
> I think C-n/P-n is what users would expect. See Ivy, Helm, etc.
>
> Arrow keys, too.

As a former Ivy user who went back to icomplete and is now following
this thread with a lot of attention, my vote also goes for C-n/C-p for
next/previous candidate selection, and M-n/M-p for history navigation.

(Actually, I wouldn't mind C-n/C-p in regular (non-vertical) icomplete;
C-. is not super-ergonomic on AZERTY.  I liked C-M-i, but it's been
decommissioned in Emacs 27…)

Re: vertical fido-mode

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 2372 bytes --]

Hi

I agree that this (C-p/C-n && <up> <down>) is the most intuitive in vertical and they shouldn't apply in non-vertical mode (cause <right> <left> is more intuitive then). C-s && C-r could do the same in both cases. For history navegation in vertical M-p and M-n could work fine.

If we want fido fully emulate ido; in the package ido-vertical there is something we could also provide somehow (maybe not exactly in the same way):

| (defun ido-vertical-define-keys () |
|  | (when ido-vertical-define-keys |
|  |  (define-key ido-completion-map (kbd "C-n") 'ido-next-match) |
|  |  (define-key ido-completion-map (kbd "C-p") 'ido-prev-match) |
|  |  (define-key ido-completion-map (kbd "C-c C-t") 'ido-toggle-prefix)) |
|  |  (when (memq ido-vertical-define-keys '(C-n-C-p-up-and-down C-n-C-p-up-down-left-right)) |
|  |  (define-key ido-completion-map (kbd "<up>") 'ido-prev-match) |
|  |  (define-key ido-completion-map (kbd "<down>") 'ido-next-match)) |
|  |  (when (eq ido-vertical-define-keys 'C-n-C-p-up-down-left-right) |
|  |  (define-key ido-completion-map (kbd "<left>") 'ido-vertical-prev-match) |
|  |  (define-key ido-completion-map (kbd "<right>") 'ido-vertical-next-match))) |


-----Original Message-----
From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: Ergus <spacibba@aol.com>; emacs-devel@gnu.org <emacs-devel@gnu.org>; monnier@iro.umontreal.ca <monnier@iro.umontreal.ca>; Juri Linkov <juri@linkov.net>
Sent: Thu, Jun 18, 2020 10:22 am
Subject: Re: vertical fido-mode

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 18.06.2020 00:50, Juri Linkov wrote:
>> Actually the hardest question is to decide what keys to use
>> to navigate completions in the vertical layout.  It would be
>> natural to use arrow keys and M-p/n, but there keys are used
>> for history navigation in the minibuffer.
>
> I think C-n/P-n is what users would expect. See Ivy, Helm, etc.
>
> Arrow keys, too.

As a former Ivy user who went back to icomplete and is now following
this thread with a lot of attention, my vote also goes for C-n/C-p for
next/previous candidate selection, and M-n/M-p for history navigation.

(Actually, I wouldn't mind C-n/C-p in regular (non-vertical) icomplete;
C-. is not super-ergonomic on AZERTY.  I liked C-M-i, but it's been
decommissioned in Emacs 27…)

[-- Attachment #2: Type: text/html, Size: 16588 bytes --]

Re: vertical fido-mode

[Stefan Monnier]

> Yes, I'd be happy to make the changes.  What does that look like
> logistically? Sending patches to this mailing list asking for review?

That works, yes.

> I don't have a copyright assignment yet, but some kind folks are educating
> me about how to procure it over at the icomplete-vertical repo.

Great.  Let me know if you need any further help with that.


        Stefan

Re: vertical fido-mode

[Juri Linkov]

>> Or maybe it's possible to navigate history using completion lists?
>
> I'm not sure how that would look.

Currently completion is performed on a set of all possible values.
In addition to this, completion could be performed on a set of
all previously entered values (history items), or on default items
(a list of the most useful values).  This shows all 3 possibilities:

(completing-read "Prompt: "
                 minibuffer-history nil nil nil
                 'minibuffer-history
                 minibuffer-history)

M-n - defaults list, M-p - history list, TAB - completion on history list.

In a normal minibuffer maybe there should be a key to switch between
normal completion, completion on defaults, and completion on history.
Also maybe another key to sort history items by recency/frequency
in the completion list.

Re: vertical fido-mode

[João Távora]

On Thu, Jun 18, 2020 at 11:36 PM Juri Linkov <juri@linkov.net> wrote:
>
> >> Or maybe it's possible to navigate history using completion lists?
> >
> > I'm not sure how that would look.
>
> Currently completion is performed on a set of all possible values.
> In addition to this, completion could be performed on a set of
> all previously entered values (history items), or on default items
> (a list of the most useful values).  This shows all 3 possibilities:
>
> (completing-read "Prompt: "
>                  minibuffer-history nil nil nil
>                  'minibuffer-history
>                  minibuffer-history)
>
> M-n - defaults list, M-p - history list, TAB - completion on history list.
>
> In a normal minibuffer maybe there should be a key to switch between
> normal completion, completion on defaults, and completion on history.
> Also maybe another key to sort history items by recency/frequency
> in the completion list.

I think, you are starting to describe incremental reverse history search,
or C-r in normal minibuffers.  It works in icomplete, too, but not too
well in my opinion.  Still, it's better to fix that than to reinvent the wheel.

João

Re: vertical fido-mode

[Juri Linkov]

>> >> Or maybe it's possible to navigate history using completion lists?
>> >
>> > I'm not sure how that would look.
>>
>> Currently completion is performed on a set of all possible values.
>> In addition to this, completion could be performed on a set of
>> all previously entered values (history items), or on default items
>> (a list of the most useful values).  This shows all 3 possibilities:
>>
>> (completing-read "Prompt: "
>>                  minibuffer-history nil nil nil
>>                  'minibuffer-history
>>                  minibuffer-history)
>>
>> M-n - defaults list, M-p - history list, TAB - completion on history list.
>>
>> In a normal minibuffer maybe there should be a key to switch between
>> normal completion, completion on defaults, and completion on history.
>> Also maybe another key to sort history items by recency/frequency
>> in the completion list.
>
> I think, you are starting to describe incremental reverse history search,
> or C-r in normal minibuffers.  It works in icomplete, too, but not too
> well in my opinion.  Still, it's better to fix that than to reinvent the wheel.

Actually I meant displaying a list of completions (no matter whether
in the *Completions* buffer or inline like in icomplete) based on
different sets of input data (on all possible values like default completion,
or on all history items...)

Re: vertical fido-mode

[João Távora]

On Thu, Jun 18, 2020 at 11:53 PM Juri Linkov <juri@linkov.net> wrote:
>
> >> >> Or maybe it's possible to navigate history using completion lists?
> >> >
> >> > I'm not sure how that would look.
> >>
> >> Currently completion is performed on a set of all possible values.
> >> In addition to this, completion could be performed on a set of
> >> all previously entered values (history items), or on default items
> >> (a list of the most useful values).  This shows all 3 possibilities:
> >>
> >> (completing-read "Prompt: "
> >>                  minibuffer-history nil nil nil
> >>                  'minibuffer-history
> >>                  minibuffer-history)
> >>
> >> M-n - defaults list, M-p - history list, TAB - completion on history list.
> >>
> >> In a normal minibuffer maybe there should be a key to switch between
> >> normal completion, completion on defaults, and completion on history.
> >> Also maybe another key to sort history items by recency/frequency
> >> in the completion list.
> >
> > I think, you are starting to describe incremental reverse history search,
> > or C-r in normal minibuffers.  It works in icomplete, too, but not too
> > well in my opinion.  Still, it's better to fix that than to reinvent the wheel.
>
> Actually I meant displaying a list of completions (no matter whether
> in the *Completions* buffer or inline like in icomplete) based on
> different sets of input data (on all possible values like default completion,
> or on all history items...)

Sorry, Juri.  Perhaps I read your email in a hurry. I'm not opposed to
having new forms of navigating history or other collections of potential
completions, of course.  I was just mentioning that within the current
completion interface, both the regular minibufer, Icomplete and Ido
have ways to reach back to history items using "reverse-isearch".  The
regular minibuffer's is triggered by C-r and in Ido it's simply a question
of typing something, then typing M-p, if I recall correctly.  In Icomplete,
C-r works , but what follows is not completely intuitive, IMO. It should
be perfected.  What I said for Icomplete goes for Fido, except that uses
C-M-r because its C-r is used for something else.

João

-- 
João Távora

Re: vertical fido-mode

[Ergus]

Hi:

Any progress on this? need some help?

Best,
Ergus

On Thu, Jun 18, 2020 at 09:51:52AM -0400, Stefan Monnier wrote:
>> Yes, I'd be happy to make the changes.  What does that look like
>> logistically? Sending patches to this mailing list asking for review?
>
>That works, yes.
>
>> I don't have a copyright assignment yet, but some kind folks are educating
>> me about how to procure it over at the icomplete-vertical repo.
>
>Great.  Let me know if you need any further help with that.
>
>
>        Stefan
>
>

Re: vertical fido-mode

[Ergus via Emacs development discussions.]

[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]

On Thu, Jun 11, 2020 at 02:08:56AM +0300, Juri Linkov wrote:

>Or show vertical completions in the *Completions* buffer and use the
>current icomplete keys to navigate the *Completions* list from the minibuffer.
>

Hi!

Coming back to this thread, I just made this very simple patch
(attached) to provide a sort of "zsh" like experience in the
*Completion* buffer.

I would love to see a version of this enabled by default in emacs (to
feel we are a bit in 2020 and give a more friendly first impression to
new users); but I know that changing defaults will start a war. So I
won't even try to argue about that; so I added variables to customize
everything.

If you are interested, you can try it and I will be very happy with any
suggestions and critics if you thing this can be added to master in the
future.

It basically adds:

1) enforces navigation throw completion candidates (no go to header or
random useless places in *completion* buffer).

2) Current candidate highlight with the 'highlight face.

3) Second tab in minibuffer with completion shown and all candidates
visible (no need scroll) jump to *Completions* buffer (similar to zsh).

4) Skip Completion buffer with C-g.

The intentions of this is just to tweak a little the *Completions*
interaction keeping everything extremely simple.

At the end after a couple of hours most of the users go for Ido, help or
Ivy. But this doesn't mean we shouldn't improve the first impression
right?

OTOH: I would like to know if Omar finally got the copyright otherwise I
will try to implement the vertical-fido/Icompletes mode.

Best,
Ergus


[-- Attachment #2: complete.patch --]
[-- Type: text/plain, Size: 4538 bytes --]

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 641a2e5315..7c5025b11c 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -753,6 +753,12 @@ minibuffer-message-clear-timeout
                  (integer :tag "Wait for the number of seconds" 2))
   :version "27.1")
 
+(defcustom minibuffer-tab-go-completion t
+  "If a second `TAB' jump to completion buffer."
+  :type 'boolean
+  :version "28.1"
+  :group 'completion)
+
 (defvar minibuffer-message-timer nil)
 (defvar minibuffer-message-overlay nil)
 
@@ -940,6 +946,8 @@ completion-styles
   :type completion--styles-type
   :version "23.1")
 
+
+
 (defvar completion-category-defaults
   '((buffer (styles . (basic substring)))
     (unicode-name (styles . (basic substring)))
@@ -1288,8 +1296,12 @@ completion--in-region-1
     (let ((window minibuffer-scroll-window))
       (with-current-buffer (window-buffer window)
         (if (pos-visible-in-window-p (point-max) window)
-            ;; If end is in view, scroll up to the beginning.
-            (set-window-start window (point-min) nil)
+            (if (and minibuffer-tab-go-completion
+                     (pos-visible-in-window-p (point-min) window))
+                ;; If all completions are visible move cursor there
+                (switch-to-completions)
+                ;; If end is in view, scroll up to the beginning.
+              (set-window-start window (point-min) nil))
           ;; Else scroll down one screen.
           (with-selected-window window
 	    (scroll-up)))
diff --git a/lisp/simple.el b/lisp/simple.el
index b45fb87887..c203efe16d 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8359,6 +8359,12 @@ set-variable
 \f
 ;; Define the major mode for lists of completions.
 
+(defcustom completion-highlight-candidate t
+  "Non-nil means show help message in *Completions* buffer."
+  :type 'boolean
+  :version "28.1"
+  :group 'completion)
+
 (defvar completion-list-mode-map
   (let ((map (make-sparse-keymap)))
     (define-key map [mouse-2] 'choose-completion)
@@ -8372,6 +8378,12 @@ completion-list-mode-map
     (define-key map [backtab] 'previous-completion)
     (define-key map "q" 'quit-window)
     (define-key map "z" 'kill-current-buffer)
+
+    (define-key map (kbd "C-g") 'quit-window)
+    (define-key map (kbd "<up>") 'previous-line-completion)
+    (define-key map (kbd "C-p") 'previous-line-completion)
+    (define-key map (kbd "<down>") 'next-line-completion)
+    (define-key map (kbd "C-n") 'next-line-completion)
     map)
   "Local map for completion list buffers.")
 
@@ -8410,6 +8422,19 @@ completion-base-size
 If nil, Emacs determines which part of the tail end of the
 buffer's text is involved in completion by comparing the text
 directly.")
+
+(defvar completion-overlay nil
+  "Use a face to highlight completion candidate.")
+
+(defun move-completion-overlay ()
+  "Update completion overlay to highlight current candidate."
+  (let* ((obeg (point))
+         (oend (next-single-property-change obeg 'mouse-face nil (point-max))))
+    (unless (overlayp completion-overlay)
+      (setq completion-overlay (make-overlay 0 0))
+      (overlay-put completion-overlay 'face 'highlight))
+    (move-overlay completion-overlay obeg oend)))
+
 (make-obsolete-variable 'completion-base-size 'completion-base-position "23.2")
 
 (defun delete-completion-window ()
@@ -8428,7 +8453,7 @@ previous-completion
   (interactive "p")
   (next-completion (- n)))
 
-(defun next-completion (n)
+(defun next-completion (n &optional no-move-overlay)
   "Move to the next item in the completion list.
 With prefix argument N, move N items (negative N means move backward)."
   (interactive "p")
@@ -8454,7 +8479,25 @@ next-completion
 	;; Move to the start of that one.
 	(goto-char (previous-single-property-change
 		    (point) 'mouse-face nil beg))
-	(setq n (1+ n))))))
+	(setq n (1+ n)))))
+
+  (when (and completion-highlight-candidate
+             (not no-move-overlay))
+    (move-completion-overlay)))
+
+(defun next-line-completion (&optional arg try-vscroll)
+  "Go to completion candidate in line bellow current."
+  (interactive "^p\np")
+  (line-move arg t nil try-vscroll)
+  (next-completion 1 t)
+  (next-completion -1))
+
+(defun previous-line-completion (&optional arg try-vscroll)
+  "Go to completion candidate in line above current."
+  (interactive "^p\np")
+  (line-move (- arg) t nil try-vscroll)
+  (next-completion -1 t)
+  (next-completion 1))
 
 (defun choose-completion (&optional event)
   "Choose the completion at point.

Re: vertical fido-mode

[Juri Linkov]

>>Or show vertical completions in the *Completions* buffer and use the
>>current icomplete keys to navigate the *Completions* list from the minibuffer.
>
> Coming back to this thread, I just made this very simple patch
> (attached) to provide a sort of "zsh" like experience in the
> *Completion* buffer.
>
> If you are interested, you can try it and I will be very happy with any
> suggestions and critics if you thing this can be added to master in the
> future.

Thanks, some suggestions below.

> It basically adds:
>
> 1) enforces navigation throw completion candidates (no go to header or
> random useless places in *completion* buffer).
>
> 2) Current candidate highlight with the 'highlight face.
>
> 3) Second tab in minibuffer with completion shown and all candidates
> visible (no need scroll) jump to *Completions* buffer (similar to zsh).

But zsh doesn't jump to completions - the cursor remains on the command line
(the minibuffer in Emacs).  Something like this would be more preferable
where navigation keys will insert completions from the *Completions* buffer
to the minibuffer - without leaving the minibuffer.

Re: vertical fido-mode

[Ergus]

On Thu, Aug 20, 2020 at 03:35:57AM +0300, Juri Linkov wrote:
>
>But zsh doesn't jump to completions - the cursor remains on the command line
>(the minibuffer in Emacs).  Something like this would be more preferable
>where navigation keys will insert completions from the *Completions* buffer
>to the minibuffer - without leaving the minibuffer.

Hi Jury:

This is why I said zsh-like. The problem with this is that in
*Completions* some letters like q or z are bind to something and
changing that will modify too much the actual user experience.

While in the minibuffer the horizontal arrows are used to
move-forward/backward and the vertical to search in history.

Do you have any alternative?

OTOH this is the simplest I could implement making minimal changes with
the hope of making some of this enabled by default in the "near" future
without too many old users complains.

Otherwise we will implement just-another new mode that will be off by
default and probably nobody will use as there is ido/fido/icomplete/ivy
and so on.

So far there are some details in the actual user experience with
*Completes* I didn't change intentionally.

1) Completions are only shown on demand (TAB)

2) When completions are shown TAB tries to scroll the completions buffer
if not all of them are visible (actual behavior)

3) The completions are updated on demand (TAB) only (unlike zsh that they are
updated automatically on input)

4) Arrows and navigation keys keep their current meaning either in
minibuffer and *Completions* buffer.

So far this doesn't changes the current experience at all, so old users
won't complain and we could enable this by default.

The only addition was the jump to completions with a TAB when all
completions are shown.

And exit completions with C-g like in zsh.

Do you think it worth doing a stronger change?

Re: vertical fido-mode

[Juri Linkov]

> While in the minibuffer the horizontal arrows are used to
> move-forward/backward and the vertical to search in history.
>
> Do you have any alternative?

An alternative would be to use the same keys as used in web browsers
to navigate completions from the url input field where M-up and M-down
are used to display a list of completions and to navigate in completions,
without switching to the completions buffer.

> OTOH this is the simplest I could implement making minimal changes with
> the hope of making some of this enabled by default in the "near" future
> without too many old users complains.
>
> Otherwise we will implement just-another new mode that will be off by
> default and probably nobody will use as there is ido/fido/icomplete/ivy
> and so on.
>
> So far there are some details in the actual user experience with
> *Completes* I didn't change intentionally.
>
> 1) Completions are only shown on demand (TAB)
>
> 2) When completions are shown TAB tries to scroll the completions buffer
> if not all of them are visible (actual behavior)

There are other keys that currently scroll the completions buffer as well:
M-PgUp, M-PgDown, M-C-v, S-M-C-v.

> 3) The completions are updated on demand (TAB) only (unlike zsh that they are
> updated automatically on input)

I think whether to show/update completions only on demand or to show/update
them automatically on input should be customizable with a new option.

> 4) Arrows and navigation keys keep their current meaning either in
> minibuffer and *Completions* buffer.
>
> So far this doesn't changes the current experience at all, so old users
> won't complain and we could enable this by default.

I agree that any changes in the default behavior should be unobtrusive.

> The only addition was the jump to completions with a TAB when all
> completions are shown.

The existing key that already jumps to completions is PgUp (M-v).

> And exit completions with C-g like in zsh.

The existing key to exit completions is ESC (delete-completion-window).

> Do you think it worth doing a stronger change?

I think that adding more logic to the existing key TAB is too strong
change: for example, when the user doesn't notice that the completions
buffer already displays all completions, types TAB again, and it switches
to the completions buffer contrary to user wishes.

OTOH, the feature of using TAB to switch to the completions buffer
doesn't work when the list of completions is too big and
not all completions are displayed.

Re: vertical fido-mode

[Ergus]

On Fri, Aug 21, 2020 at 02:15:36AM +0300, Juri Linkov wrote:

>
>An alternative would be to use the same keys as used in web browsers
>to navigate completions from the url input field where M-up and M-down
>are used to display a list of completions and to navigate in completions,
>without switching to the completions buffer.
>
yes, but this is what we have already in fido and the others somehow. I
wanted to keep things easier.

>
>There are other keys that currently scroll the completions buffer as well:
>M-PgUp, M-PgDown, M-C-v, S-M-C-v.
>
Yes, I know, but I shouldn't be able to change the TAB one. BTW in
terminal S-M-C-v conflicts with terminal yank.

>
>I think whether to show/update completions only on demand or to show/update
>them automatically on input should be customizable with a new option.
>
This is something simple to implement, but again, this something more in
the icompletes-ivy-ido experience.


>> The only addition was the jump to completions with a TAB when all
>> completions are shown.
>
>The existing key that already jumps to completions is PgUp (M-v).
>
Yes but somehow I found more "intuitive" to do it with tab.

>> And exit completions with C-g like in zsh.
>
>The existing key to exit completions is ESC (delete-completion-window).
>
Actually it is ESC ESC ESC. C-g was unbind in the Completions
buffer. Doing C-g (go return to minibuffer) and again C-g (to exit
minibuffer) is shorter and more intuitive than q C-g or ESC ESC ESC.

But don't worry this kind of changes I understand they require
discussion in the ML and are only kind of "proposals" to see reactions.

>> Do you think it worth doing a stronger change?
>
>I think that adding more logic to the existing key TAB is too strong
>change: for example, when the user doesn't notice that the completions
>buffer already displays all completions, types TAB again, and it switches
>to the completions buffer contrary to user wishes.
>
I agree, here. I just ran out of ideas to make it simple and "Intitive"

>OTOH, the feature of using TAB to switch to the completions buffer
>doesn't work when the list of completions is too big and
>not all completions are displayed.
>
Yes this was intentional to avoid changing the defaults.

Re: vertical fido-mode

[Juri Linkov]

>>An alternative would be to use the same keys as used in web browsers
>>to navigate completions from the url input field where M-up and M-down
>>are used to display a list of completions and to navigate in completions,
>>without switching to the completions buffer.
>>
> yes, but this is what we have already in fido and the others somehow. I
> wanted to keep things easier.

Easier can be only one thing: to use arrows and navigation keys to navigate
completions from the minibuffer.  So the main question is on what condition
to activate these keys (instead of allowing them to search in history)?

Since making TAB more DWIM doesn't work, what about the following solution:
activate completions navigation keys and display the completions buffer
only when there is some input in the minibuffer, i.e. when the minibuffer's
content is different from its default value.

Or similar to this https://api.jqueryui.com/autocomplete/#option-minLength
activate completions only when input is longer than the minimum number
of characters.

Re: vertical fido-mode (new branch)

[Ergus via Emacs development discussions.]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

Hi:

Could you please try the attached patch (where the mode is enabled by default).

On Sun, Aug 23, 2020 at 09:45:17PM +0300, Juri Linkov wrote:
>
>Easier can be only one thing: to use arrows and navigation keys to navigate
>completions from the minibuffer.  So the main question is on what condition
>to activate these keys (instead of allowing them to search in history)?
>
I enabled the keys only when the *Completions* buffer is shown and the
highlight completions is active. And added a hook to remove the bindings
when minibuffer-hide-completions.

>Since making TAB more DWIM doesn't work, what about the following solution:
>activate completions navigation keys and display the completions buffer
>only when there is some input in the minibuffer, i.e. when the minibuffer's
>content is different from its default value.
>
Please try this closer to zsh experience implementation.

>Or similar to this https://api.jqueryui.com/autocomplete/#option-minLength
>activate completions only when input is longer than the minimum number
>of characters.
>

I will give a look.

If this patch is too much code for adding in simple and minibuffer, I
would try to make a separate file with a mode. WDYT?

Best,
Ergus

[-- Attachment #2: completion-highlight.patch --]
[-- Type: text/plain, Size: 14739 bytes --]

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 641a2e5315..cdc1e18708 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -753,6 +753,12 @@ minibuffer-message-clear-timeout
                  (integer :tag "Wait for the number of seconds" 2))
   :version "27.1")
 
+(defcustom minibuffer-tab-go-completion t
+  "If a second `TAB' jump to completion buffer."
+  :type 'boolean
+  :version "28.1"
+  :group 'completion)
+
 (defvar minibuffer-message-timer nil)
 (defvar minibuffer-message-overlay nil)
 
@@ -940,6 +946,8 @@ completion-styles
   :type completion--styles-type
   :version "23.1")
 
+
+
 (defvar completion-category-defaults
   '((buffer (styles . (basic substring)))
     (unicode-name (styles . (basic substring)))
@@ -1272,6 +1280,122 @@ minibuffer-complete
                           minibuffer-completion-table
                           minibuffer-completion-predicate)))
 
+(defmacro with-minibuffer-scroll-window (&rest body)
+  "Execute BODY in *Completions* buffer and return to `minibuffer'.
+The command is only executed if the `minibuffer-scroll-window' is
+alive and active."
+  `(and (window-live-p minibuffer-scroll-window)
+	(eq t (frame-visible-p (window-frame minibuffer-scroll-window)))
+	(with-selected-window minibuffer-scroll-window
+          (with-current-buffer (window-buffer minibuffer-scroll-window)
+            ,@body))))
+
+(defun minibuffer-next-completion (n)
+  "Execute `next-completion' in *Completions*.
+The argument N is passed directly to `next-completion', the
+command is executed in another window, but cursor stays in
+minibuffer."
+  (interactive "p")
+  (with-minibuffer-scroll-window (next-completion n)))
+
+(defun minibuffer-previous-completion (n)
+  "Execute `previous-completion' in *Completions*.
+The argument N is passed directly to `previous-completion', the
+command is executed in another window, but cursor stays in
+minibuffer."
+  (interactive "p")
+  (with-minibuffer-scroll-window (previous-completion n)))
+
+(defun minibuffer-next-line-completion (n)
+  "Execute `next-line-completion' in *Completions*.
+The argument N is passed directly to `next-line-completion', the
+command is executed in another window, but cursor stays in
+minibuffer."
+  (interactive "p")
+  (with-minibuffer-scroll-window (next-line-completion n)))
+
+(defun minibuffer-previous-line-completion (n)
+  "Execute `previous-line-completion' in *Completions*.
+The argument N is passed directly to `previous-line-completion',
+the command is executed in another window, but cursor stays in
+minibuffer."
+  (interactive "p")
+  (with-minibuffer-scroll-window (previous-line-completion n)))
+
+(defun minibuffer-completion-set-suffix (choice)
+  "Set CHOICE suffix to current completion.
+It uses `completion-base-position' to determine the cursor position"
+  (let* ((base-position (or completion-base-position
+                            (list (minibuffer-prompt-end)
+                                  (choose-completion-guess-base-position choice))))
+         (cursor-pos (cadr base-position))
+         (prefix-len (- cursor-pos
+                        (car base-position)))
+         (minibuffer-window (active-minibuffer-window))
+         (minibuffer-buffer (window-buffer minibuffer-window))
+         (completion-no-auto-exit t)
+         (suffix (if (< prefix-len (length choice))
+                     (substring choice prefix-len)
+                   ""))
+         (suffix-len (string-width suffix)))
+
+    (with-selected-window minibuffer-window
+      (with-current-buffer minibuffer-buffer
+
+        (choose-completion-string suffix minibuffer-buffer
+                                  (list cursor-pos (point-max)))
+        (add-face-text-property cursor-pos (+ cursor-pos suffix-len) 'shadow)
+        (goto-char cursor-pos)))))
+
+(defun minibuffer-completion-unset-suffix ()
+  "Remove suffix to current completion.
+It uses `completion-base-position' to determine the cursor position"
+  (minibuffer-completion-set-suffix ""))
+
+(defmacro completions-highlight-minibufer-bindings (set)
+  "Add extra/remove keybindings to `minibuffer-local-must-match-map'."
+  `(progn
+     (define-key minibuffer-local-must-match-map [right] ,(and set ''minibuffer-next-completion))
+     (define-key minibuffer-local-must-match-map [left] ,(and set ''minibuffer-previous-completion))
+     (define-key minibuffer-local-must-match-map [down] ,(and set ''minibuffer-next-line-completion))
+     (define-key minibuffer-local-must-match-map [up] ,(and set ''minibuffer-previous-line-completion))))
+
+(defun completions-highlight-unset-minibuffer-bindings ()
+  "Remove extra keybindings from `minibuffer-local-must-match-map'."
+  (completions-highlight-minibufer-bindings nil))
+
+(defmacro completions-highlight-completion-bindings (set)
+  "Add extra keybindings to `completion-list-mode-map'."
+  `(progn
+     (define-key completion-list-mode-map "\C-g" ,(and set ''quit-window))
+     (define-key completion-list-mode-map [up] ,(and set ''previous-line-completion))
+     (define-key completion-list-mode-map "\C-p" ,(and set ''previous-line-completion))
+     (define-key completion-list-mode-map [down] ,(and set ''next-line-completion))
+     (define-key completion-list-mode-map "\C-n" ,(and set ''next-line-completion))))
+
+(defun completions-highlight-unset-completion-bindings ()
+  "Remove extra keybindings from `completion-list-mode-map'."
+  (completions-highlight-completion-bindings nil))
+
+(defun completions-highlight-minibuffer-complete-setup ()
+  "Add extra functionalities for minibuffer when completions are enabled.
+This is called from `completion-setup-function'"
+  (when (and completion-highlight-candidate
+             (minibufferp))
+    (add-hook 'pre-command-hook
+              (lambda ()
+                ;; TODO: probably we need an alist here
+                ;; (message "Precommand %s" (current-local-map))
+                (unless (eq this-command 'minibuffer-complete-and-exit)
+                  (minibuffer-completion-unset-suffix))
+                )
+              nil t)
+    (add-hook 'minibuffer-hide-completions-hook
+              #'completions-highlight-unset-minibuffer-bindings)
+
+    (completions-highlight-minibufer-bindings t)
+    (completions-highlight-completion-bindings t)))
+
 (defun completion--in-region-1 (beg end)
   ;; If the previous command was not this,
   ;; mark the completion buffer obsolete.
@@ -1288,8 +1412,12 @@ completion--in-region-1
     (let ((window minibuffer-scroll-window))
       (with-current-buffer (window-buffer window)
         (if (pos-visible-in-window-p (point-max) window)
-            ;; If end is in view, scroll up to the beginning.
-            (set-window-start window (point-min) nil)
+            (if (and minibuffer-tab-go-completion
+                     (pos-visible-in-window-p (point-min) window))
+                (minibuffer-next-completion 1)
+                ;; If all completions are visible use tab completion
+              ;; If end is in view, scroll up to the beginning.
+              (set-window-start window (point-min) nil))
           ;; Else scroll down one screen.
           (with-selected-window window
 	    (scroll-up)))
@@ -1776,6 +1904,12 @@ completion-setup-hook
 The completion list buffer is available as the value of `standard-output'.
 See also `display-completion-list'.")
 
+(defvar minibuffer-hide-completions-hook nil
+  "Normal hook run at the end of completion-hide-completions.
+The hook is called from the minibuffer after hide completions.
+When this hook is run, the current buffer is the minibuffer and
+the *Completions* buffer is already hidden.")
+
 (defface completions-first-difference
   '((t (:inherit bold)))
   "Face for the first character after point in completions.
@@ -2040,7 +2174,6 @@ minibuffer-completion-help
                                    (completion--done result
                                                      (if (eq (car bounds) (length result))
                                                          'exact 'finished)))))))
-
                       (display-completion-list completions)))))
           nil)))
     nil))
@@ -2050,7 +2183,9 @@ minibuffer-hide-completions
   ;; FIXME: We could/should use minibuffer-scroll-window here, but it
   ;; can also point to the minibuffer-parent-window, so it's a bit tricky.
   (let ((win (get-buffer-window "*Completions*" 0)))
-    (if win (with-selected-window win (bury-buffer)))))
+    (when win
+      (with-selected-window win (bury-buffer))
+      (run-hooks 'minibuffer-hide-completions-hook))))
 
 (defun exit-minibuffer ()
   "Terminate this minibuffer argument."
@@ -2318,6 +2453,7 @@ completion-help-at-point
          (setq completion-in-region--data
                `(,start ,(copy-marker end t) ,collection
                         ,(plist-get plist :predicate)))
+
          (completion-in-region-mode 1)
          (minibuffer-completion-help start end)))
       (`(,hookfun . ,_)
@@ -3754,7 +3890,7 @@ completing-read-default
                                           require-match))
          (minibuffer--require-match require-match)
          (base-keymap (if require-match
-                         minibuffer-local-must-match-map
+                          minibuffer-local-must-match-map
                         minibuffer-local-completion-map))
          (keymap (if (memq minibuffer-completing-file-name '(nil lambda))
                      base-keymap
diff --git a/lisp/simple.el b/lisp/simple.el
index fa6e154004..27dc87217b 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8368,6 +8368,12 @@ set-variable
 \f
 ;; Define the major mode for lists of completions.
 
+(defcustom completion-highlight-candidate t
+  "Non-nil means show help message in *Completions* buffer."
+  :type 'boolean
+  :version "28.1"
+  :group 'completion)
+
 (defvar completion-list-mode-map
   (let ((map (make-sparse-keymap)))
     (define-key map [mouse-2] 'choose-completion)
@@ -8381,6 +8387,12 @@ completion-list-mode-map
     (define-key map [backtab] 'previous-completion)
     (define-key map "q" 'quit-window)
     (define-key map "z" 'kill-current-buffer)
+
+    (define-key map "\C-g" 'quit-window)
+    (define-key map [up] 'previous-line-completion)
+    (define-key map "\C-p" 'previous-line-completion)
+    (define-key map [down] 'next-line-completion)
+    (define-key map "\C-n" 'next-line-completion)
     map)
   "Local map for completion list buffers.")
 
@@ -8419,6 +8431,10 @@ completion-base-size
 If nil, Emacs determines which part of the tail end of the
 buffer's text is involved in completion by comparing the text
 directly.")
+
+(defvar completion-overlay nil
+  "Highlight to use when `completion-highlight-candidate' is non nil.")
+
 (make-obsolete-variable 'completion-base-size 'completion-base-position "23.2")
 
 (defun delete-completion-window ()
@@ -8432,15 +8448,9 @@ delete-completion-window
       (if (get-buffer-window buf)
 	  (select-window (get-buffer-window buf))))))
 
-(defun previous-completion (n)
-  "Move to the previous item in the completion list."
-  (interactive "p")
-  (next-completion (- n)))
-
-(defun next-completion (n)
+(defun goto-next-completion (n)
   "Move to the next item in the completion list.
 With prefix argument N, move N items (negative N means move backward)."
-  (interactive "p")
   (let ((beg (point-min)) (end (point-max)))
     (while (and (> n 0) (not (eobp)))
       ;; If in a completion, move to the end of it.
@@ -8465,6 +8475,46 @@ next-completion
 		    (point) 'mouse-face nil beg))
 	(setq n (1+ n))))))
 
+(defun next-completion (n)
+  "Move to the next item in the completion list.
+With prefix argument N, move N items (negative N means move backward).
+If completion highlight is enabled, highlights the selected candidate.
+Returns the completion string if available."
+  (interactive "p")
+  (goto-next-completion n)
+
+  (let* ((obeg (point))
+         (oend (next-single-property-change obeg 'mouse-face nil (point-max)))
+         (choice (buffer-substring-no-properties obeg oend)))
+
+    (when completion-highlight-candidate
+      (move-overlay completion-overlay obeg oend)
+      (minibuffer-completion-set-suffix choice))
+
+    ;; Return the current completion
+    choice))
+
+(defun previous-completion (n)
+  "Move to the previous N item in the completion list see `next-completion'."
+  (interactive "p")
+  (next-completion (- n)))
+
+(defun next-line-completion (&optional arg try-vscroll)
+  "Go to completion candidate in line above current.
+With prefix argument ARG, move to ARG candidate bellow current.
+TRY-VSCROLL is passed straight to `line-move'"
+  (interactive "^p\np")
+  (line-move arg t nil try-vscroll)
+  (goto-next-completion 1)
+  (next-completion -1))
+
+(defun previous-line-completion (&optional arg try-vscroll)
+  "Go to completion candidate in line above current.
+With prefix argument ARG, move to ARG candidate above current.
+TRY-VSCROLL is passed straight to `line-move'"
+  (interactive "^p\np")
+  (next-line-completion (- arg) try-vscroll))
+
 (defun choose-completion (&optional event)
   "Choose the completion at point.
 If EVENT, use EVENT's position to determine the starting position."
@@ -8646,6 +8696,12 @@ completion-show-help
   :version "22.1"
   :group 'completion)
 
+
+(defun completions-highlight-completions-pre-command-hook ()
+  "Function `pre-command-hook' to use only in the minibuffer."
+  (move-overlay completion-overlay 0 0)
+  (minibuffer-completion-unset-suffix))
+
 ;; This function goes in completion-setup-hook, so that it is called
 ;; after the text of the completion list buffer is written.
 (defun completion-setup-function ()
@@ -8684,7 +8740,22 @@ completion-setup-function
 	    (insert "Click on a completion to select it.\n"))
 	(insert (substitute-command-keys
 		 "In this buffer, type \\[choose-completion] to \
-select the completion near point.\n\n"))))))
+select the completion near point.\n\n")))
+
+      (when (and completion-highlight-candidate
+                 (string= (buffer-name) "*Completions*"))
+
+        (set (make-local-variable 'completion-overlay) (make-overlay 0 0))
+        (overlay-put completion-overlay 'face 'highlight)
+
+        (add-hook 'pre-command-hook #'completions-highlight-completions-pre-command-hook nil t)
+        (add-hook 'isearch-mode-end-hook (lambda ()
+                                           (goto-next-completion -1)
+                                           (next-completion 1)) nil t)
+        (completions-highlight-completion-bindings t)))
+
+    (completions-highlight-minibuffer-complete-setup)))
+
 
 (add-hook 'completion-setup-hook #'completion-setup-function)
 

Re: vertical fido-mode (new branch)

[Juri Linkov]

> Could you please try the attached patch (where the mode is enabled by default).

Cool, now completions navigation is much easier than with anything else.

>>Easier can be only one thing: to use arrows and navigation keys to navigate
>>completions from the minibuffer.  So the main question is on what condition
>>to activate these keys (instead of allowing them to search in history)?
>>
> I enabled the keys only when the *Completions* buffer is shown and the
> highlight completions is active. And added a hook to remove the bindings
> when minibuffer-hide-completions.

Good.

> If this patch is too much code for adding in simple and minibuffer, I
> would try to make a separate file with a mode. WDYT?

Maybe initially this could be a separate package to allow easier
experimentation with it.  Later when it works well, this could be added
to core commands.

Re: vertical fido-mode (new branch)

[Ergus]

On Tue, Aug 25, 2020 at 09:55:41PM +0300, Juri Linkov wrote:
>
>> If this patch is too much code for adding in simple and minibuffer, I
>> would try to make a separate file with a mode. WDYT?
>
>Maybe initially this could be a separate package to allow easier
>experimentation with it.  Later when it works well, this could be added
>to core commands.
>

To do so I need two changes in the emacs core that can't be implemented
from outside.

1) The hook

-    (if win (with-selected-window win (bury-buffer)))))
+    (when win
+      (with-selected-window win (bury-buffer))
+      (run-hooks 'minibuffer-hide-completions-hook))))

Maybe there is a hook like bury-buffer-hook or something similar; but I
am not aware of it.  If so, then I could add my function in that local
hook in *Completions*. It is tricky, but it could work if we don't want
to add another hook. (But I would prefer having the hook)

2) The extra condition in completion--in-region-1

-            ;; If end is in view, scroll up to the beginning.
-            (set-window-start window (point-min) nil)
+            (if (and minibuffer-tab-go-completion
+                     (pos-visible-in-window-p (point-min) window))
+                (minibuffer-next-completion 1)
+                ;; If all completions are visible use tab completion
+              ;; If end is in view, scroll up to the beginning.
+              (set-window-start window (point-min) nil))

I think that we can modify this one to be more general using a funcall
or so and make my function to return t on success or nil if we should go
for the `else` part.

I can add these two small changes if you think they are fine.  If so,
then the package can be added as an extra file and I could avoid messing
up even more the simple.el and minibuffer.el. Even enabling the mode by
default (if we decide so) it could be in a different file for simplicity.

BTW I am implementing also a vertical icomplete.  I will upload a
feature branch in a while. Could you try that?

Best,
Ergus

Re: vertical fido-mode (new branch)

[Stefan Monnier]

> -    (if win (with-selected-window win (bury-buffer)))))
> +    (when win
> +      (with-selected-window win (bury-buffer))
> +      (run-hooks 'minibuffer-hide-completions-hook))))

When introducing hooks, often it's a good idea to try and think of
*replacing* rather than *adding*.  E.g. Maybe instead of running
`minibuffer-hide-completions-hook` after hiding the buffer, you want to
have a `minibuffer-hide-completions-function` which defaults to `bury-buffer`.

I'm not sure if it'd be better in this specific instance, but...

> -            ;; If end is in view, scroll up to the beginning.
> -            (set-window-start window (point-min) nil)
> +            (if (and minibuffer-tab-go-completion
> +                     (pos-visible-in-window-p (point-min) window))
> +                (minibuffer-next-completion 1)
> +                ;; If all completions are visible use tab completion
> +              ;; If end is in view, scroll up to the beginning.
> +              (set-window-start window (point-min) nil))

... I think here it might be a good idea: introduce
a `minibuffer-tab-through-completions-function` which by default would
do the scrolling, i.e.:

    (let ((window minibuffer-scroll-window))
      (with-current-buffer (window-buffer window)
        (if (pos-visible-in-window-p (point-max) window)
            ;; If end is in view, scroll up to the beginning.
            (set-window-start window (point-min) nil)
          ;; Else scroll down one screen.
          (with-selected-window window
	    (scroll-up)))
        nil)))

and which you could override to your liking.

> I think that we can modify this one to be more general using a funcall
> or so and make my function to return t on success or nil if we should go
> for the `else` part.

This makes me think maybe you were thinking exactly the same and we're
just in violent agreement.


        Stefan

Re: vertical fido-mode (new branch)

[Ergus]

On Tue, Aug 25, 2020 at 07:42:23PM -0400, Stefan Monnier wrote:
>
>When introducing hooks, often it's a good idea to try and think of
>*replacing* rather than *adding*.  E.g. Maybe instead of running
>`minibuffer-hide-completions-hook` after hiding the buffer, you want to
>have a `minibuffer-hide-completions-function` which defaults to `bury-buffer`.
>
>I'm not sure if it'd be better in this specific instance, but...
>
Hi Stefan:

Yes I also thought that, but as there is the `completion-setup-hook`
called when the completions are shown I just thought in a `symmetric`
hook to call when closing.

In my opinion the hook here was just simpler. Also because the
bury-buffer runs inside a with-selected-window and the action I need are
in the minibuffer.

>
>... I think here it might be a good idea: introduce
>a `minibuffer-tab-through-completions-function` which by default would
>do the scrolling, i.e.:
>
>    (let ((window minibuffer-scroll-window))
>      (with-current-buffer (window-buffer window)
>        (if (pos-visible-in-window-p (point-max) window)
>            ;; If end is in view, scroll up to the beginning.
>            (set-window-start window (point-min) nil)
>          ;; Else scroll down one screen.
>          (with-selected-window window
>	    (scroll-up)))
>        nil)))
>
>and which you could override to your liking.
>
This is exactly what I did ;p thanks for the name cause mine was worst.

>
>This makes me think maybe you were thinking exactly the same and we're
>just in violent agreement.
>
>
>        Stefan
>
I have 2 questions:

1) Why the function needs to return nil if the return value of
completion--in-region-1 is not used anywhere so far?

2) What's the "canonical method" to add a keymap to the minibuffer (and
*Completions*) when enabling the mode but restoring it cleanly at the
end?

Is it possible to do something like push/pop a keymap to another?

I see we have inheritance for keymaps but maybe there is a simpler
method?

How can I restrict the mode-keymap to the minibuffer for example?

Thanks in advance,
Ergus

Re: vertical fido-mode (new branch)

[Stefan Monnier]

> This is exactly what I did ;p thanks for the name cause mine was worst.

Great minds think alike.

> I have 2 questions:
>
> 1) Why the function needs to return nil if the return value of
> completion--in-region-1 is not used anywhere so far?

IIRC the value can be used to decide whether completion took place or not.
It's mostly a left over from older completion code where this convention
was used to try various completions in turn.

> 2) What's the "canonical method" to add a keymap to the minibuffer
> (and *Completions*) when enabling the mode but restoring it cleanly at
> the end?

A minor mode?

> Is it possible to do something like push/pop a keymap to another?

You can do that too, e.g. use `current-local-map` to get the current
keymap, then `make-composed-map` to combine it with your new keymap,
then `use-local-map` to make that new composed keymap be the keymap to use.

For pop, it can be a bit trickier if you want to be careful and handle
interaction with other packages doing similar things, but it's not
too bad.

You can look at `internal-push-keymap` and `internal-pop-keymap`
for inspiration.  Maybe we could clean those up and promote them out of
the "internal-" namespace.

> How can I restrict the mode-keymap to the minibuffer for example?

Not sure what you mean by that.


        Stefan

Re: vertical fido-mode (new branch)

[Ergus]

Hi Juri:

There is a new branch with the modifications either in minibuffer.el and
the new file. I followed the recommendations from Stefan and any
suggestion (including names) is very welcome.

Please try that and check if everything is fine to merge into master. I
would like to enable this by default in emacs 28, but going into that
discussion will take maybe 10 years.

On Tue, Aug 25, 2020 at 09:55:41PM +0300, Juri Linkov wrote:
>> Could you please try the attached patch (where the mode is enabled by default).
>
>Cool, now completions navigation is much easier than with anything else.
>
>>>Easier can be only one thing: to use arrows and navigation keys to navigate
>>>completions from the minibuffer.  So the main question is on what condition
>>>to activate these keys (instead of allowing them to search in history)?
>>>
>> I enabled the keys only when the *Completions* buffer is shown and the
>> highlight completions is active. And added a hook to remove the bindings
>> when minibuffer-hide-completions.
>
>Good.
>
>> If this patch is too much code for adding in simple and minibuffer, I
>> would try to make a separate file with a mode. WDYT?
>
>Maybe initially this could be a separate package to allow easier
>experimentation with it.  Later when it works well, this could be added
>to core commands.
>