Show HN: Devil Mode: A twisted Emacs key translator for modifier-free editing | Hacker News Reader

Show HN: Devil Mode: A twisted Emacs key translator for modifier-free editing

github.com

50 pointssusam56 comments

This could be done more cleanly in keyboard firmware.

I recovered from a deep dive into mechanical keyboards by trying Topre switches, the obsession killer. I now have four Leopold FC660C keyboards with Hasu FC660C controllers, with custom QMK firmware.

After many experiments, I've been won over by making every key near home row a "tap / hold" key. Tap for usual keystroke, hold as a modifier to access a custom keyboard layer with the other hand.

This is an empirical question. I've learned chording keyboards. I had the original FingerWorks TouchStream multitouch keyboard, tech which Apple turned into the iPhone. I've owned various ergonomic and small keyboards. I've tried many versions of my own firmware. I learned Dvorak on a one-handed half keyboard, and experienced the miracle of knowing how to type Dvorak both hands with no practice. Brain plasticity is very important to me; I've tried everything I can.

"One finger each hand, near home row" is stripped down chording that wins hands down over any other typing system I've ever tried. Taking advantage of the quadratic address space (versus a linear multiple using a fixed set of modifier keys), I control every aspect of my computer this way.

"Control-Xylophone" has kept me from ever accepting Emacs. I should write a two finger chording interface to Emacs, in the spirit of Devil Mode.

Leopold FC660C Mechanical Keyboard https://mechanicalkeyboards.com/shop/index.php?l=product_det...

Hasu FC660C Controller https://1upkeyboards.com/shop/controllers/fc660c-controller/

Do you mind sharing your qmk config? I'm using homerow for modifiers and combos for symbols, barely using any layers. Though idea of ditching homerow modifiers for layers not crazy since there is no arbitrary modifier need (cmd-c t etc can be thrown into a layer)

Nice! Years ago I added home row chording to a simple text editor I was writing. It worked so well that I wondered why it's not common practice. You should write more about your project! :)

I will echo another commenter, I'd love to hear more about how you arrived at this, and what your current practice looks like (the theory of operation, if you will).

I'd love to try and sort something like this out, but I'd need to consider where the chording is scoped. I run i3wm/KDE Plasma and emacs, and I'm not quite sure where to begin with something like that.

I feel like I'm living in both the golden age of ergonomic keyboards (kinesis, ergodox, etc) and the golden age of modal interfaces for Emacs (evil, devil, boon, meow, etc).

Lots of new and interesting HSI ideas today, at least for us Emacs users.

what is HSI?

For the past couple years, I've been using this hacked version of xf86-input-evdev (by Teika Kazura), which allows the use of a space bar for the space and as a "control" modifier if held: https://github.com/lambdaloop/at-home-modifier-evdev

I made a small modification so that if the space key is pressed shortly after a regular character, it just inserts a space immediately. This makes typing feel more natural, with spaces inserted as usual.

I like this better than using the comma as a modifier, as the space bar is nicely positioned on the keyboard to take advantage of your thumbs already.

Day to day, it's such a natural extension that I forget that I have this on. However, this is the first thing I install when I set up a new computer, as otherwise a lot of shortcuts are much more strenuous.

Edit: I just realized that, while editing this, I've been pressing space-backspace (aka ctrl-backspace with this module) to delete whole words. I guess it's fully ingrained now!

This is an heir to a long history: many keyboards did not have a meta key (in fact had only a seven bit connection to the host) so you could type escape as a way of saying “treat the next keystroke as having its meta bit set”.

And escape itself was just a fallback for altmode if all you had was an ascii terminal.

On a standard MIT-AI TV keyboard (Knight keyboard) you could type M-Altmode to get a minibuffer and just type some TECO for immediate execution — if you wanted to cancel you you’ll press escape, which was the original semantics of “escape” anyway. Compressing that to a standard ASCII character set probably made emacs a little more obscure for people who didn’t have a mental model of using it on a more capable keyboard.

