Re: Q on minibuffer-message

Re: Q on minibuffer-message

[Lennart Borgman]

As far as I can see it is a bug, at least in CVS Emacs. 
`minibuffer-message' uses temp_echo_area_glyphs in minibuf.c and that 
function calls

  Fsit_for (make_number (2), Qnil, Qnil);

which just sits for 2 seconds.

BTW `minibuffer-message' puts the string at the end of the current 
buffer which is not necessarily the minibuffer. Is not that a bug too?

--lennart


Drew Adams wrote:
> I have a command `foo' that calls `minibuffer-message' at various points.
>
> I want to call this function from another command, `bar', but I don't want
> the `minibuffer-message' display to wait for two seconds - I even don't care
> if it is displayed at all in this case.
>
> I could change the definition of command `foo', to pass it a flag to not
> call `minibuffer-message' (or to call it only when the command is called
> interactively), but I'd rather not have to resort to that.
>
> `minibuffer-message' displays its message for two seconds, unless an input
> event is received during this time. My question is: How can I inhibit the
> 2-second wait? Is there, for example, some way I can simulate an input
> event? Or is there a simpler, cleaner way?
>
> In command `bar', just after calling `foo', I tried (sit-for 0), to no
> avail. I tried adding a fake event (e.g. a character) to
> `unread-command-events', to no avail. I tried binding
> `minibuffer-message-timeout' (to nil and to 0), to no avail (it seemed to
> have no effect).
>
> Anyone have a suggestion?
>   

RE: Q on minibuffer-message

[Drew Adams]

    As far as I can see it is a bug, at least in CVS Emacs.
    `minibuffer-message' uses temp_echo_area_glyphs in minibuf.c and that
    function calls

      Fsit_for (make_number (2), Qnil, Qnil);

    which just sits for 2 seconds.

    BTW `minibuffer-message' puts the string at the end of the current
    buffer which is not necessarily the minibuffer. Is not that a bug too?

I don't know if those observations indicate bugs, and I'm not sure they're
related to my question. I'd just like to know how to inhibit or cancel the
2-second delay. I don't understand this enough to know if it is the presence
of bugs that prevents me from doing that. I'd like some input on what might
work (modulo bugs).

----
    Drew Adams wrote:
    > I have a command `foo' that calls `minibuffer-message' at
    various points.
    >
    > I want to call this function from another command, `bar', but
    I don't want
    > the `minibuffer-message' display to wait for two seconds - I
    even don't care
    > if it is displayed at all in this case.
    >
    > I could change the definition of command `foo', to pass it a
    flag to not
    > call `minibuffer-message' (or to call it only when the
    command is called
    > interactively), but I'd rather not have to resort to that.
    >
    > `minibuffer-message' displays its message for two seconds,
    unless an input
    > event is received during this time. My question is: How can I
    inhibit the
    > 2-second wait? Is there, for example, some way I can simulate an input
    > event? Or is there a simpler, cleaner way?
    >
    > In command `bar', just after calling `foo', I tried (sit-for 0), to no
    > avail. I tried adding a fake event (e.g. a character) to
    > `unread-command-events', to no avail. I tried binding
    > `minibuffer-message-timeout' (to nil and to 0), to no avail
    (it seemed to
    > have no effect).
    >
    > Anyone have a suggestion?
    >

Re: Q on minibuffer-message

[Richard M. Stallman]

    > I have a command `foo' that calls `minibuffer-message' at various points.
    >
    > I want to call this function from another command, `bar', but I don't want
    > the `minibuffer-message' display to wait for two seconds - I even don't care
    > if it is displayed at all in this case.

It is not useful to display a minibuffer message and not wait to give
the user a chance to see it.  The operation must normally wait.

Perhaps what you mean is that when foo is used from bar,
you see no reason for foo's messages to appear at all.

In that case, what I suggest is that you set up foo with an optional
argument that is provided as t when it is called interactively.  And
foo should only display its messages when that argument is t.

RE: Q on minibuffer-message

[Drew Adams]

        > I have a command `foo' that calls `minibuffer-message' at
        > various points.
        >
        > I want to call this function from another command, `bar',
        > but I don't want the `minibuffer-message' display to wait
        > for two seconds - I even don't care
        > if it is displayed at all in this case.

    It is not useful to display a minibuffer message and not wait to give
    the user a chance to see it.  The operation must normally wait.

    Perhaps what you mean is that when foo is used from bar,
    you see no reason for foo's messages to appear at all.

Yes, that's what I mean.

    In that case, what I suggest is that you set up foo with an optional
    argument that is provided as t when it is called interactively.  And
    foo should only display its messages when that argument is t.

That's just what I wanted to avoid having to do. From my original message:

    I could change the definition of command `foo', to pass it a flag to not
    call `minibuffer-message' (or to call it only when the command is called
    interactively), but I'd rather not have to resort to that.

    `minibuffer-message' displays its message for two seconds,
    unless an input event is received during this time. My question is:
    How can I inhibit the 2-second wait? Is there, for example, some
    way I can simulate an input event? Or is there a simpler, cleaner way?

    In command `bar', just after calling `foo', I tried (sit-for 0), to no
    avail. I tried adding a fake event (e.g. a character) to
    `unread-command-events', to no avail. I tried binding
    `minibuffer-message-timeout' (to nil and to 0), to no avail (it
    seemed to have no effect).

