History of Emacs and vi Keys (2010) | Hacker News Reader

History of Emacs and vi Keys (2010)

xahlee.info

130 pointsMcMini85 comments

Neither Emacs nor the control/meta keys were invented on Lisp Machines. Emacs was written in TECO on DEC's PDP machines.

The control/meta keys actually date back to Professor Wirth at Stanford. The Stanford keyboard had control/meta then. MIT then had it in the form of the Knight keyboard.

http://www.lysator.liu.se/hackdict/split/bucky_bits.html

Control as a modifier key (not a bucky bit) certainly predates that, if the dates in the link are correct.

Double Bucky

(Sung to the tune of "Rubber Duckie")

    Double bucky, you're the one!
    You make my keyboard lots of fun
      Double bucky, an additional bit or two:
    (Vo-vo-de-o!)
    Control and Meta side by side,
    Augmented ASCII, nine bits wide!
      Double bucky, a half a thousand glyphs,
               plus a few!
        Oh,
        I sure wish that I
        Had a couple of
            bits more!
        Perhaps a
        Set of pedals to
        Make the number of
            Bits four:
        Double double bucky!
    Double bucky, left and right
    OR'd together, outta sight!
        Double bucky, I'd like a whole word of
        Double bucky, I'm happy I heard of
        Double bucky, I'd like a whole
            word of you!

(For those of you who are interested, the term "bucky bits" comes from Niklaus Wirth, known as "bucky" to friends, who suggested that an extra bit be added to terminal codes on 36 bit machines for use by screen editors.)

http://www.art.net/~hopkins/Don/text/double-bucky.html

Interesting to see the Symbolics keyboard. As an Emacs user I had reprogrammed my ThinkPad keyboard (Windows) so that

Alt -> Control

Windows-key and Menu Key -> Alt

Control keys -> Windows key

So without having ever seen a Symbolics keyboard and without knowing the history behind emacs keyboard layout I remapped my keyboard so that I had very quick access to Control and Alt (= Meta) keys.

On my Macbook it's not that easy. I could remap the Command key to become a Control key, but many Mac shortcuts heavily rely on the Command key. So that's no option.

I used "Keyboard Maestro" for this. I tried out some other tools, but they mostly didn't work or were too bothersome to configure. It's definitely worth the cost, as it made a Mac usable to me, although my keymap is quite different from yours, which is kind of a point with this kind of software :)

I was using Linux and StumpWM (a Common Lisp/Emacs-based WM, and Enlightenment before that) for a couple of years, so I thought that full support for personal keymaps is a given in any serious computing environment. I was pretty shocked to learn that on Mac OS you can do very little keybinding, if exchanging a few keys positions can be even called that. Fortunately, it looks like I'm going back to Linux soon.

There is Karabiner for Mac. It let's you remap every key of your Mac. For instance I remapped the enter key to behave like a Control key if I use it in combination with another key. Otherwise (if I just hit enter it behaves like the enter key)

It does not work on Sierra yet.

I know and I haven't updated to Sierra just because of that. If I knew that Keyboard Maestro gives me all of the features of it I'd even pay fifty dollars to get it.

Karabiner is a disaster.

From the configuration file format, which is XML but not really, to the fact it doesn't work for Sierra and it won't work for Sierra because the author(s) decided to rewrite the whole app and stopped updating the original one, to the GUI straight out of the 90's... I can't find any other word for describing it. Disaster fits.

Keyboard Maestro is a paid app. It's reasonably cheap, but as a long time Linux user, I was shocked I need to pay at all for something I'd consider an essential part of the OS. But you can try KM for free for some time and decide if it's worth its price. Personally, I'm very happy with it. Its UI could be a bit better, but its functional and lets you easily add and organize your own mappings. Karabiner, on the other hand, is a giant blob of pre-defined mappings you can disable or enable (and adding your own is a pain).

