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

[Juri Linkov <juri@jurta.org>]

>>Yes, these messages overwrite the minibuffer, but instead of temporarily
>>redefining the function `message' as in shell-command.el, it would be
>>better to fix comint.el and shell.el to not display completion messages
>>when the minibuffer is active.  These files already contain places where
>>this check is done this way:
>
>> (unless (window-minibuffer-p (selected-window))
>>   (message "Completing file name..."))
>
> I think that such change will not work well based on two reasons.
> The first reason is that we will have to install the above change into
> all completion functions including functions added by users if you hope
> that this change works consistently.  Such great change must be very
> very difficult.  The second reason is that several completion functions
> will require a minibuffer to display their completing status.

That is why we should try to find a general solution.

> My solution employed in shell-command.el resolves these two problems.
> The first problem is resolved by re-defining `message' function.
> Re-definition of `message' function enables all tab-completion functions
> to call `message' function without ill effects.

As I see, your solution is just using a shorter delay for displaying the
message: 0.3 sec instead of 2 sec.  I think 0.3 sec is too short delay
to be able to read the displayed message.

> And more, the second problem is also resolved by this re-defined
> `message' function which uses a single minibuffer as two separated
> areas.  The re-defined `message' function uses the left half of
> minibuffer to display a regular prompt and uses the right half to
> display a completing status.

Displaying the message aligned to the right has the problem that it is
hard to notice when you look at the default left part of the minibuffer.
I use a wide frame and tried your command several times before I noticed
that something blinks for the short period (0.3 sec) on its right part.

> This trick is realized by the following code.  You can see that the
> re-defined `message' function concatenates a regular prompt and a
> completing status, and displays both of them.

Such workarounds like redefining the `message' function are not necessary
when installing code to the Emacs core, because we can change Emacs
internals in a general way to avoid similar problems in other places.

> I hope that you will try http://namazu.org/~tsuchiya/elisp/shell-command.el
> before further discussion.

Yes, I already tried it, thanks.

>>Also I see that shell-command.el changes the shell-command prompt.
>>I think this is a separate feature that is better to implement as
>>a minor mode that uses `minibuffer-setup-hook' to add shell-command
>>specific information to the created prompt.  Please see a mode like
>>minibuffer-electric-default-mode or file-name-shadow-mode for the ideas
>>how this could be implemented.
>
> I think that it is not a good idea to separate the tab-completion
> feature and the feature to display a current directory in a prompt.
> Users must know where they call commands with tab-completion, because
> almost all actions of tab-completion functions depend on the current
> directory.

Under a separate feature I meant that it should possible to turn it on/off,
and an ability to easily enable it also in other functions that use the
minibuffer to read commands.  I also appreciate that you implemented
the same prompt format specifiers as are used for shell prompts.

> I already signed a disclaimer for Gnus.

I hope our maintainers will answer your questions about papers.

> So, the simplest way is to merge necessary code of shell-command.el
> into simple.el and grep.el after I will sign a disclaimer for Emacs
> itself, isn't it?

I think merging necessary code into simple.el and grep.el would be the
best thing to do.

-- 
Juri Linkov
http://www.jurta.org/emacs/