> From: Arthur Miller <arthur.mil...@live.com> > Cc: Gerd Möllmann <gerd.moellm...@gmail.com>, > e...@thyrsus.com, > r...@gnu.org, drew.ad...@oracle.com, a...@muc.de, luang...@yahoo.com, > emacs-tangents@gnu.org > Date: Tue, 12 Sep 2023 21:58:43 +0200 > > Eli Zaretskii <e...@gnu.org> writes: > > > [Redirected to emacs-tangents] > > > >> From: Gerd Möllmann <gerd.moellm...@gmail.com> > >> Cc: Richard Stallman <r...@gnu.org>, Drew Adams <drew.ad...@oracle.com>, > >> arthur.mil...@live.com, a...@muc.de, luang...@yahoo.com, > >> emacs-de...@gnu.org > >> Date: Tue, 12 Sep 2023 06:38:00 +0200 > >> > >> "Eric S. Raymond" <e...@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.
