(Sorry for the longish delay, my webserver was down since
yesterday evening)
William XWL <[EMAIL PROTECTED]> writes:
>> It would probably be a good idea to just store the time the song
>> started, and show the playing time by calculating it from that -
>> timers aren't guaranteed to run as often as the repeat delay says.
>
> Calculating it now and then to update the playing time?
Daniel was right - just store the start time. When you have to
display the run time, you can use the difference between the
current time and the start time.
>> Imagine starting Gnus and sorting in some 20k mails or so :-)
>
> Hmm, Gnus seems to be the biggest headache for a timer,
Not at all - tramp has similar problems, or w3m while rendering a
big page, or ...
> why can't Gnus run asynchronically? because of elisp's
> constraints?
Yes. Emacs Lisp does not do real threads, so no concurrency. This
helps a lot, actually, since threads are very difficult beasts to
handle. There's an old discussion on whether Emacs should be
threaded or not. My position there is twofold. First, I think that
the introduction of threads would create more bugs than it would
bring features (Emacs Lisp just is not the right language for
useful concurrency abstractions like CML). Second, I recently came
upon a case where Emacs Lisp _does_ do concurrency, and that
should be removed.
To get back on topic, in the timer case, even threads wouldn't
help at all. Imagine a heavily loaded system. For your kind of
application, you would need a real time system. Not something you
use every day :-)
>> PS. Have you ent in your copyright assignment form? :-)
>
> Yes. I'm waiting for the really slow snail mail...
Great, same here. :-)
Greetings,
-- Jorgen
--
((email . "[EMAIL PROTECTED]") (www . "http://www.forcix.cx/";)
(gpg . "1024D/028AF63C") (irc . "nick forcer on IRCnet"))
_______________________________________________
Emms-help mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emms-help
