[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Juri Linkov
Subject: Re: Feature request : Tab-completion for 'shell-comand'
Date: Sun, 09 Mar 2008 19:45:43 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-unknown-linux-gnu)

>     > I have doubts that this is uniformly the best thing to do.
>     > I think that the best thing to do depends on the message:
>     > some messages are good to display at the end of the minibuffer,
>     > as in `minibuffer-message', and some are better just omitted
>     > while in the minibuffer.
>     Currently messages displayed when the minibuffer is active don't get
>     omitted.  They just obscure the minibuffer content from the user.
> The message I replied to showed an example of code that omits
> the message when the minibuffer is active.

Then I agree that if some messages are not important they should be
omitted while in the minibuffer (by using a condition that check if the
minibuffer is active before calling `minibuffer-message', or in `message'
if it will call `minibuffer-message').  Otherwise, a message should be
appended to the end of the minibuffer.  But I think messages should never
overwrite the content of the active minibuffer.

>     With the patch I sent (that changes `message' to call `minibuffer-message'
>     in the active minibuffer), Isearch in the minibuffer works mostly without
>     changes,
> I am surprised.  How does it do that?  If `message' calls
> `minibuffer-message', how come that doesn't cause all the isearch
> messages to appear after the minibuffer text?

This is due to the special function `minibuffer-history-isearch-message'
that doesn't call `isearch-message' if isearch is not failed.

If we will change `message' to call `minibuffer-message' in the active
minibuffer, then something like this could be implemented in a few
special cases where using `minibuffer-message' will be not desirable.

>            but there is a difference on failed Isearch: without this patch
>     the Isearch error message overwrites the minibuffer content, but with this
>     patch it appends the error message to the end of the minibuffer, e.g.
>     I-search backward: foo [Failing I-search backward: bar]
> I am not sure how to interpret that, because I do not know what foo
> and bar stand for.

The former is is the minibuffer content and the latter is the search string.
The complete workflow looks like:

1. Activate the minibuffer and type some text like "text":

Prompt: text

2. Type C-r and type a character "t":

I-search backward: text

The successful isearch highlights the found character "t".

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]

5. But currently it displays:

Failing I-search backward: search string

> But it cannot be right to have two isearch messages at once.
> Whether the search succeeds or fails, its message should be displayed
> in the same place, in the same way.

So it seems it would be better to leave its current behavior.

>     Otherwise, we could just fix this particular case not to use
>     `minibuffer-message'.
> If `message' automatically calls `minibuffer-message' when the minibuffer
> is active, how is it possible to fix one case not to do that?

We could add a condition to `message' to check for the value of
a variable like `minibuffer-message-timeout', and if it is nil
then don't call `minibuffer-message'.

Juri Linkov

reply via email to

[Prev in Thread] Current Thread [Next in Thread]