Re: Shrinking the C core

[Arthur Miller]

Ihor Radchenko <yantar92@posteo.net> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Instead of denigrating the C language, Emacs's C core, and so many other
>> components critical to Emacs that have been subject to unjustified
>> invective in recent times, why not direct your attention to a more
>> productive task, such as identifying the complex interdependencies
>> between different pieces of Emacs's global state to establish a detailed
>> plan for their interlocking?  For this task, the most important tool is
>> a control-flow visualizer such as cflow, and an ample supply of paper.
>
> And we tried to dig into this question in
> https://yhetil.org/emacs-devel/871qhnr4ty.fsf@localhost/
> At least, the task does not look impossible.

That was a long thread to say mildly :) I don't have time to read all
that, but thanks for the pointer. To answer shortly.

Po has narrowed this to be a discussion about threading only, which
certainly wasn't my intention; I see it as an important part, but there
are other importnat aspects which would benefit Emacs than just
multithreading.

I generally agree with you, even with Po; I think it is possible in some
way, I never said it is impossible to rework Emacs.

For example if we could instantiate the interpretter on its own, with an
empty state, than you could perhaps run that in a separate thread, but I
am affraid everything is just one big state and would mean some
refactoring.

I am not sure if sitting and trying to puzzle pieces to interlock during
the execution as Po suggests is a very good idea. Again *anything* is
possible, but that sounds like a very tedious and error prone strategy
to me. I can't read the entire thread, there are tens if not 100s of
posts there, so I don't know what you have come up with.

However, my thesis was not that it is impossible to do in Emacs, but
that there is a lisp machine that already has figured out that work.