Hacker News Reader

Comment by jhoechtl | Hacker News Reader

Is there any progress made on modernizing Emacs internals? Like

* disentangling it from GTK to make Emacs a proper GUI citizen or * the shift from Emacs Lisp towards ... is it Guile?

I'm not quite sure what you mean by disentangling it from GTK. I can tell you that a major selling point of the 29 release is that the GUI is more entangled with GTK. Specifically, by removing all X11 code and using only GTK, Wayland will have native support, instead of requiring an additional X server as a shim between the two.

All attempts to use guile were never completed , and the resulting prototypes were always slower, mostly because of impedance mismatches between guile and elisp. As reported by the sibling comment, native-comp was merged and it makes the existing elisp code faster while being fully compatible. It was a major achievement, done in a relatively short time by a single contributor!

It means that elisp is here to stay with all its quirk, but as we all know, worse is always better (which is ironic when comparing lisps :) ).

"the resulting prototypes were always slower, mostly because of impedance mismatches between guile and elisp"

That may be technically true, but I think the real problem is that there was only one guy working on the project.

A lot more progress would probably have been made if there was a team of people working on it, but apparently it's just not important enough for most Emacs users. Some would like to see it happen, but not enough to actually contribute to the effort to make it so.

I'm not disagreeing with you, but this is kind of a moot point since the main selling point of Guile was always performance. AFAIK it was never the plan to actually make Emacs use Scheme rather than Elisp---the semantics of the languages just aren't compatible, and it would require throwing away too much of the existing Elisp ecosystem.^[1] Rather, the idea was to modify the better-performing Guile interpreter so that it could evaluate Elisp with the end goal being better performance.

Since the performance wins for native compilation exceed what people had hoped for with Guile Emacs, whether or not Guile Emacs was feasible isn't really that important.

[1] Furthermore: the biggest wart in Elisp compared to modern Lisps like Scheme is that it uses dynamic binding by default. But pretty much everything in Emacs (including third-party packages) declares lexical binding now (which is required for native compilation anyway), and the use of cl-lib nowadays is fairly ubiquitous, so a lot of the arguments about Elisp not being as "nice" as other modern Lisps aren't as compelling as they used to be 15 years ago.

"the main selling point of Guile was always performance"

I don't agree with this. For Emacs users like myself, Guile is just a way more elegant and powerful language than eLisp (and also preferable to Common Lisp, which is a lot more antiquated and clunky compared to Scheme). I would have written all my Emacs code in Guile (or any other modern Scheme) if I could.

If Guile Emacs could equal the performance of regular Emacs (or even a little slower) while allowing all existing eLisp packages to run, then I'd switch in a heartbeat. It needn't have offered better performance than regular Emacs to win me over.

But the parent is arguing that guile-emacs was never on the table. Instead the plan was elisp-on-guile-vm.

I'm sure a guile-emacs would have been a better platform in Isolation but without the thousands of elisp packages it would never have gained traction.

In fact it was Guile Emacs exactly. What that entailed was both the ability of the Guile VM to run eLisp so that all existing eLisp packages would run on the Guile VM without modification and that Emacs users could write in Guile (or any other language that the Guile VM supported) instead of eLisp if they chose.

The big selling point was that no eLisp packages would have to be rewritten in Guile, but that wouldn't stop new packages and other code to be written in Guile if users chose. Both of these were essential for users like myself who actually prefer to write their own code in Scheme, but realize that rewriting all existing packages in it is an unrealistic goal.

That's interesting and I guess it would have worked. Unfortunately the reality is that nobody assign people to tasks in purely community driven open source projects like emacs. People do the task they are interested in.

At this point I guess it is more likely for elisp to slowly mutate into CL than emacs getting scheme support.

I know very little of the lisp ecosystem (I barely can write some elisp) so I don't know what are the pros and cons of scheme vs CL.

As far as as I can tell, there aren't a huge amount of contributors to the core emacs team in the first place. Still the native-comp was implemented by one person.

That means that native-comp was probably easier than well-performing Guile Emacs. I'm not disputing that, just pointing out that performant Guile Emacs could have probably been done if enough people contributed rather than leaving it to one person.

My not very well-informed take on the situation is: Yes, Emacs seems to make a lot of progress in many directions. Latest git master does have elisp native compilation support (via libgccjit). Various elisp semantics have been modernized (support for common-lisp style lexical closures).

Still it is rather lightweight (compared with, say firefox), you can download upstream source and compile&install it in minutes rather than hours.

>the shift from Emacs Lisp towards ... is it Guile

Guile isn't meant to replace ELisp but the ELisp engine. Also note ELisp is closer to CLisp than Scheme that Guile is.

As someone who wrte a partial implementation of elisp in Common Lisp, at one point in time...

Yes, elisp is in many ways closer to CL than it is to Scheme. But, it is not very close to CL, once you start looking at the details.

Reply on news.ycombinator.com