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

[Juri Linkov]

>     This is due to the special function `minibuffer-history-isearch-message'
>     that doesn't call `isearch-message' if isearch is not failed.
>
> Is that in the trunk only?

Yes, this is in the trunk only.

>     3. Type a search string like "search string".
>     When isearch fails, it will display using `minibuffer-message':
>
>     I-search backward: text [Failing I-search backward: search string]
>
> I don't think that is desirable output.
>
>     5. But currently it displays:
>
>     Failing I-search backward: search string
>
> Perhaps failing searches should continue displaying that.
> I am not sure what is best for them  to display, but we should
> not let that decision be forced by limited behavior of `message'.
> We should choose the output we want, and make sure we have primitives
> that can display it.
>
> Perhaps we should change `message' should be changed to act like
> `minibuffer-message', but then add a new function which continues to
> do what `message' does now.  Then isearch could use that.

A new function would be good if `minibuffer-message' worked well.
But unfortunately `minibuffer-message' is still unsatisfactory.
The main problem of `minibuffer-message' is that requires a delay 2 sec.
So for instance, when you call `dabbrev-expand' M-/ in the minibuffer,
it displays an unimportant message [Scanning for dabbrevs...] and then
waits.  When you do the same in a normal buffer, `message' doesn't wait.

One solution for `minibuffer-message' is to put an overlay at the end
of the minibuffer with the message and don't wait.  Any new call to
`minibuffer-message' could replace the message on this overlay shared
between several calls to `minibuffer-message'.  Any cursor movement
will remove it like cursor movements remove the message displayed
by `message'.  Would this work?

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