54 ms·

Ooo this is nice. I may have to try to get this working with my personal setup using Emacs and Sway. My long term vision is to make an Emacs implementation tha

by Zambyte 5mo ago

Ooo this is nice. I may have to try to get this working with my personal setup using Emacs and Sway. My long term vision is to make an Emacs implementation that is compatible only in philosophy. It would use Guile instead of Elisp, default to bindings that are more familiar to people coming from more modern systems, and would be built from the beginning with concurrency and graphics in mind. For now it remains a dream though.

grumpyprole 5mo ago
VSCode is pretty much this. But with typescript instead of Guile. After 30 years of Emacs, I switched .
- bergheim 5mo ago
  after 30 years you say this? this cannot be serious.
- krupan 5mo ago
  Heresy! ;) I would guess you hadn't done as much emacs yak shaving as some of us other emacs users if the switch to VSCode was a simple one
- iLemming 5mo ago
  Pfff... it's like my teenage daughter who's never driven a car brags to her friends how Mazda is better than Toyota, because "she switched". "Using Emacs" means actively reading, writing, evaluating Lisp code. How many packages have you written? If not too many, I'm afraid, you're only "riding it", not "using" it, just like my daughter has been riding in one car and now in a different one. There's a huge fundamental gap between Emacs and VSCode. In Emacs, the editor is the Lisp runtime. Every piece of the editor is a live Lisp object you can inspect, redefine, and compose at runtime. There's no boundary between "editor" and "extension" - they're all just functions and variables in the same image. VSCode doesn't offer anything remotely close to that. Without understanding that gap, there's no understanding of what Emacs actually is. There's no "switching" between Emacs and an editor/IDE. "IDE" is a much smaller category than what Emacs actually is. You switched editors while not realizing you gave up something that isn't an editor.
  - alfiedotwtf 5mo ago
    A bit harsh, but 100% on point. THIS is why emacs is fundamentally different to the core of what emacs is vs all other editors - you’re driving a Mazda, but you’re your own mechanics with that Toyota
cmrdporcupine 5mo ago
Sounds like you want Lem. Though it's common lisp instead of guile. https://github.com/lem-project/lem https://github.com/lem-project/lem
- Zambyte 5mo ago
  Nope! I should have elaborated, but by "graphics in mind" I meant full support for graphical applications. I want it to be a Wayland compositor. It would either be used as a top level compositor like EXWM, or as a nested compositor, like how gamescope is used. I want it to be as easy to make scripts to automate graphical applications as it is to automate textual ones in Emacs or shell scripts.
  - cmrdporcupine 5mo ago
    Yeah fair enough. I think we likely agree, too. As I said in my other comment in this topic I actually would love to see an arch where the UI portions are split up with a background daemon holding buffers, lisp execution etc and then IPC to frontend pieces for window management and buffer editing. So window management can be done by ... a window manager, but with intelligent interaction to the editor pieces so you don't lose all the awesome emacs stuff. EDIT: I would say however that something like lem is probably more amenable to that refactoring/restructuring than GNU emacs, which is a single-threaded monolith.
volemo 5mo ago
I know, right? However, one of the strongest points of Emacs is the huge amount of existing packages.
krupan 5mo ago
https://guile-emacs.org/ https://guile-emacs.org/
- Zambyte 5mo ago
  I'm familiar. The difference is that this is targeting source compatibility with existing Elisp. I don't feel like that is worth it for most people who would be interested in what I want to build.

by Zambyte 5mo ago

grumpyprole 5mo ago

VSCode is pretty much this. But with typescript instead of Guile. After 30 years of Emacs, I switched .

bergheim 5mo ago
after 30 years you say this? this cannot be serious.
krupan 5mo ago
Heresy! ;) I would guess you hadn't done as much emacs yak shaving as some of us other emacs users if the switch to VSCode was a simple one
iLemming 5mo ago
Pfff... it's like my teenage daughter who's never driven a car brags to her friends how Mazda is better than Toyota, because "she switched". "Using Emacs" means actively reading, writing, evaluating Lisp code. How many packages have you written? If not too many, I'm afraid, you're only "riding it", not "using" it, just like my daughter has been riding in one car and now in a different one. There's a huge fundamental gap between Emacs and VSCode. In Emacs, the editor is the Lisp runtime. Every piece of the editor is a live Lisp object you can inspect, redefine, and compose at runtime. There's no boundary between "editor" and "extension" - they're all just functions and variables in the same image. VSCode doesn't offer anything remotely close to that. Without understanding that gap, there's no understanding of what Emacs actually is. There's no "switching" between Emacs and an editor/IDE. "IDE" is a much smaller category than what Emacs actually is. You switched editors while not realizing you gave up something that isn't an editor.
- alfiedotwtf 5mo ago
  A bit harsh, but 100% on point. THIS is why emacs is fundamentally different to the core of what emacs is vs all other editors - you’re driving a Mazda, but you’re your own mechanics with that Toyota

cmrdporcupine 5mo ago

Sounds like you want Lem. Though it's common lisp instead of guile. https://github.com/lem-project/lem https://github.com/lem-project/lem

Zambyte 5mo ago
Nope! I should have elaborated, but by "graphics in mind" I meant full support for graphical applications. I want it to be a Wayland compositor. It would either be used as a top level compositor like EXWM, or as a nested compositor, like how gamescope is used. I want it to be as easy to make scripts to automate graphical applications as it is to automate textual ones in Emacs or shell scripts.
- cmrdporcupine 5mo ago
  Yeah fair enough. I think we likely agree, too. As I said in my other comment in this topic I actually would love to see an arch where the UI portions are split up with a background daemon holding buffers, lisp execution etc and then IPC to frontend pieces for window management and buffer editing. So window management can be done by ... a window manager, but with intelligent interaction to the editor pieces so you don't lose all the awesome emacs stuff. EDIT: I would say however that something like lem is probably more amenable to that refactoring/restructuring than GNU emacs, which is a single-threaded monolith.

volemo 5mo ago

I know, right? However, one of the strongest points of Emacs is the huge amount of existing packages.

krupan 5mo ago

https://guile-emacs.org/ https://guile-emacs.org/

Zambyte 5mo ago
I'm familiar. The difference is that this is targeting source compatibility with existing Elisp. I don't feel like that is worth it for most people who would be interested in what I want to build.