bug#6076: 23.1.96; [PATCH] rcirc-complete for nicks and commands

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> I guess the right solution is to improve completion-at-point so that it
>> can be told to use cycling (the functionality is already provided by the
>> minibuffer-force-complete command).
> `flyspell-auto-correct-word' (bound to M-TAB) that cycles through
> completions could use this as well.

Even more so, yes, because the choice between completion and cycling
is not just a preference for this one.

>> This relates to a larger question: how to provide "in-buffer" the
>> variety of completion commands seen in minibuffer completion.
>> I.e. minibuffer-completion-help, minibuffer-force-complete,
>> minibuffer-complete-word, icomplete-mode, ...
> Is the problem in the implementation of these commands or in choosing
> key bindings for them available for "in-buffer" completion?

I'm not sure.  We could try and provide key bindings for all those
commands, but that would seem close to impossible: we're talking about
keybindings that would mostly need to be very short (single-key) to be
worthwhile, and we really don't have that many single-key available.

So, I see it as an implementation problem where we want to make
in-buffer completion modal to some extent: when in-buffer completion is
started you'd be put into a new "mode" (kind of like isearch, I guess),
where new completion commands become available.  The main problem is
how/when to leave this mode (it should be as seamless as possible).
Some other reason for such a change: we want to be able to run code when
completion is finished, e.g. to hide the *Completion* buffer.


        Stefan