Rendered at 22:39:27 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
SubiculumCode 21 hours ago [-]
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.
noir_lord 12 hours ago [-]
I set up a crude set of Ublock Origin filters to nuke AI off the frontpage of HN a while ago.
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.
ristomatti 6 hours ago [-]
In my current favorite alternative HN frontend https://hcker.news, you can filter (include and/or exclude) posts by words found in the titles. There's _a lot_ of other customization options as well.
backwardsponcho 47 minutes ago [-]
Dark mode? God finally
Edit: and PWA support! Woohoo!
diminish 15 hours ago [-]
Can you pls link to them?
torh 12 hours ago [-]
They are still on the front page, but here you go:
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 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
ristomatti 6 hours ago [-]
I'd be surprised if someone hasn't already solved this. I'm not an Emacs user myself but try searching for something like "seamless <tiling_system> <tiling_app> navigation site:github.com". I've seen several scripts/plugins to setup seamless navigation between i3/tmux, tmux/Vim, i3/tmux/NeoVim, i3/Zellij etc.
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.
9999gold 6 hours ago [-]
I can relate, finding myself pressing the wrong keybindings when moving between i3 and emacs windows. The idea in the post is interesting but I am not sure how I’m going to solve this. I have been thinking about trying EXWM or switch to another WM. Tried KDE but it didn’t have support for multiple workspaces in the secondary screen. And after using i3wm I found it difficult to get back to other WMs.
cmrdporcupine 10 hours ago [-]
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.
alfiedotwtf 2 hours ago [-]
I got rid of the default bindings for my window manager and emacs…
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
Zambyte 15 hours 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.
volemo 12 hours ago [-]
I know, right? However, one of the strongest points of Emacs is the huge amount of existing packages.
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.
cmrdporcupine 14 hours ago [-]
Sounds like you want Lem. Though it's common lisp instead of guile.
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 8 hours 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.
grumpyprole 14 hours ago [-]
VSCode is pretty much this. But with typescript instead of Guile. After 30 years of Emacs, I switched .
iLemming 2 hours 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 2 hours 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
krupan 10 hours 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
bergheim 13 hours ago [-]
after 30 years you say this? this cannot be serious.
timonoko 15 hours ago [-]
Unrelated, but me and Gemini just invented "C-x 4" for multiscreens.
(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)
the-lazy-guy 11 hours ago [-]
You should use emacsclient, so file will be actually shared. Or better yet - use GUI emacs with its ability to have multiple frames.
timonoko 10 hours ago [-]
No Thank You
export EDITOR="emacs -nw"
krupan 10 hours ago [-]
export EDITOR="emacsclient -nw"
It really speeds things up
timonoko 14 hours ago [-]
Incredibly splendid. I just tested it myself.
Try C-x 2, C-x 3 and C-x 4
klik99 7 hours ago [-]
I have to mainly drive Windows 11 for work reasons so I use komorebi for a tiling window manager (highly recommended btw). I bet the ideas in this post can be applied in that environment too, gotta try it now, great idea
skulk 22 hours ago [-]
I've started using ewm to get this kind of unification between emacs window management and non-emacs window management.
I keep trying it (coming from EXWM) but I get lots of lag, stutters, and poor fractional scaling. I'm not sure how much of that is "GTK under wayland", Emacs's PGTK build (known to have lag/rendering issues), AMD kernel drivers (?), or EWM itself; but it's not yet a replacement for EXWM in my experience.
krupan 10 hours ago [-]
"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).
skulk 8 hours ago [-]
it is sad, X11 had a suite of tools like xrandr that worked regardless of your wm/compositor but now with Wayland these tools are compositor-specific (or have to agree to a standard).
nesarkvechnep 14 hours ago [-]
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.
krupan 10 hours ago [-]
Care to share?
Pay08 8 hours ago [-]
I'm curious; why Erlang?
nesarkvechnep 1 hours ago [-]
Why not Erlang?
It's is great in everything which requires talking to and/or listening on a socket. It's amazing for writing and running daemons.
PunchyHamster 23 hours ago [-]
I just use super(win key)/hyper (bound to capslock) for i3-related commands and leave emacs to its own devices with normal binds
That's fine as far as it goes, but I don't think that gets you what this article is for, which is things like using the same binding context-dependently to navigate between emacs splits and regular window manager windows, context-dependently. Which is a fun bit of overengineering.
krupan 11 hours ago [-]
The problem some of us have is we get used to jumping between emacs windows/buffers using C-x o and C-x b and then without thinking about it try and use the same keys to jump between i3 windows and of course it doesn't work. Or vice versa, trying to use i3 shortcuts to switch emacs windows/buffers.
rileymat2 22 hours ago [-]
Yes, I am misunderstanding the problem. The windows/mac command key leave shift, control and alt free for i3.
royal__ 22 hours ago [-]
Yeah this is what I do. This article feels like crazy overengineering for something that's not really a problem
dima55 22 hours ago [-]
A dedicated key for all window-manager things is what people that have thought about it do (I use the "windows" key). But keyboard manufacturers haven't thought about it, so sometimes reasonable things aren't possible. I don't know.
sudahtigabulan 16 hours ago [-]
Unless you have RSI. Then it might be worth it. Depends on what hurts.
gigatexal 17 hours ago [-]
Ah no video it action??
Very interesting though. I don’t always read entire posts on blogs but this one I did. Lisp looks really interesting.
Pay08 8 hours ago [-]
Unrelated to the content of the article, but I absolutely hate the lack of capitalisation.
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!
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
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
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.
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
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.
https://github.com/lem-project/lem
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.
"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 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
It really speeds things up
Try C-x 2, C-x 3 and C-x 4
https://codeberg.org/ezemtsov/ewm
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).
It's is great in everything which requires talking to and/or listening on a socket. It's amazing for writing and running daemons.
https://xcancel.com/octonion/status/1341113219142828039
Very interesting though. I don’t always read entire posts on blogs but this one I did. Lisp looks really interesting.