[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interactive guide for new users

From: Dmitry Gutov
Subject: Re: Interactive guide for new users
Date: Sun, 13 Sep 2020 03:01:42 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 12.09.2020 16:43, Eli Zaretskii wrote:
Date: Sat, 12 Sep 2020 15:18:02 +0200
From: Ergus <spacibba@aol.com>
Cc: ghe@sdf.org, casouri@gmail.com, emacs-devel@gnu.org

"Spirit" is not what's important here, IMO.  What's important is the
visual appearance and the available actions and their effects.  What I
see out there is similar to Company, and quite different from
icomplete-mode, even when augmented by the vertical sub-mode.

We have xref-find-apropos and completion-at-point. But icomplete use is
totally different to company.

icomplete is more a minibuffer completion engine useful while tipping
commands, of lookign for files. There a company panel is uncomfortable.

While company-mode is a "suggestion menu" while editing. Maybe our error
have been to consider both as a single "feature".

We are miscommunicating.  I said "similar to Company", meaning that
the completion drops down a vertical list of candidates that overlays
the rest of the display.  AFAIK, no existing completion package offers
something similar.

With a modest amount of work, Company could work in the minibuffer, as long as a frontend based on child frames is used (like company-posframe), `company-mode-on' is modified to allow operation inside minibuffer, and the minibuffer setup is altered to set completion-at-point-functions appropriately, so that Company knows which completions to offer.

That said, it would still be quite different from what VS Code, Atom and friends employ. See the attached screenshot for the Company-based example.

So either we implement something similar (and
offer it in that initial tour as an option), or we have to live with
the fact that users will not find in Emacs completion that they expect
to see.  In the latter case, I wonder why icomplete is deemed a step
in the right direction, for reasons I already described: it's too
complicated and confusion, IMO.

I don't see what's so complicated you see about icomplete-mode. If you have problems when trying to use it, perhaps you should ask questions?

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

Here's a showcase if one such package in action:


In particular, see the examples where the dropdown is displayed at the top and in the middle of the frame.

The package itself is here: https://github.com/honmaple/emacs-maple-minibuffer

There are already several packages that try to do something like this, but this one seemed the most stable last time I tried.

Even so, it has unfortunate limitations like not being able to adjust the height according to the number of available completions. And different features that use minibuffer are likely to expose other sharp corners of this (very impressive) hack. Like, some previous version of icomplete-vertial failed to work with it. The current seems to work fine, though.

So some low-level work/redesign of minibuffer code might be needed for this to be ready for wide public.

Relatedly, there exists a similar effort by out very own Martin Rudalics, but the discussion about polishing it has died down around here: https://lists.gnu.org/archive/html/emacs-devel/2020-06/msg00171.html

Previously: https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg03167.html

Attachment: Screenshot from 2020-09-13 02-23-00.png
Description: PNG image

reply via email to

[Prev in Thread] Current Thread [Next in Thread]