The rewrite of Karabiner promises some of the features of Keyboard Maestro, but it's still underway.

Worth noting that Mac lets you remap the control, alt, and cmd keys to one another. It's been hidden in the keyboard settings under a "Modifier Keys..." button for a major version or three now, and is stored per keyboard (nice for mechanicals with a keycap swap).

The new MBPs (possibly anything on Sierra?) add CapsLock as a mapping target and both CapsLock and Esc as a mapped value, presumably to get around only having the soft Esc key in the touchbar. It's also nice for Esc as meta, though.

That obviates the need for Karabiner in the 99% case, though I still use Keyboard Maestro for macro and text expansion.

> Worth noting that Mac lets you remap the control, alt, and cmd keys to one another.

Yeah, but that's all it allows you to do. In other words, if you exchange Ctrl and Cmd so that "normal" Ctrl+c/Ctrl+v works you need to press Ctrl+space for Spotlight. I don't want that. I want to leave Ctrl where it is, and only make Ctrl+c/Ctrl+v (as an example) behave as expected.

You might be able to put "symbolics" keys on your keyboard: https://deskthority.net/photos-f62/round-6-the-cappening-t15... Don't make the mistake I did and focus too hard on the tool and not enough on the work :)

The most important thing that distinguished the Lisp Machine keyboard was that it had dedicated parenthesis keys. According to my sources, that was so you could hold a Hefty bag of nitrous oxide in one hand, and type s-expressions with the other. (Gumby can you verify this? ;) )

I have a new style Symbolics keyboard. This one has a very sharp front and a heavy metal body. From time to time it serves well in a guillotine, executing obnoxious unix weenies with a Lispm keyboard.

As a tmux/vim user those extra control keys look amazing, there are too many layers fighting over too many control keys in my current setup, I'd love to have something like a dedicated vim accelerator, a dedicated tmux one, a dedicated console one and a dedicated desktop manager one.

Is anyone selling keyboards like this? What happened to those really expensive customizable keyboards from a few years back?

Emacs user? Get a Japanese keyboard.

That's my number one piece of advice after two decades of Emacsing and one on a Japanese keyboard.

Japanese keyboards have a much shorter space bar with extra keys on either side. Remap these to control, hit them with your thumbs, and experience bliss.

I used to get 'Emacs pinky' quite frequently, but never since the switch. If you think about it, it makes all kinds of sense:

- your thumbs are strong and dextrous but totally underused in a traditional layout - most space bars are ridiculously large.. wasted real estate - your non-spacebar thumb can comfortably rest on a ctrl key so there's often no lateral movement at all

Fascinating to see others thinking along the same lines as me with keyboard remapping, and also to discover that all this time we've been trying to get closer to the keyboards of antiquity!

Previous thread

https://news.ycombinator.com/item?id=6056420

Any idea why the period became repeat in VIM? I've checked through old manuals, and can't quite figure out where it came from.

In command contexts "." refers to the current line (e.g., :.,$s/a/b/ will perform the a -> b substitution from the current line to the last line of the file). That comes from ex which likely copied that from ed. I've seen "." used similarly in other contexts. 8-bit Microsoft BASIC used "." for the current line -- "LIST ." would list the last line that had been listed or edited. A number of assemblers use "." for the current assembly address.

The point being that there is a bit of a tradition of using "." for "the current thing" so there's a sort of sense in using it for the most recent command.

If you're really curious get in touch with Bill Joy.

Also ./ for the current folder is still used on all OS's. I think your examples predate computers having folders though.

UNIX's ‘.’ predates Microsoft BASIC. (Possibly inherited from Multics, but I don't know.)

I was thinking more of ed, for some reason I thought folders were a later invention, 70's or early 80's, but they were first used in 1958: https://en.wikipedia.org/wiki/Directory_(computing)

Vi is a poor implementation of a great idea.

I would really like a modal editor in which I could configure the behavior for each key, maybe even define more modes and composable functions.

  :help map.txt

