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).