Re: [External] : Re: Shrinking the C core

[Arthur Miller <arthur.miller@live.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> [Redirected to emacs-tangents]
>
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Richard Stallman <rms@gnu.org>,  Drew Adams <drew.adams@oracle.com>,
>>  arthur.miller@live.com,  acm@muc.de,  luangruo@yahoo.com,
>>  emacs-devel@gnu.org
>> Date: Tue, 12 Sep 2023 06:38:00 +0200
>> 
>> "Eric S. Raymond" <esr@thyrsus.com> writes:
>> 
>>  > But it could be done. There is a technical path forward to it.
>> 
>> Which would have to cope with buffer-local bindings.
>
> Right.  And the display code.  And text en/decoding.  And input queue.
> And faces.  Etc. etc. -- these are all written in C, but are full of
> Lisp data structures and calls into Lisp, so separating them is
> anything but easy or even straightforward.
>
> People who have enough talents, knowledge, and energy to do this kind
> of job will be better off, and will serve the community better, if
> they design an Emacs differently, taking into consideration the main
> lessons we've learned.

I don't know what you have learned, but I have learned that Guy Steel
was correct when he told the world back in 1998 already: don't really on
a few people for the development, instead make things extensible by
the users. In an applicaiton that is almost a life style for many users
and where most of users are developers as well it makes sense to use the
same implementation and extension language, because it removes a barrier
for design and experimentation. For web developers it might make sense
to write their tools in JS, for Lisp developers it make sense to use
Lisp for their tools. That would make for more sustainable development.

> lessons we've learned.  That "neo-Emacs" could have a mode whereby it
> worked in a way compatible with the current Emacs, so that people who
> must run the old applications could run them without changes.  But it

Such a "mode" would still require you to implement al that stuff you
have now, there is no way around, and I am quite sure you know it.

Also; there is nothing that says that you can't have different
implementation under the hood. There is so much narrow-mindedness and
assumptions from you. Instead of assuming bunch of what I think or don't
think, as you always do, why don't you just ask me? I didn't answered
further in our private correspondence because of your constant assuming
what I think or don't think and so on. Ask me instead; if I haven't think
of something, or thought wrong, I'll be glad to learn about it.

> should be based on different, more modern architectural decisions.
> Handling of buffer text, GC, the display engine, threads -- all these
> and more needs to be rethought and preferably replaced with more
> modern solutions, to avoid bumping into the same limitations right
> from the get-go.

Yes, and what in your opinion *is* a suggestion to completely remove the
C code, which actually was a very relevant in a thread about shrinking
the C core? Also, to answer all those who can't put 1 + 1 togther by
themselves: I have suggested to remove completely C core in a thread
about shrinking the C core. I think a "maximal shrink" of C core is
quite on topic :-).

About your "neo-design", just implementing the editor in a Lisp machine
instead of having a Lisp machine in the editor is itself already a
radical design change. Not to mention that the Lisp machine suggested
already has threading and some other tools that would make life much
easier so you could concentrate on actually improving the editor instead
of the Lisp machine. Look at other similar applications already doing it
in that "clumsy" CL; Lem already has several rendering backends. How
many do you have?

Nobody says that you have to implement stuff under the hood the same
way; I have said we need C core and elisp semantics implemented in
CL. It is laborous but possible. Under the hood it could be implemented
with any changes needed, and in the future design could be exchanged for
something else, complemented etc.

Anyway, your rhetorics give allusion that Emacs is dead, users should go
to greener pastures you who want something more modern dead suites their
needs. I don't know, but those are vibes I get from your arguments.

Anyone can *already* use other "more modern applications". Reason users
don't use Hemlock or Climax or don't rush to Lem (perhaps they should)
is, as we have already discussed in private and Reddit, because they
can't run Emacs packages in them. People don't want Emacs-like editor,
they want GNU Emacs. Which is good, and which you are aware of from both
private discussion and Reddit. Sure, loosing *some* applications is OK,
there is a natural regression too, some things are not maintained or get
irrelevant for other reasons, but not all.

Another thing is your way to talk to people and keep this community; I
was told I am a lazy idiot who came here to beg someone to write
something for me, and I am told to watch my mouth when I answered. Great
community you are maintaining, thank you for that.