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

[Eli Zaretskii <eliz@gnu.org>]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>   esr@thyrsus.com,
>   rms@gnu.org,  drew.adams@oracle.com,  acm@muc.de,  luangruo@yahoo.com,
>   emacs-tangents@gnu.org
> Date: Tue, 12 Sep 2023 21:58:43 +0200
> 
> 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.

I don't know how to respond to this tirade, nor even where did it came
from and what did I do to deserve such rudeness.

I expressed my opinions on what would be a worthwhile "rewrite" of
Emacs.  Feel free to disagree with what I said, but why do you have to
mention my alleged "narrow-mindedness", or accuse me in making some
assumptions about what you think, or claim that I think Emacs is dead?
What I wrote was about Emacs and its future, not about you.  And no, I
don't think Emacs is dead, or I wouldn't be wasting my free time on
this job.

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

You are mistaken: I don't maintain this community.  I can barely tell
people to use kinder words, and even then they don't always listen.