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

Previous Next

Full log

View this message in rfc822 format

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Dave Abrahams <dave <at> boostpro.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 8890 <at> debbugs.gnu.org
Subject: bug#8890: 23.3; message writing slows emacs
Date: Sat, 17 Sep 2011 07:19:56 +0200

Dave Abrahams <dave <at> boostpro.com> writes:

>> So the general approach to fixing those problems is to say "use
>> progress-reporter-update" since this function has the advantage of
>> knowing that there will be a `progress-reporter-done' at some later
>> point, which allows it to skip a message without worries.
>
> Hm.  So there *is* a builtin functionality for this... well, that's
> good.  Sorry if I've wasted everyone's time on this.

I didn't know about progress-reporter, so my time wasn't wasted, at
least.  :-)

But I wonder whether a simpler, more general function would be
possible.  If we're outputting stuff that's not a percentage,
progress-reporter doesn't help much.

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

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.

This would be a very simple interface for programmers to deal with
(i.e., "don't worry about it"), and the user wouldn't notice anything in
particular -- other than Emacs being faster in some situations.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Previous Next

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