emacs-tangents
[Top][All Lists]
Advanced

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

Re: A simple(perhaps dumb) idea for a more responsive emacs


From: Barry Fishman
Subject: Re: A simple(perhaps dumb) idea for a more responsive emacs
Date: Thu, 05 Oct 2023 08:49:20 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

On 2023-10-04 19:21:36 +02, Emanuel Berg wrote:
> joakim wrote:
>
>> - You have a single Emacs instance, you do everything in it,
>>   but you get sad when a long running operation, in this
>>   case Gnus, or generating your Org agenda, takes a long
>>   time, and you have to wait.
>>
>> - You start 2 or three emacsen for different purposes, but
>>   then you get sad because you dont have the same state in
>>   all emacsen
>>
>> - You could have the main emacs communicate with the
>>   different special purpose emacs using some async option,
>>   and that would work, but this is a different idea
>>
>> - You could also use CRDT:s to communicate with the special
>>   purpose emacsen. There is a crdt emacs package already.
>>   In this case, mainly the gnus window gets replicated to
>>   the main emacs from the gnus emacs.
>
> Yes, this model of multiprocessing is called asymmetric as
> different processing units do dedicated, different things, and
> then communicate.
>
> One can certainly think of such a setup but I think for it to
> be really good it would have to be symmetric with transparent,
> automated scheduling over the cores which we leave to the OS,
> after speaking with Emacs.

It might be simpler to have a possibly slow operation be done in a
function call that is passed a list of buffers and two thunks, one to do
the slow operation and the other to update the buffers after the first
thunk completes.

If threading is not available, it would just perform the two thunks in
order.

Otherwise it would put the buffers in read-only mode, and spawn a thread
to do the slow operation and return.  When that thread completed, an
event would start second thunk which would update the buffers, and then
the original mode of the buffers would be restored.

This would allow a slow operation not to hold up the user from doing
anything except changing the effected buffers.  It would still let the
buffer and screen update happen in the appropriate threads, which might
be limited by the window system being used.

-- 
Barry Fishman




reply via email to

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