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.
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.)
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.
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.
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.
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.
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)
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.
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.
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?
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!
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.
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.
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.
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.
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.
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.
I genuinely consider falling into established patterns and modes of interaction (i.e. a cargo cult approach) to be a serious problem for software engineers, including myself. And I think that vi and emacs keybindings are a great point illustrating this problem.
Many years ago, I came across the term "emacs pinky". I thought it was joke, until I got a job as a programmer where I was lucky enough to have free choice of editor, so emacs it was.
My memory is a little hazy on the "when", but I think some 6-12 months after starting at that company, I noticed my left pinky did indeed kind of hurt. Reaching for that Ctrl-key on the far, far left front of the keyboard was getting a nuisance. The "emacs pinky" was real!
I did a bit of research on the Internet and found a piece of text that said, Ctrl used to be where CAPS LOCK lives now, oh, and here's how to make your CAPS LOCK into an additional Ctrl key (I cannot remember a single time I used CAPS LOCK, so I did not exactly miss it). I made the change and found it more comfortable right away.
To this day, the first thing I do on a new computer I am going to use for longer than, say, a week, is to make that little change. My pinky has not had any problems since.
Indeed, the Emacs pinky got me started on a life-long interest in [ergonomic] keyboards. The best solution I have found so far is the Kinesis Advantage where Control is moved from the weakest finger (pinky) to the strongest (Thumb). I also swapped delete and Alt (Meta) so the thumb is use for Meta as well. Fixed all my problems!
Incidentally I _also_ switched to Dvorak too, but only for that keyboard. Works great because muscle memory "feels" the keyboard is different and uses the correct layout without cognitive overhead.
I've started using my palm/the left side of my hand to press ctrl and it works really well, provided you are working on a keyboard with raised keys, not so easy on a laptop.
For me, symmetric C- and M- provides a good layout because I can use either hand for C- or M- and the other for the additional keypress. Having one on either side of the spacebar but asymmetricly located is ok, but not as good.
I have found that having only one C- key on the keyboard becomes uncomfortable over time. For example C-a and C-e and C-x and C-f contort my hand more with only a left hand C- key...looking for this in a keyboard is one of the things I learned from Xah's site.
Yeah, C-n is just _perfect_ to reach. Just thinking of it makes my arm twitch and glow with pain. I am starting to suspect that Emacs original keybinding designer (Richard?) is actually an octopus.
He had a keyboard with important keys on both sides of the spacebar because the assumption was that a user would interact with the computer in sophisticated ways such as or similar to programming. Most current keyboards are designed for cost saving or consumption or just by copying mediocre designs that are common.
I write software for 20 years, I use Linux and OS X as my primary development desktop OS, I have used Slackware Linux 1.0 back in 1995, I am a touch typist — but I just can't stay using Vim or Emacs, unless forced to (such as when I have to quickly edit something on a remote machine).
Yes, I might be a special snowflake — most developers don't have problems with vim or Emacs, expect for occasional flame wars between the two. But I do, even as I tried to make the switch like 20 or more times.
My comment was only to clarify that the keyboards have changed over the years and that historically, there was a more rational basis for the keybinding ergonomics than it might seem today. Part of the reason that Emacs is configurable is that there were lots of different keyboard layouts many years ago and the design view was that there is no one right way. One of the things I like about Emacs is that the philosophy of many right ways is consistent with mine and I don't think there is one right way of editing text and hence there is no one right text editor.
What I like about Emacs is that I can use it with just about any programming or semi-programming language I come across without having to learn a new IDE or editor. The other thing I like is that the capability ceiling of the tool is so high that I am constantly making significant progress in terms of efficiency. So the cost of learning it, was and is worth it for me. If I was writing Java or C# or Pharo most of the time, I'd probably uses different tools.
Why would you even try to make a switch to Emacs? It's kind of ok as a text editor, but, by default, it's nothing special. The default keybindings are stupid all the time they aren't malicious, that's true, and it has other problems, like archaic UIs (eg. completion, M-x, Speedbar).
The situation changes drastically once you account for two things:
1. The plugins. I said it many times already here on HN, but my Emacs is running 900k loc of Elisp, where more than 500k loc are plugins (or extensions, applications, and libraries). When modern packaging systems appeared, for both Emacs and Vim, their ecosystems were already formidable - it only got better since then.
2. Customization. It's not, in my opinion, worth learning Emacs if you're not going to customize it. The defaults are awful, that's one of the few things I agree with Xah on. But the ease of configuration and extension makes up for it if you're willing to put some hours into it. Not into "learning Emacs", but into "learning how to customize Emacs". The latter - if you're a programmer - is also more fun than memorizing arbitrary keybindings which don't necessarily make any sense for your keyboard, hand size and other factors.
It's, of course, a trade-off, as you have to put some effort into it and you're starting from a rather low point. You could try one of Emacs "starter kits", but, honestly, they involve just as much memorization as the vanilla version and (as mentioned) I don't find it fun at all.
Still, the smoothness of your workflow that you can achieve with Emacs once you do customize it is astonishing. It's still not pretty like VSCode (just one example I recently played with), but it doesn't have almost any limitations to what it can do with a single press of a key. It can make minutes or sometimes hours of your work time collapse into seconds (well, as long as you tell it how).
If you didn't already - if anything I wrote here is news to you - you could give Emacs another try. Of course, if you're not opposed to spending some time tinkering with it until it feels just right.
In my experience yes, most people do touch type, and no, most people don't use right control much, if at all. The right control key on many keyboards is already so uncomfortable to reach that even single-hand chording with the left hand feels better. Using caps lock as the control key makes it even easier to completely avoid the right control key.
However, I have also seen mention of people remapping return to the right control key, then doing who knows that to still be able to press return.
The cheapest solution is the Microsoft Natural Ergonomic 4000 keyboard <$40 US with symmetric keys. For laptops, most Thinkpads have symmetric keys. Others, such as Dell Precisions have left and right control and alt keys, but they are not symmetric...better than one though.
Speaking of touch typing, the TrackPoint between g and h is also helpful. Thinkpads and Dell Precisions typically have one. Some Toshiba's also. Though this sort of assumes that keyboard is a primary driver for a laptop purchase.
I don't understand your questions. What would touch typing have to do with it?
And you can still use right control when typing a letter with the left hand. When pressing control-<right-hand-letter> you have less stretching. I've subconsciously over time found that I mostly do single-handed cording with control-<left-hand-letter> though since the control location is so much more convenient than the shift location (for me). Your milage may vary!
While I certainly do touchtype, I never taught my right hand to contort itself to reach control or shift. I occasionally press right alt with my thumb, but that's about it.
Mapping caps to control makes my keyboard a bit more usable, but it is still fundamentally flawed in a variety of ways.
That is probably one of the reasons ergodox (or similar) is so appealing to me.
I agree, modern keyboards are not perfect. But they are more intuitive and approachable than those monstrocities (I started with one of these — and when a modern Model M layout finally appeared, it was a pure bliss).
Do you have better designs? If you're using Emacs-style editing, you want Ctrl shortcuts. If you're using vi-style modal editing, you want single keys to move around. What would you recommend?
Note that moving your hand to the arrow keys is, while more intuitive, slower and requiring more thought than the other options presented (once these options are learned).
Mac default keymap looks intuitive enough for me. Opt+arrows for skipping words, Cmd+arrows for sentences. Beats absolutely arbitrary Ctrl-A/Ctrl-E and ^/$ definitively.
(I am a proficient touch typist, but I can't adapt to hjkl in lieu of arrow keys — not to mention the context shifting overhead for two vim modes).
Is holding down one or more modifiers and pressing a key not a similar context switch? Typing 'v' enters a 'v' character, cmd/ctrl-v pastes from the clipboard. There's no logical connection between the two except that you've probably had that one memorized for decades. The difference in vim is that you don't use modifiers when you're in normal mode (usually).
Side note: TWO vim modes? I guess you're never had the pleasure of stumbling into ex mode
Control keys are relegated to the edges of the keyboard and easily remembered and distinguished by touch, as there are only few of them. Cmd+X, Cmd+C and Cmd+V is much more convenient, memorizable and logical (X and V visually look like editing marks on paper, for cutting and inserting respectfully; C is for Copy), than... how do you copy-paste again in vim? v/y? I see no logic there. Yes, I remember that v is for "visual selection", and y is for "yank", whatever it is... but it is way less logical.
Remapping vi's escape function to caps lock or jj/jk seems like a common example, or doing it the other way around and getting a HHKB. It doesn't have to be a wholly different style, just one that fits modern keyboards.
Having used a HHKB, the arrow keys and page/home keys are aggravating to have to chord when you are in a program where you can't remap to the expected key combinations (and the chords all have to be done with just the right hand, unless you want to give up your CMD/Windows key).
The swap of del and '\' is annoying too, and creates problematic muscle memory that will fail you when you're forced to use a normal keyboard.
That's a bit of an oversimplification. Especially given how none of those keyboards look THAT different than what we use today. In particular, Vim's use of the home row for movement is objectively better than moving your hand off the home row and using the arrow keys (which you can do if you wish as well). I'm sure if someone was creating Vim today, they might choose WASD instead since many are familiar with the use of those keys for movement in gaming.
I would prefer they pick jkl; instead of hjkl. I'm not a fan of shifting my right hand left and even less enthused about forcing my index finger into double duty on jh.
As a long time vi and vim user, I disagree. Learning the keys tends to happen in stages (with arrow keys being stage 1) and reliance on hjkl is not the final stage. When you truly master vi/vim you barely use hjkl at all. Instead, you use fFtT/?nN;, text objects, addresses, and marks. These tools allow you to move to places in text and make changes at a glance without dealing with all the characters or lines in between.
But you have to relocate your hand from the home row to use arrow keys. Arrow keys are great and all, but the vi/vim benefit to home row arrows is a lot less travel for your (usually) right hand, which can be a great ergonomic win.
I think the main difference between the vi(m)/emacs users and others is that they actually use the keyboard as their general home more. Not just programmers, but sysadmins, office workers, etc, spend far too much time in habit-formed inefficiencies of input.
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