Re: Very interesting analysis of "the state of Emacs"

[Tom Tromey <tromey@redhat.com>]

>>>>> "Miles" == Miles Bader <miles.bader@necel.com> writes:

Miles> One thing I've heard a lot is that it's annoying to wait 5
Miles> minutes for gnus to finish reading in a huge group or
Miles> something.

I haven't seen 5 minute pauses since the bad old days -- faster
machines have made elisp look faster.

However, I do experience the occasional annoying pause when an nntp
server is down.  In cases like this it would be nice to have an
asynchronous gnus that connects in the background.

Also, blocking operations sometimes mess with other applications
running in Emacs.  E.g., if blocked too long ERC seems to time out its
connection to irc servers.

Miles> Of course Gnus could be rewritten to do potentially lengthy stuff in the
Miles> background (and that's what usually happens with such things ... e.g.,
Miles> "M-x man"), but it's probably not easy, and in many cases not even
Miles> desirable -- when the wait is short, I think it's less confusing for the
Miles> user for such actions to be synchronous.

My ideal is that no Emacs operation be allowed to block Emacs for
"very long" (like, less than 1 second would be nice).

It is easy to make an async operation look like it is blocking, if
that is desirable.  However, in general I think it probably is not.  I
rather like how M-x man works, or async vc-diff or vc-annotate, and I
don't think they are super confusing to the new user.

So, instead of having "g" in gnus block Emacs entirely, it could
simply block operations in the *Group* buffer and present a message
somewhere saying what is happening.

Tom