[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8890: 23.3; message writing slows emacs

From: Dave Abrahams
Subject: bug#8890: 23.3; message writing slows emacs
Date: Sat, 17 Sep 2011 02:23:05 -0400
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (darwin)

on Sat Sep 17 2011, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:

> Dave Abrahams <address@hidden> 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.

Technically, that 100th of a second could be arbitrarily long:

,----[ (info "(elisp)Timers") ]
|    Emacs cannot run timers at any arbitrary point in a Lisp program; it
| can run them only when Emacs could accept output from a subprocess:
| namely, while waiting or inside certain primitive functions such as
| `sit-for' or `read-event' which _can_ wait.  Therefore, a timer's
| execution may be delayed if Emacs is busy.  However, the time of
| execution is very precise if Emacs is idle.

However, that might not be such a bad thing.

Dave Abrahams
BoostPro Computing

reply via email to

[Prev in Thread] Current Thread [Next in Thread]