Indeed. A really easy way to test this out on a modern Unix-ish system is to launch a terminal emulator, run cat, and then type Alt+a followed by Esc a. And then for bonus, type Ctrl+[ a. The output should look like this:

  $ cat
  ^[a^[a^[a

Interestingly, on my Linux setup, Alt-a gets me this for left and right Alt:

Ubuntu 22.04

I set up PrtSc as a compose key and have an .XCompose file, but that still works.

Through a little playing around, I figured it out: My Alt actually is a Meta key, in that it sets the high bit. Convert the resulting eight-bit value to UTF-8 and you get the observed behavior: 'a' is 0x61 (0b01100001) and 'á' is U+00E1 (0b11100001) in Unicode.

The postition of the comma key doesn't (to me) feel a lot better than the normal position of the CTRL key. I remap CAPS-LOCK (which I almost never use or want) to CTRL and that works well for me in emacs to reduce finger contortions. It does create minor annoyances when I have to use a computer where this isn't the case, since it's in my muscle memory now.

Using a sequence rather than a chord (or tap vs. hold) makes a big difference and I think it reduces the necessity of having the perfect spot.

The author also mentions in the readme that it was inspired by laptop keyboards that are lacking that right-side CTRL, so even if it's not perfect for the majority of commands, it adds a little flexibility.

Here how it's better:

- stronger hand - stronger finger - better vertical movement instead of horizontal

Reminds me of god-mode: https://github.com/emacsorphanage/god-mode. Although I use Evil, it still comes in handy on occasion when I need to type something without an Evil keybind. Alas, it’s been abandoned, though it still seems to work for me on the rare occasions I need it.

That was the first thing I thought of too. I'm guessing the name itself is a parody, especially given the cheeky readme.

Yes, I had the same thought.

Interesting concept. The constant modifiers in Emacs are really such a turn-off. I want to give Emacs another try, but I cannot understand why functionalities are accessed like this in the first place. In sublime text, with ctrl+shift+p I can access most of the functionalities I need. Still a weird key combination, but sure beat ctrl+x ctrl+f...

Edit: I am still not sure why it isn't just something more direct like ctrl+j, since it is used so much, maybe someone can enlighten me...

ST's command palette is a descendant of M-x in emacs.

Tangent: any tips on how to make the M-x line more usable, similar to a command palette?

I just got started with Emacs, and the archaic terminology and inconsistent naming is causing me to have to consult StackOverflow for basic things like “what are the copy and paste commands called?”. (Those were probably both in the tutorial, but I already forgot them a few times.)

I’m aware of “apropos”, but it also uses antiquated terminology, so it’s frequently not useful to me.

I’m sure this problem has been solved :)

You probably want posframe along with one of the many options for a vertical completion candidate minibuffer (I like vertico), and a package like marginalia to annotate the options like VS Code. A non-default completion-style like hotfuzz, flx, or orderless might also interest you.

I use ivy-mode. Apparently it's not the cool thing anymore, but I use it because it's simple and it works. With ivy-mode enabled, anything Emacs asks you that has a list of options -- so, M-x, file selection, buffer selection, etc. -- will pop up a little menu right in your minibuffer. It should be available in ELPA, with a more recent release in MELPA.

> I’m aware of “apropos”, but it also uses antiquated terminology

can you clarify 'antiquated' for me please

Here’s an example:

M-x, “apropos”, RET, “copy text”

No apropos matches for “copy text”

Using just “copy” returns two undocumented variables first. I did eventually find kill-ring-save, but it took more digging than I’d like. Obviously if I embraced (or at least remembered) Emacs’s terminology I’d have a better experience, but I’m not there yet.

Edit again: “copy selection” found copy-region-as-kill, which is maybe what I should have searched for originally. Not sure yet how it differs from kill-ring-save.

OK, fair enough

I'm sympathetic to this argument but I just searched apropos for "cut" and then for "copy" and got many commands related to cutting/copying text. Granted also that the words "copy" and "cut" don't seem to appear in the results, so you still have some reading to do, but the metadata is apparently there.

What version of Emacs did you try?

Yank instead of paste. Frame instead of window. Kill instead of delete. kill-ring-save instead of copy.

I was going to add 'visit instead of open', but I guess that bit has changed over the years. C-x C-v no longer invokes 'visit-file'.

While I completely get what you're saying it's not really fair to expect Emacs to be compatible with systems that came after it. If you going to work in Emacs you have to pretty much work on its terms, which I think is fairly reasonable and speaking only for myself, I found very worthwhile.

If you think it would make it more accessible to have certain changes, email the Emacs issue/bug people with constructive suggestions and see what they say; they are extremely responsive (then try doing the same with Apple or Microsoft and see what happens :-) )

I'm a happy Emacs user myself. Nobody change anything for my sake.

It absolutely is fair to expect Emacs to use industry standard terminology to avoid confusing users. At this point, keeping the outdated, idiosyncratic terminology and default UI paradigms serves no purpose except unnecessary gatekeeping.

> (then try doing the same with Apple or Microsoft and see what happens :-) )

Microsoft, the authors of Visual Studio Code, the editor most developers use? Whose team has been lauded for being super responsive to developer feedback?

> It absolutely is fair to expect Emacs to use industry standard terminology to avoid confusing users

"Initial release 1976; 47 years ago" (from https://en.wikipedia.org/wiki/Emacs).

There was no such standard terminology back then.

May I recommend you avoid using Emacs to avoid the concomitant headache of getting involved in Emacs discussions, thank you.It clearly isn't for you.

For the record, the intent of my original post was just to see if someone had already encountered and solved my problem (having difficulty finding Emacs commands, due to inexperience).

The use of “archaic”, etc. was meant humorously, and not as a complaint about Emacs. I wouldn’t mind if the maintainers added some more modern synonyms for commonly needed commands, but I wouldn’t expect them to.

The following is my personal experience only. When I decided to learn Emacs I bought a book (the fat O'Reilly one),sat down and practised the keystrokes. I made a few scratch notes as well. Within a few hours, not days, I found movement to be extremely straightforward and much more comfortable than the old windows/mac way, for the great part.

When I was doing my own project I would do most of my work in Emacs but regularly swap back to VStudio because of its LSP support. Swapping back and forth between these two very different environments brought on a few mistakes (wrong key in wrong editor) but astonishingly few. I got comfortable doing switches pretty quickly which is surprising because they are so utterly different, but that's how I found it to be.

I ended up spending more time in VS because of better LSP, but built-in LSP support is coming in the next Emacs. Good. Because once I went back to 'standard' keyboard commands, I never felt comfortable. It just doesn't feel right. Also Emacs is so vastly more capable in some ways it just blows VS away. In other ways VS is better certainly, in the more advanced technical stuff such as LSP, in other ways, screw it.

So: grab a book, prepared to put in a bit of time, good luck!

(Edit: just remembered, I certainly did buy the book but started off doing the built-in Emacs tutorial before that)

That's a very thoughtful response, thanks. It would be nice if I could see into the future to know whether or not my time spent learning Emacs will pay off :)

Good luck with your decision, whichever it is! My only suggestion is avoid Gnus which I found an incredibly flaky mess and regretted ever touching it.

The fact that Emacsen developers started to create text-manipulation terminology earlier is laudable. But it doesn't make Emacsen terms better. From purely pragmatic perspective we have almost a separate language which brings additional barrier for entry, while adding no particular value. I really feel like we stick to sunk-cost fallacy here.

I fear I may be wasting my time replying, but I'm going to try and understand where you're coming from rather than answer your question about Emacs.

Your complaint comes across very much like moaning that strawberries are not the same as cherries. Quite true, and that is exactly why it's a good thing; I would prefer to have a world with strawberries and cherries. Emacs is different from (e.g.) Visual Studio and that's a good thing. Your complaint seems to be that you want Emacs to resemble something else, okay, and after the terminology matches do you want the key bindings to match as well,? And then what do you want? How close in the end, do you want them to look and behave? And if you want them very close, then just use what you're familiar with already and don't worry about us Emacs users.

ISTM you are trying to turn Emacs into visual studio, if not then please make it clear what precisely you want other than injecting phrases like "barrier to entry". Please be specific.

The biggest barrier to entry for you is yourself; the fact that you're not prepared to try something different.

So please tell me, what exactly do you want Emacs to end up looking like, if not a clone of Visual Studio?

I'm not sure if your answer is for my comment, or you posted it to the wrong thread. If it's the former, could you clarify what part of my comment you answering?

You're talking about terminology being a barrier to entry. Terminology is trivial but suppose we changed it (yank -> paste, kill -> cut etc). Now you'll not be happy with the key bindings (C-y to paste, C-k to cut) and want them to be replaced with the Windows/Mac standard – right? Because developing new muscle-memory for a different style of working is a lot heavier than just learning new terms for existing things.

Having done that you'll want all the other key bindings changed surely?

And I can see it progressing from their – Emacs regular expressions don't behave quite like visual studio IIRC, for example. Search and replace is pretty weird if you're not used to it. Rectangular selection is very different in Emacs from visual studio. etc. If you change Emacs you lose a lot of what makes it Emacs, and good.

So if I'm not misrepresenting you, and apologies if I am, I don't see your demands for change stopping until Emacs resembles, perhaps, visual studio, in which case why not just use visual studio?

I hope that makes sense.

Now, it's clearer what you mean. But still doesn't not make much sense, sorry! You apparently see something which I didn't say, and refute something which I didn't say with impressive energy. No, making docs using common terms of today won't make you wish to turn Emacs to Visual Studio, or whatever other IDE you don't like. There are Emacs tutorials written in languages other than English where standard terminology for that particular language used. You know, you would not invent a separate word just to mirror idiosyncrasy of Emacs slang present in English. Trust me, there are no signs that after reading them somebody got obsessed with turning Emacs into Visual Studio.

Then you destroy any remaining trace of a link between the key binding and the action. You can imagine the conversation

"control p to go up? Control y to paste? v to go down – perhaps that's v for vertically down or something? Who designed this crap anyway".

Maybe it would work but I'm not feeling optimistic :-)

Emacs is a programmable environment constructor, ain't it? Significant share of users prefer evil-mode, and use "p in command mode", not c-y. There are people who have custom keyboards (and even pedals) and their bindings often tuned to that fact. So "control y" is not more sacred than the leftmost pedal, and link is ephemeral anyway.

I think the mnemonic link matters for beginners, but let's say I agree with you. By calling the link ephemeral haven't you just undermined your own argument that the terminology is a barrier?

Of course I haven't as I made zero claim about mnemonics. We're talking about readability i.e. cognitive burden which by definition increases with amount of unknown words, or words with unexpected contextual meanings

In the old days, we wouldn't dream of taking up a new editor without first printing out a cheat sheet for it, to have lying next to the keyboard for the first few days.

Yeah I know, archaic terminology: 'printing'. It's a thing we used to do.

By default in Emacs, `M-x` is analogous to Ctrl+Shift+p. Most users like a vertical completion candidate interface for it, such as the `vertico.el` package (among very very many other options). You actually have a ton of control over how this interface works, between `completion-styles` (candidate filtering algorithms, which themselves can be sorted in a hierarchy or even changed dynamically while the menu is open), and various packages like `marginalia` to get richer annotations. You can even dock it somewhere else on the screen using the `posframe.el` package.

Vertico and Selectrum are two modern popular options, Ivy and Helm are two older ones, and there are very creative ones like Raven (https://github.com/chameco/raven) or MCT (https://protesilaos.com/emacs/mct).

Emacs comes with `cua-mode`, which provides some more modern conventions like `C-s` to save, `C-o` to open files, etc., however most users find that the default system does make sense once you learn it. `C-c`, `C-u`, and `C-x` prefixes have very consistent meanings by default across all major modes, and by convention across basically all elisp packages.

I don't use QWERTY, so I find the rebinder package very useful (https://github.com/darkstego/rebinder.el), but I think it can improve the ergonomics of those prefixes across any keyboard layout. My equivalents to `C-x` and `C-u` are on my home-row. I also use home-row mods (https://precondition.github.io/home-row-mods) which make the feel of interacting with Emacs very smooth.

Keybinding discovery is also very easy between the `C-h` family, The `which-key.el` package, and the `helpful.el` package. The `M-x` menu also shows keybindings, even by default.

What's really nice about Emacs is that changing keybindings is very easy, and between hooks, advices, and modes, the keybindings and their behavior are incredibly flexible.

It's a pity all those highly extensible vim/emacs editors ship with such awful unergonomic defaults and are so resistant to change, such a waste of a potential :(

Relevant to this devil mode (and to a similarly named god mode): they do replace the pinky control, but they are still stuck with the default keycaps after that

I wonder how well this would work with SPC as the devil key.

Not at all.

Thumb keys on an ergonomic keyboard are a much better solution to this issue.

This is insane. I am going to try it immediately.

This looks fantastic :))

Well, someone has to say it, right?

"You might as well use vi."

vi doesn't have a good extension language.

(Actual vi doesn't have any extension language, but even Vim lags seriously in this realm.)

Neovim supports lua as an extension language which can be pretty nice. It’s by no means as nice as using a lisp but definitely a step up from viml

I'm pretty impressed by the vim-quickui and (Neovim) conjure packages.

Reply on news.ycombinator.com