noctuid

I like it infinitely more than anything, but it also still feels like a comparably slow, crufty pos that will probably die because of how anti-AI half the core community is. Regardless of how good magit is, it's slow.

I also can't understand how people like eca and agent-shell so much unless they've never actually used any decent harness. Neither seems to really fit with emacs. Acp is the exact opposite of extensible, and eca isn't really extensible either.

This a session search tool, and I think calling it a memory tool is confusing.

> Secrets: The ctx README mentions saving the text as is and warns about the need to review the output data before publishing. deja explicitly removes known secret templates at the indexing stage (replacing them with tags like [redacted:aws-key]).

How is this not security theater? You've presumably already sent the api key to an LLM if it's in your session file. You need to rotate it.

It's not easy, that's why they all suck.

No one mentioned vi, I like neovim just fine, and I'm using pi daily. Nice try though. My only point is that if you want to talk about rewriting everything yourself, NIH, churn, whatever you want to call it, Emacs is absolutely not a great example.

The new thing where everyone just vibe codes their own versions of everything is not at all like personalizing Emacs.

Specifically the idea that people generally just ignore existing versions of packages and make their own has never been the case, especially compared to other editors (even VSCode).

> There are popular elisp packages lots of people use. But except for Magit, nerds are alarmingly apt to replace them with their own shinier versions (and then to show them off, transitioning to the spore-forming phase of the elisp lifecycle). Everything in Emacs is malleable.

> Until now, the Achilles heel of Emacs culture has been that, except for Magit, its packages tend to be wretched user experiences. Ugly, slow, and discoverable only after inflicting years of elisp cortical injuries on yourself.

Terrible analogy. Emacs has always had comparably fewer major options for packages compared to other tools, there is often an obvious option based on your needs, and it has never been my experience that people decide to just roll their own versions of everything. The author has clearly never used neovim or now pi. NPM packages in general would have also been a way better example.

Edit: Sure there is some small overlap here, but it's really not comparable and definitely not like the way the author describes things. User personalization in Emacs has normally been on a much smaller scale than rewriting entire packages. Configuration is generally smaller tweaks or things on top of existing packages because Emacs provides cohesive extensibility to the point that it often doesn't require "rolling your own." Most packages are already extremely configurable and tailorable. You don't magically get that sort of environment with LLMs. Emacs is much more cooperative/generalized.

The scale and type of custom/personalized software we're seeing now with AI is completely different from how things have been in Emacs. I'm not saying that's a good or bad thing (I think it's both), but it's very different from Emacs and definitely more comparable to something like vim/neovim where (in part just because of the sheer popularity) you constantly have people "rolling their own" packages and a billion versions of everything. Even that is not a great analogy. This is something completely new.

What's just as crazy is people defending ollama.

You can take modal editing anywhere, but that doesn't mean you should.

There are many better sandboxing options than docker (in terms of security and/or ease of use), and it sounded like you weren't doing sandboxing.

Is this satire? I can never tell anymore.

Functionally you can focus any workspace on any monitor, and ids do not change when doing that. You can set things up both ways, but it's actually easier to just have a key focus workspace x on the current monitor than to lock workspaces to specific monitor.

Hyprland works with nvidia just fine with minimal coniguration, just as well as any other wayland compositor I've tried, and I have a very old card. Having out of date packages is going to be an issue on Ubuntu for software in general, but probably sway would be better to try.

There is also scroll (sway fork) and plugins for hyprland. Scrolling experience was not actually better in niri vs. others in my experience just because it was built around it. I tried to use niri, but there is too much missing functionality I want compared to hyprland and also worse power consumption.

Workspaces are not bound to displays in hyprland. This is one major reason I'm using hyprland over niri, where it's not really possible to work around that issue.

There's also focusworkspaceoncurrentmonitor, and anything more complicated can be scripted trivially to be on one keybind.

I'd be happy if they banned all devices

Keyboard mapping is fine on macOS (though most of those posts seem related to software or functionality I would never use). Keyboard-only experience is a lot more than keyboard mapping.

Consider window management, for example. If we're talking about using the keyboard for nearly everything, window management is one of the most fundamental parts of interacting with a computer. Linux has dozens of keyboard-based tiling window managers. You have only a few options on macOS, and they are all weak by comparison. Yabai is passable if you partially disable SIP so it can manage spaces, but it still has pretty limited functionality compared to herbstluftwm and bspwm (which is what it's mimicking) and feels hacky.

