Re: Shrinking the C core

[joakim]

chad <yandros@gmail.com> writes:

> Now that we're in -tangets (thanks for doing that, btw)...
>
> On Tue, Sep 12, 2023 at 7:57 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
>  [...] And don't be afraid of losing some of the applications and the
>  documentation -- these should be the least of your worries. [...]
>
> My own opinion has come around to match Eli's (far more relevant/expert) on 
> this topic, but in case it helps anyone else:
> I think this reflexive desire to keep a strong hold on all the existing elisp 
> comes from the long line of emacs clones
> like Edwin, Hemlock, climacs, Alpha, and a long list of less well-known 
> alternatives. I "lived through" several of these,
> and the sense I got from every one I actually tried was that people 
> eventually fell back to the "real thing" emacs,
> largely because it worked (well enough?) and already had some facilities that 
> were missing in the putative replacement. 
>
> summary: I think it's hard to unlearn this lesson from history
>
> It's entirely possible that the shift of "typical computing" towards 
> massively multi-core distributed etc. is the final
> straw, or at least the high bar that a massively-shared-state-lisp-machine 
> can't vault -- while still being good enough
> to cross most of the moats we see in everyday usage. It's also possible that 
> there's some adaptation that will arise,
> perhaps along the lines of how web workers/service worker threads interact 
> with the DOM in the modern browser, that keeps
> Emacs going even longer. I remember the days when "Yeah, that will happen 
> shortly after the release of Emacs 21" was the
> in-joke for porcine aeronautics, and we just saw Emacs 29 released, so: it 
> could happen.
>
> I do think that a very early step needs to be "figure out how to handle 
> concurrent analysis and editing across multiple
> cores and perhaps machines", but that probably just reflects a bunch of my 
> personal interests.

Since we are in "tangents" now, I suppose it wont harm if I add some
opinions as well.

I also tried many different emacsen, and different editors, and always
came back to the mother-ship.


The thread seemed to focus mostly on things that Emacs doesnt do so
well, and not on what Emacs does remarkably well.

For instance, the multi-tty feature is fantastic, I use it all the
time. You can use emacs on a tiny raspberry, or on a super large
machine. There is tramp, and well, the kitchen sink. And emacs is
infinitely tweakable, which is very useful. The buffer/window paradigm
is really useful.

The "new" batch of applications dont do much of the above things, so
while of course more visually apealing, they dont add much else(well of
course, LSP, and stuff, but emacs has that now as well)

So while the thread was about multi-threading, if I had a magic wand to
fix emacs things, I would fix that bother me daily.

- if I'm connected to an emacs session by ssh, and mistakenly make a
  cli command dump tens of megabytes of spewage to the shell buffer, I'm in 
trouble
  and cant easily get out of it. I need to open a new ssh session and
  kill the rampaging cli. This is quite tedious. Would concurrency fix this?

- Same for long-lines, this is still not a solved problem.

- Gnus refreshes slowly, maybe that could be helped with concurrency,
  but it could also be helped with more async work in gnus.

Anyway, thats my 0.02€, please ignore and carry on...


>
> ~Chad
>
-- 
Joakim Verona
joakim@verona.se