unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: Q on minibuffer-message
Date: Mon, 23 Jan 2006 16:10:49 -0800	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICKEMMDBAA.drew.adams@oracle.com> (raw)
In-Reply-To: <u7j8qplzd.fsf@gnu.org>

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

  reply	other threads:[~2006-01-24  0:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87irsbo7et.fsf@gmail.com>
2006-01-23 17:19 ` Q on minibuffer-message Drew Adams
2006-01-23 23:23   ` Eli Zaretskii
2006-01-24  0:10     ` Drew Adams [this message]
2006-01-24  4:28       ` Eli Zaretskii
     [not found] <MEEKKIABFKKDFJMPIOEBIEJMCOAA.drew.adams@oracle.com>
2006-01-20 22:50 ` Lennart Borgman
2006-01-20 23:08   ` Drew Adams
2006-01-22 17:44   ` Richard M. Stallman
2006-01-22 18:54     ` Drew Adams
2006-01-23  4:42       ` Eli Zaretskii
2006-01-24 16:46       ` Richard M. Stallman

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=DNEMKBNJBGPAOPIJOOICKEMMDBAA.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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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