Similarly, cli tools are very popular on linux, and it is very easy to bind keys to them. Luckily a lot of tools work on both linux and mac, but this is not always the case. Replicating my global hotkeys has been an annoyance on macOS in some cases because of this. In linux, you have control of and multiple options for basically everything (e.g. bootloader, what you use for networking, what you use for notifications, etc.). In the case of notifications, on linux I can just bind a key to "dunstctl close-all" to close all notifications or "dunstctl history-pop" to show old notifications. My notification daemon is designed with scriptability in mind. If I want to have a similar keybinding on macOS I have to go through an arduous process of trying to find some up-to-date applescript snippet that actually works and isn't slow (couldn't find one that met either requirement) or learn to use some other automation tool. Unlike the WM case, I'm sure it's possible, it's just that macOS is just very clearly not designed with the use-case of keyboard for everything in mind. It can still support it very well, but with linux I can have it so that non-keyboard-friendly software just doesn't exist on my system. I don't need to workaround it.

> No way, that's an almost non-existing class of apps. Which "keyboard-friendly software" supports the differentiation between tap and hold? Hold delays? Simultaneous keypresses? Arbitrary alpha key modifiers (hold T for Toolbar and tap 1,2,3 select different types of brushes in your image app)? Support for custom notifications? Knows left from right? Supports chords, not just combos, including single-key shortcuts?

It would be cool, but I just don't see any of this as necessary. What I use supports single-key shortcuts, modality, and modifier shortcuts, and I wouldn't need anything else. Emacs and probably vim support arbitrary key combos and some more advanced functionality with timeouts, but I don't use those features. Even at the global level, I don't use tap-hold on alpha keys or arbitrary combos. It seems like these extra features are primarily useful as workarounds for having a bad keyboard. Normal modifiers are good enough for me. There are already plenty of actions available using just single keys and modifier keys, and modifier keys are comfortable on a good keyboard (even on my personal laptop I have 8 comfortable thumb keys). "hold T for Toolbar and tap 1,2,3" seems like a comparably painful/inefficient chord, and I'm not using software designed primarily with mouse interaction and things like toolbars in mind.

> But it's not a binary, even apps that offer customizable key shortcuts, mostly offer underpowered versions nowhere close to what a keyboard remapper can offer.

I'm definitely biased in that I'm a software engineer and am not working with graphical applications like photoshop. 95% of my time is spent using tools that are programmable and intended to be used primarily with a keyboard or at least have first-class support for it.

> there is also a more limited browser-only, but cross-platform extension GhostText

firenvim can also actually embed vim in browser input fields regardless of OS. Vim is really the only option still if you don't want an external window though.

> Though maybe you can set a keybind that would instantly open a specially configured editor

Right, there are things like emacs-everywhere that can be globally bound and will automatically handle the "syncing." Probably there are similar plugins for other editors but nothing universal I'm aware of.

> All of them do, e.g., app launcher requires the contexts of the app state. If the app is in the foreground, it will hide it, if it's in the background, it'll show it, if the app isn't not launched, it'll launch it.

I have global keybindings for all my most used applications that support toggle/dropdown functionality. I don't really use enough applications to need a launcher that does this, but you can at least implement this using external context only. It would be easy to script something like this on linux, but it would be X11-specific (e.g. tdrop + maybe rofi) or window manager-specific.

> That would still fall short of Keyboard Maestro with its GUI where you can much easier find he available actions and stich them together

Only if you're a fan of GUI configuration. I'd much rather have no GUI at all and just good documentation.

> It's also the only way to make something great. There is no "native" OS/app development platform that matches that power, so it's very rare for an app to implement anything advanced on its own

> > You have some context available but only what is externally available > That's a very common limitation unfortunately

It certainly would be nice if all software was integrated at the level where you could access and work with internal state. It's why I'm using Emacs for nearly everything, but then you're stuck with whatever limitations/flaws the system has, so there are tradeoffs. If you like having options, it's nice that linux has so many Desktop Environment choices and dozens of really good window managers. By comparison, if you like tiling window managers, macOS is not great. Yabai is passable but requires partially disabling SIP or else it can't even manage/switch spaces. On the other hand, a lot of hammerspoon functionality is missing on linux. Linux will probably never have any good generic automation tools. X11 at least has some more advanced, generic tools like xdotool, but this is currently impossible with Wayland, and definitely nothing supports both. Anything more advanced than input like window management is wm/compositor-specific currently on Wayland, so if anything, linux is going backwards wrt generic keyboard/automation tooling.

