[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [External] : Re: Shrinking the C core
From: |
Arthur Miller |
Subject: |
Re: [External] : Re: Shrinking the C core |
Date: |
Thu, 14 Sep 2023 13:53:00 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Eli Zaretskii <eliz@gnu.org> writes:
>> 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.
Sory if it came out as a tirade, it answer on the mail before, your
thoughts in that mail, and also me complaining about some persons taking
very much freedom in how they talk to or about me, and when answered
back I am threatened to be blocked from here. It perhaps should have
been three mails instead of one, sorry if it is too diffused or
confused, it was the intention to be rude to you.
> 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.
Well you can; but you didn't.
I am forced to change the mailing list while other people are not, and I
am told to "dropp of" and "watch my mouth or risk to be blocked (I
believe what he meant)" while called "for lazy idiot" becaue of bringing
up what someone found uncomfortable to talk about, and I don't see that
person being threaten the way I am; and I am not able to bring that up,
than I guess I am not welcome here.
- RE: [External] : Re: Shrinking the C core, Drew Adams, 2023/09/13
- Re: [External] : Re: Shrinking the C core, Arthur Miller, 2023/09/14
- Re: [External] : Re: Shrinking the C core, Emanuel Berg, 2023/09/15
- RE: [External] : Re: Shrinking the C core, Drew Adams, 2023/09/15
- Re: [External] : Re: Shrinking the C core, Emanuel Berg, 2023/09/16
- RE: [External] : Re: Shrinking the C core, Drew Adams, 2023/09/16
- Re: [External] : Re: Shrinking the C core, Emanuel Berg, 2023/09/17
- Re: [External] : Re: Shrinking the C core, Yuri Khan, 2023/09/17
- Re: [External] : Re: Shrinking the C core, Emanuel Berg, 2023/09/17