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

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

[joakim]

Hello,

Theres been a lot of talk about multi core emacs etc, and thats nice and
all, but difficult to do.

So another idea is this:

- 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.

You could presumably use the crdt for replicating lisp structures,
not just the buffer. A crdt is just a data structure after all.

Anyway, just tossing out an idea.
-- 
Joakim Verona
joakim@verona.se

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Emanuel Berg]

joakim wrote:

> Theres been a lot of talk about multi core emacs etc, and
> thats nice and all, but difficult to do.
>
> So another idea is this:
>
> - 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.
>
> You could presumably use the crdt for replicating lisp
> structures, not just the buffer. A crdt is just a data
> structure after all.
>
> Anyway, just tossing out an idea.

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.

-- 
underground experts united
https://dataswamp.org/~incal


---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Barry Fishman]

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


---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Eli Zaretskii]

> From: Barry Fishman <barry@ecubist.org>
> Date: Thu, 05 Oct 2023 08:49:20 -0400
> 
> 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.

Making buffers unwritable while the slow operation runs is probably
problematic, as it doesn't allow the user to keep working on the
buffer while the operation runs.

> 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.

Displaying a buffer sometimes modifies the buffer (via font-lock).

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Barry Fishman]

On 2023-10-05 19:24:51 +03, Eli Zaretskii wrote:
> Making buffers unwritable while the slow operation runs is probably
> problematic, as it doesn't allow the user to keep working on the
> buffer while the operation runs.
...
> Displaying a buffer sometimes modifies the buffer (via font-lock).

Yes.

I was just looking for a simple common interface that would:

 * Encapsulated common code to reduce code duplication.  Avoid platform
   specific handling such as systems without threads.

* Handle simple cases simply.  It may be that the locking buffers is not
  generally helpful.  It probably isn't, but if it were, programmers
  could pass an empty list of buffers, or release the buffers when they
  were ready to update them.

* Provide a common function (grep-able) so that the implementation
   could change with time.

I was just suggesting that rather that waiting for some global solution
to be found, a less complex approach be considered in the mean time.
Where "pain points" could be considered a case by case basis, but still
provide a common mechanism to use.

-- 
Barry Fishman


---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Eli Zaretskii]

> From: Barry Fishman <barry@ecubist.org>
> Date: Thu, 05 Oct 2023 17:34:01 -0400
> 
> I was just suggesting that rather that waiting for some global solution
> to be found, a less complex approach be considered in the mean time.
> Where "pain points" could be considered a case by case basis, but still
> provide a common mechanism to use.

See, I'm not sure even this suggestion (that is already rather radical
in its implications) will do.  Because, apart of buffers, we have the
rest of the huge global state in Emacs, and Lisp programs are quite
cavalier in relying on that, and there's a rare Lisp program in Emacs
that doesn't access that global state in some way.  Something needs to
be done about that as well.

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Barry Fishman]

On 2023-10-06 07:54:49 +03, Eli Zaretskii wrote:
>> From: Barry Fishman <barry@ecubist.org>
>> Date: Thu, 05 Oct 2023 17:34:01 -0400
>>
>> I was just suggesting that rather that waiting for some global solution
>> to be found, a less complex approach be considered in the mean time.
>> Where "pain points" could be considered a case by case basis, but still
>> provide a common mechanism to use.
>
> See, I'm not sure even this suggestion (that is already rather radical
> in its implications) will do.  Because, apart of buffers, we have the
> rest of the huge global state in Emacs, and Lisp programs are quite
> cavalier in relying on that, and there's a rare Lisp program in Emacs
> that doesn't access that global state in some way.  Something needs to
> be done about that as well.

[My ideas seem to fit well into the subject's simple (perhaps dumb)
category.  I hope I haven't outwore your patience.]

It would seem that "global state" is the thing that needs to be
dealt with first, when it comes to any thread based approaches in Emacs.

I was trying to start top down, identifying the "pain points",
and syntactically breaking them into a backgroundable, and
non-backgroundable parts.  It seems that approach can't work.

Alternative one can look at things bottom up, and propagate changes in
parts of the global state up the call stack.

In many languages that is done using an asynchronous function and
signaling protocol.

Implementing something like this in Emacs, and in a staged manner that
doesn't break existing code is something I would not propose without
doing a lot more thought and some actual example coding.

-- 
Barry Fishman



---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)