My recollection of past guile-emacs stuff is that rms is not a blocker here.

> rms is not a blocker here

huh?!?

he was and is actually supporter of guile-emacs

rms is a blocker of CL emacs, which I would like to see (and use). Relative to the guile, CL implementations are of great quality, rich set of libraries, ...

There would be no speed improvement, because the guile jit will not beat the existing native aot compilation via the libgccjit. It will be rather slower. But it will have proper concurrency support, and access to a wide area of guile libs. And a proper jit, which Stallman blocked for decades because of evil dll's.

Ah, typo. A proper ffi of course

What's your rush, sonny? You say 'not anytime soon' but then you say 'next 10 years'. In the world of GNU software, to say 'glacial pace' is basically asking 'what's your hurry?' Fine wine, fine wine... give it at least 30-40 years...

The biggest roadblocks are 1) lack of continued effort and 2) reticence on the Emacs side. I'd say 1) is the most important by far.

3) what's the point?

It's not like the pool of guile developers is much larger than the pool of elisp developers.

And guile has gotten worse for users in the 3.x series compared to the 2.x series.

This is coming from someone whose used it since 1.6 and gave up around 3.0.4 moving to racket.

Guile is garbage, just move to CL

In terms of speed, yes. In terms of functionality, hell no. Compare the following in Racket:

  (define (add-2 x)
    (+ x 2))
  (add-2 z)

Where the result is an error without the possibility to provide a value. Compared to in SBCL:

  (defun add-2 (x)
    (+ x 2))
  (add-2 z)

Where we are dropped in the debugger with the following possible restarts:

* Continue, where we retry the operation (best to first define z),

* Use Value, where we can provide a value to use,

* Store Value, where we can set z to a value and use the value,

* Abort, where we just cancel the operation.

There's also setf expansions, so in SBCL we can do, for example:

  (setf (car some-pair) 3)

Whereas in Racket we can't do the equivalent:

  (set! (car some-pair) 3)

Although I think I understand Stallman and his role in Emacs pretty well, I cannot guess as to what "Stallman factor" refers to in this context.

I don't so it was a genuine question, checking if my understanding was correct. I guess it's more about the CL aspect.

From the article "Richard Stallman is not a fan of Common Lisp; rewriting Emacs using it is not likely to go far." My understanding is his preferences have a strong influence on emacs direction, which of course is well deserved, but he can be stubborn about things. I used "stallman factor" because it's not easy to sum up, as his strong opinions and influence on the project are both not bad things (even when I disagree with him I feel it's important to have someone like him) but they do prevent some avenues for improvement. Happy to be wrong about this.

Judging by the mailing list, RMS is not actively involved in emacs development at all.

In such cases he will show up for sure. Esp. for the ffi. But we got around him with our last ffi for gtk.