Re: Q on minibuffer-message

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sun, 22 Jan 2006 10:54:35 -0800
> Cc: 
> 
>     In that case, what I suggest is that you set up foo with an optional
>     argument that is provided as t when it is called interactively.  And
>     foo should only display its messages when that argument is t.
> 
> That's just what I wanted to avoid having to do. From my original message:
> 
>     I could change the definition of command `foo', to pass it a flag to not
>     call `minibuffer-message' (or to call it only when the command is called
>     interactively), but I'd rather not have to resort to that.

This doesn't explain why you wanted to avoid such a solution.

RE: Q on minibuffer-message

[Drew Adams]

    Drew> I could change the definition of command `foo', to pass it a
          flag to not call `minibuffer-message' (or to call it only when the
          command is called interactively), but I'd rather not have to
          resort to that.

  Eli> This doesn't explain why you wanted to avoid such a solution.

In fact, I have always planned anyway to modify `foo' in this way, because
my library needs to work also with Emacs 20, which has no
`minibuffer-message-timeout'. When I said that I wished to avoid such
modification, what I meant was that one should be able to avoid it.

  Ian> But why?  The argument can be optional, meaning if it's not
       given it will default to nil.  So there's no need to modify call
       sites in programs.

The concern was not needing to modify functions that call `foo'. The concern
was needing to modify `foo', the function that calls `minibuffer-message'.

The point is that it would be useful to be able to inhibit the action of
`minibuffer-message' from _without_, just as you can turn off logging of
messages in buffer *Messages* from without.

Imagine a scenario where you have no control over the definition of `foo'.
You simply want to use it, but not hear its `minibuffer-message' noise.
Binding `minibuffer-message-timeout' to 0 (or nil, or t, or whatever) should
let you do that. That's all.

Re: Q on minibuffer-message

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 23 Jan 2006 09:19:29 -0800
> Cc: 
> 
> The point is that it would be useful to be able to inhibit the action of
> `minibuffer-message' from _without_, just as you can turn off logging of
> messages in buffer *Messages* from without.

I'm not sure Emacs should cater to such a concern: a function that
calls `message' is clearly supposed to be invoked interactively, not
silently.

In other words, you are asking for a mechanism to subvert the intent
of the author of the function which calls `message'.

If a good reason presents itself to allow non-interactive invocation
of the function, a better solution would be rewrite it so that its
code is divided into two parts: one that is an internal
non-interactive function, the other an interactive wrapper.  Like
find-file and its subroutines, for example, or save-buffer and its.

> Imagine a scenario where you have no control over the definition of `foo'.
> You simply want to use it, but not hear its `minibuffer-message' noise.
> Binding `minibuffer-message-timeout' to 0 (or nil, or t, or whatever) should
> let you do that. That's all.

You have defadvice, which is an official way of committing such crimes
of uncleanness.

RE: Q on minibuffer-message

[Drew Adams]

    > Imagine a scenario where you have no control over the
    > definition of `foo'. You simply want to use it, but not hear its
    > `minibuffer-message' noise.  Binding `minibuffer-message-timeout'
    > to 0 (or nil, or t, or whatever) should let you do that. That's all.

    You have defadvice, which is an official way of committing such crimes
    of uncleanness.

Someone gives you a command that has maybe 10 or 100 possible calls to
`minibuffer-message' sprinkled throughout its execution tree. You're going
to use `defadvice' to try to slice and dice away the message appearances? Or
you're going to rewrite the command, so that it uses a non-interactive
helper function or accepts a flag that controls message appearance or tests
whether it was called interactively?

The original author intended it only as an interactive command, but you see
that you can use its functionality as is - you just want to inhibit its
messages.

    In other words, you are asking for a mechanism to subvert the intent
    of the author of the function which calls `message'.

Yes. It's far from atypical to reuse something in a way that was not
foreseen by the original author. Probably most reuse fits that description.

In any case, `minibuffer-message-timeout' apparently has no effect
whatsoever currently: a 2-second delay is apparently hard-coded. When that
is fixed, one can hope that a setting of 0 seconds will inhibit display.
Some will then use 0 for that purpose; others will prefer more official ways
of committing such crimes of uncleanness ;-).

Re: Q on minibuffer-message

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 23 Jan 2006 16:10:49 -0800
> Cc: 
> 
> Someone gives you a command that has maybe 10 or 100 possible calls to
> `minibuffer-message' sprinkled throughout its execution tree. You're going
> to use `defadvice' to try to slice and dice away the message appearances? Or
> you're going to rewrite the command, so that it uses a non-interactive
> helper function or accepts a flag that controls message appearance or tests
> whether it was called interactively?
> 
> The original author intended it only as an interactive command, but you see
> that you can use its functionality as is - you just want to inhibit its
> messages.

Are we talking about a well-written, clean function?  Or are we
talking about something that shouldn't have seen the light of the day?
I get the impression that I'm thinking mostly about the former, while
you have the latter before your mind's eyes.

If it's a badly written function, then yes, I'd rewrite it, or urge
the author to do so.

>     In other words, you are asking for a mechanism to subvert the intent
>     of the author of the function which calls `message'.
> 
> Yes. It's far from atypical to reuse something in a way that was not
> foreseen by the original author. Probably most reuse fits that description.

A well written code doesn't need to be subverted to be reused.

> In any case, `minibuffer-message-timeout' apparently has no effect
> whatsoever currently: a 2-second delay is apparently hard-coded.

That's a different issue, with a different solution.

Re: Q on minibuffer-message

[Richard M. Stallman]

	In that case, what I suggest is that you set up foo with an optional
	argument that is provided as t when it is called interactively.  And
	foo should only display its messages when that argument is t.

    That's just what I wanted to avoid having to do.

That's the right method, so I'm not interested in helping people avoid
it.