Kanata supports early tap-hold dispatch based on key overlap, which is all I need. There's an open issue for more advanced conditions: https://github.com/jtroo/kanata/issues/128

The maintainer has been very responsive in my experience and would probably add more advanced conditions if someone wanted them.

> There are way too many interactions for me to list

Sounds like mostly hackarounds for non-keyboard-friendly software. I generally prefer to use keyboard-friendly software (of which there is no shortage on linux) and just make application-specific keybindings directly in each application. Anything else is inevitably a hack. Window management, browsing, anything related to text or programming, etc. all have good keyboard-friendly options. I have to use some stuff like excel and teams for work, but I'll just use the mouse more in those cases. I don't spend a significant amount of time dealing with applications like that though, and e.g. for Teams I'd try set up a matrix bridge or just use warpd before trying anything else.

Teams no longer supports linux, but for other apps that have non-customizable key shortcuts, it's definitely possible hack around that and create your own in linux. E.g. When I used to use libreoffice regularly, I set up modal keybindings that sent the corresponding chords to libreoffice.

As long as I can use my editor to type anything non-trivial, I'm good. For example, you have generic software like sketchyvim on mac to essentially use vim in any input field. I don't think there's a linux equivalent that lets you essentially embed an editor like vim inside any input field, but you can use a generic keybinding to open one and then have the text sent back when you're done.

A lot of the examples you list don't seem to need any app-specific or context-aware functionality (e.g. your launcher example). I don't have enough of an idea of what you actually want to know if what's available on linux would support your use cases, but in addition to the numerous basic hotkey daemons there are programs like keyszer that support application-specific keybindings ootb or hawck which is scriptable in lua and supports conditional keybindings (allowing you to script per-application keybindings). You have some context available but only what is externally available, i.e. unless the program provides some way to interact with it like a cli utility or ipc socket, all you're going to be able to do is send input to it.

I never looked at karabiner's full functionality, but kanata is the closest thing to a linux version of QMK. It can kind of be used for hotkeys, but that's really not its purpose. Better to use a separate hotkey daemon.

Keyboard Maestro would be replaced by one or more completely different tools. There are programs that allow application-specific mapping. I've never seen the point of it, so I can't comment if any of them are any good. What are you looking to do? As someone who uses the keyboard for everything, my experience so far has been that macOS is much weaker at this.

Delays are a terrible solution. Looking at key overlap percentage, for example, works much better. There are a lot of other ways to make dual-use/tap-hold functionality more reliability, but lots of programs actually implement overlap checks. The kaleidoscope keyboard firmware, for example, lets you configure a minimum overlap threshold for a key to start acting as its secondary role (e.g. only have space act as a modifier when it is pressed first and is held for 70% of the time the second key is pressed).

In your case, I'm not sure why you would need to roll over to other keys from escape. My shift key doubles as escape, and I don't use any delay or checks at all since I don't rapidly type escape then other keys. In any case, you could try configuring your capslock key to only act as control if it being held fully overlaps with the next keypress. Not sure about keyd, but kmonad and kanata both support this (I'd highly recommend kanata). That may require changing how you type depending on the modifier, which is why more fine-grained overlap threshold checks can be useful.

Relevant github issues:

https://github.com/kmonad/kmonad/issues/351

https://github.com/jtroo/kanata/issues/128

I've tried about ten billion different tools on linux and can confirm that kanata is better than everything else mentioned in this thread and a lot more. It's not the right tool for global hotkeys, so it's not going to completely replace something like AHK or wkhd, but it's basically the closest thing to QMK functionality for a laptop or non-programmable keyboard.

I've used both. Mu4e is a lot simpler for email. I plan to eventually switch to Gnus for everything since it handles so much more than just mail (feed reader, hacker news, reddit, twitter, newsgroups, etc.), but mu4e is much easier to set up. Gnus really shines when you need to deal with a higher volume of messages than you will ever read.

Mu4e now uses Gnus' code for viewing emails by default. Mu4e's headers mode will look a lot nicer than Gnus' article mode though.

Gnus is massive and has a huge learning curve. It would be great if you are working with very active mailing lists. If you're dealing with a small amount of email, there won't be much benefit.

