Re: Feature request : Tab-completion for 'shell-comand'

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

> I have just prepared the minimized patch to support tab-completion
> features for `shell-command' etc.  It is attached at the end of this
> message.  Because several users do not want to see the current
> directory, the default values of prompt options do not contain
> %-sequences.

Could you provide a new version of your patch without the
make-shell-prompt-string?  I'm not sure whether make-shell-prompt-string
is a good idea or not, but in any case I'd rather keep it as a separate
question (same thing with the introduction of all those *-prompt
defcustoms).  Also I note that it's used in *every* call to
read-shell-commmand, so it would be better to place just a single call
to it directly inside read-shell-commmand.

Also, please remove the `keymap' argument to read-shell-commmand since
it's not used anywhere.  In turn this will allow you to move the
construction of the keymap out of the function into a variable
read-shell-command-map where users will then be able to customize it to
use pcomplete, for example.

Try to avoid interactive anonymous functions, so just give it a name
like minibuffer-complete-shell-command.

Finally, using `defun' within another function is a bug in 99.99% of
the cases.  This case is not an exception.  Such tricks, similarly to
using defadvice, are fine for external Emacs packages who want/need to
work with existing Emacs releases, but we're lucky enough to be in
a position to change the rest of Emacs, so we don't need such things:
just change the comint completion code so that it works well when used
in the minibuffer.

>> However, I still don't see a solution for the problem how to display
>> the message (such as "[Completing command name...]") without a delay,
>> and leave it visible to the user persistently without interfering with
>> the user input.

Why would you want to?  This message is not particularly important, as
far as I can tell.  All it says, basically is "yeah I did get your key
press and it was bound to the command you thought".

I suggest to only display it if the minibuffer is not active (I'd even
happily remove it altogether, but at least when the minibuffer is
inactive the message is pretty harmless, so I don't mind keeping it).


        Stefan