Yes, I am well aware that I could remap everything. It's still not as malleable as I would like.

What exactly is missing? The tinymode, the tinykeymap (and others) plugins emulate some sort of temporary modes.

Rather than map over already-defined keys, it would be nice to have a clean slate to work from.

So, "I want cake! Ok, here is cake. No! I want it to be feed to me also."

Sometimes, you should accept the 80% (or 97% in this case) solution and not pine for 100%. Or, scratch your own itch instead of whining no one else is offering to.

> Or, scratch your own itch instead of whining no one else [who] is offering to.

I'm working on it, but these things take time.

I don't see how it hurts to express my thoughts here. I wasn't asking anyone to do anything, just expressing something that I want, in case it already exists, or there are others who share my desire for it.

So, you want an editor that doesn't do anything when you press a key? I'm not sure if such an app would have many users. :-)

You would define the behavior yourself, or (more likely) load a set of defined behavior.

I've seen some work like this with 4coder. Having extensions written with native code that is dynamically linked makes this sort of thing make more sense if you want to minimize lag.

4coder is still very alpha at this point is easy to break but the low level primitives exposed leave it open for easy experimentation with little cruft to peal away first. It also very C++ focused so YMMV.

Emacs? It has a gajillion modes.

Yes, but they all have the same keybindings. I'm really not a fan of C-x everything, or C-[npfb] (especially since b is hard to reach), etc.

In Emacs, it's really hard to create completely different keybindings, because as soon as you enter a new mode, it defines the same original keybindings for new behavior.

I smell an Emacs user!

Emacs has the same problem. The best editor for Emacs is the vim emulation evil-mode.

what is the difference between "backspace" and "rubout"? the emacs keyboard had both it seems, but wouldn't they be doing the same operation?

Since that keyboard does not seem to have a “Delete” key, I assume that “Rubout” performs that function.

This is probably a holdover from typewriters. Backspace moves the cursor. Rubout erases.

On an ASR33 Teletype, backspace simply moved the carriage one character position to the left.

Rubout was a different concept entirely. The ASR33 had a paper tape punch and reader. The Rubout character was 0x7F, i.e., it had all bits set. So, to "rub out" an erroneous character from the paper tape, you could back the tape up in the punch to the desired character (by pressing a button on the punch; there was no character that invoked this function) and hit Rubout; this would punch the tape at all seven holes, changing whatever character had been there to a Rubout. (The software ignored Rubout characters on input.)

When the world moved on from Teletypes, it was natural for people to want a single keystroke that meant "delete the previous input character". But there was evidently some divergence of opinion in the industry as to whether that should be Backspace or Rubout -- notwithstanding that the ASR33's concept of Rubout didn't really map at all onto the new hardware.

  > notwithstanding that the ASR33's concept of Rubout didn't
  > really map at all onto the new hardware.

If you are working with paper tape, Rubout (DEL in ASCII parlance), like every other code, advances the tape when punched. So, if the tape is a stream of characters, DEL erases the one under the cursor and leaves the cursor on the character formerly to the right. That is, Rubout/DEL is defined as a ‘forward delete’ operation, and that's something that remains useful.

That leaves Backspace as the natural choice for entering ‘backward delete’ on a keyboard, at least after 1979 when you have the ANSI X3.64 escape sequences for explicitly nondestructive cursor keys. I think there's a reasonable argument for Backspace being nondestructive for overstrike effects (accents, underlining, APL, etc.), especially when received by a terminal, but I know none for changing the meaning of DEL.

> On an ASR33 Teletype, backspace simply moved the carriage one character position to the left.

Exactly what a typewriter would do because it couldn't erase the ink on the paper.

I never understood appeal of wasd. Maybe my fingers are shorter. It's way easier for me to have all three on same line so I change S to fwd and X to back.

Reply on news.ycombinator.com