Re: Interactive guide for new users

[Dmitry Gutov]

On 13.09.2020 05:35, Ergus wrote:

> > To my knowledge, if we want to come close to what those other editors 
> > show, our current best bet is icomplete-vertical (or something similar 
> > to it)
>
> I think that "something similar" is ivy+counsel.

Indeed. icomplete and Ivy are fairly close in visual appearance, with 
icomplete being closer to "stock" experience, that's why it would be my 
#1 pick, but Ivy can be a good choice.

> It works pretty fine,
> lighter than helm and it is in elpa. The api engine is very polished and
> the experience in general is better than with icomplete because it also
> has integrated all the completion engines, sorting and formats in a
> modular way.

It does the latter through its own internal API IIRC, which I'm not 100% 
sure about, but it's not a deal breaker.

> > PLUS a packages that moves the minibuffer to either the center or the 
> > top of the frame (or makes it seem live the minibuffer has been moved, 
> > of course).
> ivy-posframe also offers this with the ivy engine. I already wrote to
> the author to move it to elpa and he is asking the contributors if they
> have all the gnu documentation. (He already has as he is the author of
> posframe and company-posframe)

Indeed, it's kinda weird to have both posframe and ivy in ELPA, but not 
posframe-ivy. Which will be required for the experience we are probably 
looking for.

You should try maple-minibuffer, though. It might be easier to get it 
in, with just one author.

> The only drawback is that posframes does not work in a terminal
> interface as company do... (I totally ignore that's the difference
> between a posframe and a normal window)

And the other drawbacks that packages like maple-minibuffer have, like 
having to use fixed height, which shouldn't be necessary for a popup on 
top of the frame.

Those aren't huge problems, so if we managed to get this kind of 
behavior into the default set, and maybe even get more core devs to try 
to use it, it could result in something positive.

> Any way I think it is always better to have more than one option before
> deciding which one we will "officially" support.

No objections here ;-)