RE: [External] : Re: discoverability, better defaults and which-key in Emacs

[Drew Adams <drew.adams@oracle.com>]

> > Not to distract, but FYI library `keysee.el' is
> > an alternative to which-key.  Less known, some
> > differences, maybe worth checking out.
> 
> The dependency on `sortie.el` is actually cumbersome,

Sortie is completely general - independent
of keysee (which depends on it).  Sortie
can be used to interactively sort candidates
for any kind of completion.

I think this sorting is important enough for
KeySee that it should require Sortie, not
make its use optional.

Of course, if Emacs already had Sortie or an
equivalent then no explicit requiring would
be needed by KeySee. ;-)

> `keysee.el` implements a totally non-intrusive
> mini-buffer completion for keybinding suggestions.
> 
> I remember using `which-key` and implementing
> golden-ratio to my windows, things messed up
> because `which-key` suggestions are in a
> proper window, thus potentially intrusive.
> One can fix this, as a lot of people do but if
> this is to be integrated into core Emacs one
> needs to take care of that.

That's indeed another difference.  I'm
likely less aware of all the differences
because I don't use which-key. ;-)

(I don't use KeySee either, in fact.  I
use Icicles.  KeySee is actually a
reduced-functionality version of Icicles
key completion.)

The main difference from which-key is
no doubt that KeySee completes against
key _names_ (and their command names, as
I mentioned), and not keystrokes
themselves.

This means that you type text to complete
key names, instead of hitting those keys
themselves.

[As a shortcut, `M-q <keystroke>' inserts
the name of <keystroke>, so you can get
almost the same effect as which-key, when
you want that.  It would be possible/easy
to even obviate needing to hit `RET', but
I haven't added that option (except in
Icicles).]

KeySee is thus a bit less just-hit-keys
and a bit more of a discover-and-explore
feature.

In particular, this means you can, any
time, fully explore the entire domain of
keys available at that time (current
context).

You can always, for example, _backtrack_,
that is, go back up from wherever you are,
down inside a sequence of prefix keys.
E.g., after getting down into `C-x 4' you
can go back up to completing just `C-x'.

And then you can go back down again, or
down another prefix key's branch (e.g.
`C-x 8'), etc.

You go up by using the always-available
(except at top level) special completion
`..', that is, you type `..' to go back
up from completing a prefix key.

The domain of "keys" available includes
the forest of menu-bar menus.  So you can
use KeySee to explore those as well.  And
a separate command, `kc-complete-menu-bar'
does _only_ that: complete menu-bar menus.

> Honestly, I believe if we can just add it
> as a part of the customizable UI then it'd
> be great. Just like we have `ido-completion`,
> or the ability to have menu items on the GUI,
> we can add a keybinding completion system
> and put it on the manual. People should
> discover it from Emacs Manual, as they
> discover other things such as customizing
> the UI. Making such features immediately
> visible to the user is a complex problem to
> solve, which can't be solved right away.
> But a feature like this _can_ be implemented
> and should be alongside the discussion on
> discoverability and what 'defaults' Emacs
> should be shipped with.

The use of KeySee features is, and should be,
optional.  You turn them on/off using minor
modes.

As for inclusion of KeySee & Sortie in Emacs,
I should say that I don't particularly want
to develop/maintain them in/for Emacs.  If
someone wants to do that, they can do so.
They're tiny libraries.