[Zambyte]

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.

[krupan]

https://guile-emacs.org/

[Zambyte]

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.

[volemo]

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

[cmrdporcupine]

Sounds like you want Lem. Though it's common lisp instead of guile.

https://github.com/lem-project/lem

[Zambyte]

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]

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.

[grumpyprole]

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

[iLemming]

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]

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

[krupan]

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

[bergheim]

after 30 years you say this? this cannot be serious.