RE: IDE

[Drew Adams]

> I agree, the Microsoft IDE looks slicker here, but the examples
> are basically the same, in that they use separate frames for
> the completion list and documentation, not the same one.

Whether separate frames are used or not is not so important.
It is important, though, to be _able_ to show the completions
without necessarily showing the help for the current one.
IOW, separate display can be useful, whether or not separate
frames are used for that.

The Icicles approach lets you show the complete help for the
current candidate (systematically or on demand), but it does
not mandate that.  It happens to use separate windows (or
frames), but that is not important here, IMO - the same effect
could be provided with a single frame.

Icicles also automatically (by default - option turns on/off)
shows short help in the mode line (of `*Completions*'),
systematically.  Maybe that's all you had in mind, a one-liner?

If so, then users would be missing the ability to show the
complete help for the current candidate (again, systematically
or on demand).  Being able to do that is a big help, IMO.

Summary:

1. Users should be able to show candidates without also the help.
2. Whether the same or separate frames or windows are used is
   not important.  (It could be important to a given user, and
   it could be made a user choice.)
3. For simple, one-liner reminder help, the mode-line suffices.
4. Users should be able to show the complete help for the current
   candidate.  One-liner help is no substitute for this.

> > The first part is just Emacs' style of doing things: we usually
> > enter stuff in the minibuffer, so it makes sense for completion
> to display
> 
> A lot of users are fine with that, but I think we should do better.

What is better, and why?  Please don't gloss over this.

I would not argue that minibuffer input is always better than other
methods (e.g. at-point cycling).  But it has different pros & cons.

In particular, (1) it allows actual (and complete) editing, and
(2) it provides its own keymap, for completion features or cycling
features or candidate-action features.  (And users can easily
customize that keymap.)

Those are pros.  A con is that the minibuffer and `*Completions*'
are not necessarily displayed close to point.  That's a display
question that could be addressed in various ways.

> You'd think so, but displaying the docstring automatically, like
> Auto-Complete does (as well as certain IDEs), has been a common
> request for a while. And now, https://github.com/expez/company-
> quickhelp is pretty popular.

Does it display the complete doc string?  If not, I'd say users
are missing out.  If yes, and this is done systematically, I'd
say that users are being force-fed.  They should have a choice.

For systematic display (but it should still be "offable"),
one-line help is fine.  But it's not a replacement for being
able to see the whole doc string.