My I3-Emacs Integration
khz.ac
khz.ac
Two-part desk setup : https://news.ycombinator.com/item?id=48214311
Writerdeck: https://news.ycombinator.com/item?id=48250144
Wake-up demo: https://news.ycombinator.com/item?id=48253060
It's been great, much more like HN used to be.
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.
Edit: and PWA support! Woohoo!
When we switched to using a tiling window manager for all our windows, we ran into a muscle memory problem. We were used to jumping between emacs windows/buffers using C-x o and C-x b and then without thinking about it we'd try and use the same keys to jump between i3/sway windows and of course it doesn't work. Or vice versa, trying to use i3/sway shortcuts to switch emacs windows/buffers.
To try and solve this problem I've been using less emacs windows and more i3/sway windows, so I can just use i3/sway keybindings everywhere, but emacs puts up some resistance to that. I like this approach
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.
So instead, I’ve made any keybinding with the Super key take ownership from the window manager, and ctrl-c * for emacs, but I’ve been thinking of binding the Hyper key to my keyboard so it’s one less level
Recently I hacked together a Bash script for seamless navigation between i3 windows/tabs and Kitty windows/tabs using i3-msg, xdotool, jq, kitty's remote control sockets. Now if I only figured out how to add Helix windows into the mix...
Sometimes thinking outside the box helps. I've been able to unify a lot of keybindings by using a context aware remapping tool such as Keymapper (https://github.com/houmain/keymapper.
Lagging is super annoying, and regretfully it comes mostly from very slow pgtk cairo implementation.
I'm getting the Skia branch to a usable shape this week. A bit too early to say, but the approach looks promising. Running it for almost a week with a 4k 120hz external monitor, no issues noticed so far.
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).
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.
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
"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.
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.
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.
(defun my-external-readonly-split ()
"Open the current file in an external xfce4-terminal as read-only."
(interactive)
(if buffer-file-name
(start-process "xfce-terminal-split" nil
"xfce4-terminal" "-x" "emacs" "-nw"
"--eval" "(find-file-read-only (pop command-line-args-left))"
buffer-file-name)
(message "Current buffer is not visiting a file!")))
(global-set-key (kbd "C-x 4") 'my-external-readonly-split)Try C-x 2, C-x 3 and C-x 4
export EDITOR="emacs -nw"It really speeds things up
It's is great in everything which requires talking to and/or listening on a socket. It's amazing for writing and running daemons.
Very interesting though. I don’t always read entire posts on blogs but this one I did. Lisp looks really interesting.