Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My I3-Emacs Integration

khz.ac

Post reply on HN
Print view View original

31–40 of 53 posts

Re: My I3-Emacs Integration

#31

Post by krupan »

grumpyprole wrote: post #17
Zambyte wrote: post #13

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 drea…

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

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

Re: My I3-Emacs Integration

#32

Post by krupan »

skulk wrote: post #6

I've started using ewm to get this kind of unification between emacs window management and non-emacs window management. https://codeberg.org/ezemtsov/ewm

"Writing a Wayland compositor from scratch is a staggering amount of work..."

I switched to Wayland and sway about 2 years ago and it hasn't been bad, but this is the thing that makes me most sad about Wayland. X has so many different window manager options, it's like, an embarrassment of wealth. Wayland has like, 3 "finished" ones (if sway even counts).

Re: My I3-Emacs Integration

#33

Post by krupan »

nesarkvechnep wrote: post #20

I did the same integration with an Erlang daemon. All relevant key presses are sent to it and based on the current focused application the daemon does different things. I built an Erlang library i3_IPC to listen for events and send commands to Sway.

Care to share?

Re: My I3-Emacs Integration

#34

Post by cmrdporcupine »

krupan wrote: post #29

In case you don't understand the problem here, an emacs instance can be split into multiple "windows" and there are emacs key bindings to create and destroy these windows, move the "focus" from one window to another, resize the windows, etc. For many of us, this was our introduction to a tiling window manager experience before we'd ever heard of tiling window managers. When we switched to using a tiling window manage…

Yep, I still find emacs' window management bindings more intuitive than any tiling window manager I've used. So much so that I thought naively that things like exwm would "solve" this problem for me. But in fact -- beyond being janky / single-threaded -- they don't really because you still end up with competing bindings.

I think the more elegant model would be for the window manager to own all the window management keybindings and then for there to be a background emacs-like process that owns the buffers (and the remaining keybindings) and can present them in standalone windows which the window manager presents. With some kind of IPC between the two for coordination, I guess.

I don't think GNU Emacs itself works well with this model tho. Its "server" mode is something else entirely.

Re: My I3-Emacs Integration

#35

Post by Pay08 »

nesarkvechnep wrote: post #20

I did the same integration with an Erlang daemon. All relevant key presses are sent to it and based on the current focused application the daemon does different things. I built an Erlang library i3_IPC to listen for events and send commands to Sway.

I'm curious; why Erlang?

Re: My I3-Emacs Integration

#36

Post by Zambyte »

krupan wrote: post #26
Zambyte wrote: post #13

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 drea…

https://guile-emacs.org/

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.

Re: My I3-Emacs Integration

#37

Post by Zambyte »

cmrdporcupine wrote: post #18
Zambyte wrote: post #13

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 drea…

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

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.

Re: My I3-Emacs Integration

#38

Post by leephillips »

noir_lord wrote: post #23
SubiculumCode wrote: post #8

Side note: I am really enjoying HN today with the set of stories with personal hacks like this i3-emacs integration, someone's desk setup, someone's writer-deck laptop install, the kinda hilarious but also hecka geeky thermal ttrpg thingamabob, and the 16 byte wake up demo. Fun geeky stuff that isn't AI,and I love AI, but it ain't everything.

I set up a crude set of Ublock Origin filters to nuke AI off the frontpage of HN a while ago. It's been great, much more like HN used to be.

I set this up: https://hn-ai.org/

The problem now is that so many articles with innocent titles are really about AI slop. The title might be “A Space Exploration Game” and the content is about some vibe-coded garbage.

Re: My I3-Emacs Integration

#39

Post by cmrdporcupine »

Zambyte wrote: post #37
cmrdporcupine wrote: post #18

Earlier quoted context omitted.

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

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.

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.

Post reply on HN