Suggestions for improvements to the *Completions* buffer

[Philip Kaludercic]

Hi,

I'd like to suggest a few modifications to the default behaviour of
the *Completions* buffer.  These are mostly conservative extensions of
the current defaults.

Currently, next-completion (and previous-completion) stops at either the
end or the beginning of a buffer.  This patch would allow for the
command to also wrap around, and if the end has been reached to jump
back to the beginning.  In my experience, the improvement is most
noticeable when choosing between a small number choices, and pressing
tab twice is easier than shift-tab.

Optionally, this could also be extended to only enable cycling when
there are less than n options to select from.

0001-Allow-for-next-completion-to-wrap-around-the-complet.patch
Description: Text Data

Currently, as soon as the minibuffer cannot expand the completion any
further, tab becomes a noop and the user is caught in a state that they
have to exit with some other command (M-v, C-g, ...).  Again, just like
above, I prefer to stay on the same key, so this patch introduces a user
option to automatically switch to the completion buffer, as soon as it
pops up, to just "tab on".

0002-Allow-for-the-completion-buffer-to-be-automatically-.patch
Description: Text Data

When exiting the *Completions* buffer, C-g and q seem not to send the
user back to minibuffer.  This introduces friction via uncertainty,
because you don't know where the active point will land, so you have to
manually switch back.  This command adds and binds command that ensure
the minibuffer is always selected once it is closed or unfocused.  I
think this is an absolute improvement, so there is no option to reset
this behaviour.

0003-Switch-back-to-minibuffer-when-quitting-completion-b.patch
Description: Text Data

In the *Completions*, self-insert-command is not bound so that "q", "n",
"p", "z", ... can be used.  This patch would add "s" (for
isearch-forward) and "S" (for isearch-forward-regexp) to the default
bunch.  This is my most recent change, that I am least certain about.
If I played around with it for a bit longer, maybe this could also be
extended to an interactive narrowing along the lines of icomplete.

0004-Bind-modifier-less-isearch-commands-in-the-completio.patch
Description: Text Data

So, any opinions on these suggestions?  I get the impression that many
people avoid the default completion system because of small
peculiarities such as the ones I describe above.  Protesilaos Stavrou's
recent library MCT (https://gitlab.com/protesilaos/mct) demonstrates
that it doesn't take much to fix these issues, but I think that the
above already does a lot, with a lot less code (mostly because this is
not a package).

-- 
        Philip Kaludercic