GNU bug report logs - #8890
23.3; message writing slows emacs

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: dave <at> boostpro.com, 8890 <at> debbugs.gnu.org
Subject: bug#8890: 23.3; message writing slows emacs
Date: Sat, 17 Sep 2011 11:25:10 +0300

> From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
> Date: Sat, 17 Sep 2011 07:19:56 +0200
> Cc: 8890 <at> debbugs.gnu.org
> 
> `message' could work as follows:
> 
> If it's been less than (say) 50th of a second since the previous
> message, then don't message anything.  However, set up a timer in a
> 100th of a second's time to display that message -- if nothing else has
> been displayed in the mean time.

As I wrote earlier, `message' is the wrong place to fix this kind of
problems: it doesn't have enough context to decide whether or not it's
TRT to skip a message.  A Lisp program that calls `message' could have
good reasons to do this; not displaying those messages violates the
principle of least surprise.

The right place for applying this logic is in the Lisp program that
calls `message'.

> The net effect will be that normal messaging (where it's been a long
> time since the previous message) is displayed as usual, but when we
> enter a "high-message" storm, we start skipping messages.  But we always
> end up showing the final message, anyway.

You are assuming that the final message is the only one that counts.
Undoubtedly, there are use cases where this is correct.  But there are
others where it will be wrong, and `message' will not be able to
second-guess its callers well enough to know which one is true.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.