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

[Paul Michael Reilly]

Stephen Eilert wrote:
> Richard M Stallman wrote:
> >     The other hard problem is multi-tasking in the Emacs Lisp engine.
> >     RMS once left me with the impression that this was virtually
> >     intractable, especially if one wanted to have existing Elisp code 
> > base
> >     compatibility, a reasonable thing to want.
> >
> > I think "intractable" might be too pessimistic.  It is certainly
> > a lot of work, but someone could give it a try.
> >
> >
> >   
> Before diving in the merits of whether or not it is possible to add 
> multi-tasking to Emacs (by that I assume full-blown threads), what are 
> the problems this is trying to solve?
>
> Is it to add background processing (as in, file indexing, background 
> compilation, downloads and the like)? If then, a notion of task 
> priorities could be discussed. For instance, Eclipse knows that, in 
> order to deploy an application, it must be compiled first. It 
> understands that those tasks cannot happen in parallel and should be 
> queued. On the other hand, you can start downloads (usually, plugins and 
> updates for said plugins) right away.
>
> It could be a way to use the increasing amount of available processing 
> cores in personal computers. Then again, Emacs doesn't seem like a 
> particularly CPU-bound application.
>
> So I am at a loss why this is so important. Could someone clarify?

Over the years I've frequently encountered situations where I started 
executing some Elisp code that took longer than I expected.  Things like 
rgrepping and accessing the network where the network issues have Emacs' 
dedicated attention (and probably some more examples if I paid more 
close attention).  My first inclination was to start up another instance 
of Emacs and that was cool --- I now typically use half a dozen 
instances at any one time --- but it did occur to me that I was 
essentially running another Elisp engine, i.e. another thread.  So that 
was basically the reason why I had the conversation with Richard in the 
first place.  Much as I'd love to have multi-threading in Emacs it is 
way over my head, at least in any kind of reasonable timeframe.  Now 
fast forward to the era of multiple tabbed browsing, mostly firefox. 
Each tab is essentially a separate thread so if the holy grail of 
marrying multi-site browsing and Emacs is to be obtained some form of 
multi-threading seems intuitively required.  But if some wizard figures 
out how to get the grail with only a half a thread, that works for me. :-)

I think the main point is that those of us who feel annoyed every time 
we have to leave an Emacs frame to do some work can only get 
satisfaction from Emacs when it can do multiple of those things that now 
cause it prevent the User from doing something else inside of Emacs 
while it is cranking where it really doesn't matter whether the cranking 
is on the CPU(s) or in the I/O.

-pmr