4 ms·

For people who are more involved in this world than me: What're the chances of actually getting a supported full feature parity version of guile emacs? Like not

by klik99 2y ago

For people who are more involved in this world than me: What're the chances of actually getting a supported full feature parity version of guile emacs? Like not anytime soon but, say, in the next 10 years. It's my understanding it would be a significant speed improvement but the amount of work and the - ahem - stallman factor are big roadblocks.

rurban 2y ago
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.
- rurban 2y ago
  Ah, typo. A proper ffi of course
hollerith 2y ago
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.
- Iwan-Zotow 2y ago
  RMS refuses and blocks efforts to move to CL Emacs. That would be a revolutionary development, not that Guile garbage
- klik99 2y ago
  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.
  - School-Cotton 2y ago
    Judging by the mailing list, RMS is not actively involved in emacs development at all.
    - rurban 2y ago
      In such cases he will show up for sure. Esp. for the ffi. But we got around him with our last ffi for gtk.
davexunit 2y ago
My recollection of past guile-emacs stuff is that rms is not a blocker here.
- Iwan-Zotow 2y ago
  > 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, ...
lloda 2y ago
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.
- llm_trw 2y ago
  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.
  - Iwan-Zotow 2y ago
    Guile is garbage, just move to CL
    - llm_trw 2y ago
      CL is to Racket as C is to Python.
      - tmtvl 2y ago
        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)
blihp 2y ago
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...

by klik99 2y ago

rurban 2y ago

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.

rurban 2y ago
Ah, typo. A proper ffi of course

hollerith 2y ago

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.

Iwan-Zotow 2y ago
RMS refuses and blocks efforts to move to CL Emacs. That would be a revolutionary development, not that Guile garbage
klik99 2y ago
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.
- School-Cotton 2y ago
  Judging by the mailing list, RMS is not actively involved in emacs development at all.
  - rurban 2y ago
    In such cases he will show up for sure. Esp. for the ffi. But we got around him with our last ffi for gtk.

davexunit 2y ago

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

Iwan-Zotow 2y ago
> 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, ...

lloda 2y ago

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.

llm_trw 2y ago
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.
- Iwan-Zotow 2y ago
  Guile is garbage, just move to CL
  - llm_trw 2y ago
    CL is to Racket as C is to Python.
    - tmtvl 2y ago
      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)

blihp 2y ago

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...