Emacs is not multithreaded, but it has supported async/cooperative threads for a very long time (at least since before I started using it almost a decade ago). Modern packages are generally written to not block while doing something like fetching updates. Gnus still blocks. Someone rewrote it to no longer block, but it is a very large change, and GNU Emacs is unlikely to have non-blocking Gnus anytime soon. I just run Gnus with a separate daemon.

> how many actions it takes to achieve something

This is not really objective because you also have to take into consideration how intuitive/simple the UX is. Given 100 related actions, clicking through a logically grouped nested menu or multiple pages to do something is going to require more steps but be something anyone can do. Memorizing and using keyboard shortcuts for all those actions will be more efficient, but isn't something someone could immediately do. There is of course an in-between where you can have menus to display available keyboard shortcuts, but some (most?) people will still prefer a GUI/mouse-based approach. There is no one-size-fits-all approach.

Customizability is Emacs' selling point. A higher level of extensibility necessary means a higher learning curve. I'd call it a learning curve rather than "barrier": it's certainly not difficult to make Emacs look good. Most people don't care how Emacs behaves OOTB because they want to customize every aspect of it. You might say it should look or behave better by default, but I'd rather the base stay consistent and simple (it fits the use case better). There are plenty of starter kits/distros that look good OOTB for people who want a better default experience.

Janet's approach seems a little strange to me in that it's opt-in rather than opt-out. In CL or Clojure, you just normally can't have this issue due to the package or namespace system (e.g. you have to go out of your way to define an anaphoric macro that will work anywhere). Clojure doesn't have a separate function namespace either, but since backquote will automatically qualify symbols with their ns unless you opt out, you don't need to use any strange (at least to me) unquoting approach.

The "separate package" issue is really a non-issue, especially in Clojure where you have a different namespace for every file. Some people prefer a separate package for every file in CL, but even with one-package-per-project, you only have to worry about your own code. Anyone redefining functions outside your package isn't going to cause any problems with your macros.

This is not pathological insulin resistance and is an expected adaptation. OGTT is useless for someone on a low carb diet. A normal person can go from failing to passing in ~72 hours by reintroducing higher levels of carbohydrates. Good luck reversing diabetes in 72 hours...

My init files are nearly 10k lines and I have >300 packages. I've never "declared .emacs bankruptcy." Emacs starts in 0.4-0.6 seconds (without the daemon) for me. One reason I initially switched to Emacs was because Vim was comparably slow as hell for what I was doing. That's no longer the case. Neovim and Vim are definitely faster than Emacs, but I almost never run into cases where it matters. Even on my crappy work laptop, the only time I ran into issues with Emacs is when dealing with log files that were gigabytes (in cases like that evil's :g and :s are just unusably slow).

> There's a lot of cargo culted config fragments like the ones you'll find in the article.

Besides changing the gc-cons-threshold (which is indeed a questionable fragment to blindly copy/paste), there were no other specific config fragments, only examples. People blindly paste config fragments for everything (e.g. set nocompatible in Vim).

> Why does every user have to constantly reinvent the same config to work around all of the issues in Emacs?

What is there to reinvent? It should take almost no extra configuration to properly defer package loading. Package loading is also not automatic. If you are explicitly loading every package you've installed during init, that's your fault. You shouldn't blindly copy things into your config. If you really don't want to handle configuration yourself, starter kits exist for a reason.

> In the article the author talks about how he's gone bankrupt three times with his config, maybe that's a sign that the problem isn't the author. If Emacs is that fragile, then its extensibility is really a moot point.

It is mostly a user problem. Emacs lets you do anything. It gives you enough rope to hang yourself with. I could write an unreadable and broken mess of a program in any programming language, but that doesn't say anything about whether a language is fundamentally flawed.

It's a double-edged sword. There's no such thing as bug-free software. And the more functionality, the more room for misconfiguration and bugs. Vim/neovim come nowhere close in terms of functionality. The correct word isn't "fragile." A better word would be "malleable." It's the editable editor. Emacs' malleability is at least part of the reason why it's able to stay relevant despite the fact that it has very few developers compared to Vim and other editors. Because Emacs is this way, it's potentially easier to do something dumb or install a bunch of useless, slow packages, but because Emacs is this way we also have Magit, org-mode, and a bunch of other killer packages that Vim has much worse versions of (or no equivalent of at all).

This means that if you only need a simple setup, Emacs is not that appealing, but my experience has been that I have no idea what I want until I know what is actually possible (e.g. I didn't grok magit until I read the entire manual and saw how greatly it would simplify my workflow).

Recently there is https://gitlab.com/nonguix/nonguix