From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: Q on minibuffer-message
Date: Fri, 20 Jan 2006 15:08:56 -0800 [thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICEELADBAA.drew.adams@oracle.com> (raw)
In-Reply-To: <43D16944.1020407@student.lu.se>
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?
>
next prev parent reply other threads:[~2006-01-20 23:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-20 19:23 Q on minibuffer-message Drew Adams
2006-01-20 22:50 ` Lennart Borgman
2006-01-20 23:08 ` Drew Adams [this message]
2006-01-22 17:44 ` Richard M. Stallman
2006-01-22 18:54 ` Drew Adams
2006-01-23 4:42 ` Eli Zaretskii
2006-01-23 5:11 ` Ian Zimmerman
2006-01-23 17:19 ` Drew Adams
2006-01-23 23:23 ` Eli Zaretskii
2006-01-24 0:10 ` Drew Adams
2006-01-24 4:28 ` Eli Zaretskii
2006-01-24 16:46 ` Richard M. Stallman
[not found] <mailman.1959.1137785275.26925.help-gnu-emacs@gnu.org>
2006-01-20 21:58 ` Stefan Monnier
2006-01-20 23:49 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DNEMKBNJBGPAOPIJOOICEELADBAA.drew.adams@oracle.com \
--to=drew.adams@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).