Also note the correct position of CTRL. Why it's only the HHKB that gets it right today is beyond me. Caps Lock has no right to be on a modern keyboard.
Modern keyboards shouldn't still be designed to minimize typewriter jamming; they should instead be designed to be comfortable to use. I switched to a split (because I have two hands), columnar (because my fingers do not angle to the left), Dvorak (because most of my typing is English-like) layout, and my hand and back (!) comfort has greatly improved.
Funnily enough though, even with all that, I still have a caps lock key. It's on my thumb cluster, and it doubles as my Alt key if I hold it. I use it for caps lock probably a few times a week. I get not putting caps lock where it commonly is on keyboards nowadays (I have control where it commonly is too), but I actually don't agree with getting rid of it entirely.
i don't think anyone is necessarily saying we need to get rid of caps lock--afterall, we still have scroll lock (side note: I often use the scrolllock button as a button to trigger screen recording. the light on my keyboard is a visual indicator of recording).
just that it doesn't need to be in such a promient position.
My capslock is actually escape, which is much more useful. The only thing I'd say is, esc is sometimes an overlooked button in software because it is so out of the way.
On a more physically conventional keyboard without a thumb cluster, esc seems (oddly, given the switch) like a great spot to put a rarely-used key like caps lock.
Tab is a bit of a an odd one. It is useful for printing, but almost entirely useless as an input… so useless in fact that it has been repurposed for auto-complete, which is really useful!
Which leads to my gripe about how web forms and forms in other apps usually ignore tab order and often even the idea of tabbing between input fields altogether.
Also, I've been using tabs for indentation (with spaces for alignment) in code for decades. Though linters are slowly killing that.
My biggest complaint of modern keyboards is pinky overloading off the home row, particularly on the right hand side of the keyboard.
My second biggest complaint is that CTRL and ALT keys are the second most important after the SHIFT. But on the laptop I'm typing on, they're super small and placed under the hands, and there's a FN and a WINDOWS button between them on the left hand side, making it hard to hit unless you pull your hand off the keyboard so you can see.
The last complaint is doing super spock pinches for weird macros. CRTL-ALT-SHIFT-Z. The last could be fixed by composing, and not requiring the three keys be pressed down together. The SHIFT letter combinations came from the old typewriters where SHIFT key raised the letters so the upper case keys could be struck. And we've stuck with that for better or worse.
Since I don't know many people using MacOS, I didn't know this was a thing. But it appears to be a UX problem with that particular OS rather than a problem with the existence of the capslock key.
Ergonomically the position that Mac keyboards position the Command key (their Ctrl equivalent) I feel is better, which is to the immediate left of the spacebar.
With the Caps Lock position one has to use the pinky to hold it down and the index finger has to stretch more to reach Ctrl+V (unless some use their thumb to hit the V key?). While with Mac style placement you use a thumb for holding the key which naturally occupies the bottom-most row for spacebar, so less finger travel and stretching.
For most Mac applications I've used the equivalent Ctrl+<key> functions are mapped to Cmd+<key>, most obviously for cross-platform applications but also generally copy/paste/etc.
My comment was just about the positioning of the key however. I use a keyboard with programmable firmware so I can remap the actual Ctrl key to the same position since it's more comfortable.
In the Mac world, Command has always been the standardized main hotkey ingredient for every GUI application. Of all the Mac quirks, it's the most fortuitous one in my opinion that they started out with only Command (and Option*), since they only had the GUI, then when they were in a mild "compatibility" phase in the 90s they were able to separately add Ctrl and define Alt as a synonym for Option.
Historically pre-UNIX-based-OS Ctrl was lightly used in massive applications that needed more hotkey possibilities (e.g. Photoshop), or used for running PC emulators like Virtual PC. And for the few people on Macs using a terminal to connect to Unix hosts.
Then Mac OS X hit, and it was a happy coincidence that now in a Terminal, you can hit Command-C to copy some text, completely outside the scope of the process running there, or separately, do a Ctrl-C to break the process.
*Mac uses option (Alt) at the OS layer too, but it's to compose variøüs diacriticals and (√•§¢) symbols, so it's highly frowned upon to use "alone" (as in "Option-V" because that should be dedicated to making the √ symbol) - but it's frequently used in combination with Command.
It's used for OS-level commands: copy (⌘-C), paste (⌘-V), select all (⌘-A), page up/down (⌘-shift-up/down), paste as plain text (⌘-shift-V), Spotlight search (⌘-space), show all windows (⌘-up), show application windows (⌘-down), search app help (⌘-?), move desktops (⌘-left/right), etc. etc. etc.
Caps lock works only on letters, shift lock on everything that has a different meaning when shift is pressed, so also the numbers, symbols, function keys, etc.
I don't know about the C64 implementation, but some Shift locks also acted as a shift toggle rather than just "all caps"/"shift stuck", so you could use shift to "unshift" during shift lock to get a lowercase letter or a number.
Yes. On a physical typewriter, the shift was raising the whole typing carriage to get to the lower part of the striker (I don’t know the right vocabulary) to hit the ribbon. It was heavy. So to do several in a row, a shift lock was provided. Because of how it worked physically, it was indeed shift lock rather than caps lock.
I guess someone decided “why not ‘shift lock’ just for letters?”
IMO the IBM Model M keyboard popularised the incorrect position of the Control key; its predecessor (Model F) had the Control key in the correct place.
It's why I bind caps lock to control and tab to escape. I also got a programmable keyboard so I can make my escape send alt when combined with another key, and also bind C-i to tab.
Then xterm turns alt-<key> into ESC <key> with metaSendsEscape, and tab sends ^I since it's the same in ASCII, so I can deal with CUA interfaces without any change in terminal behavior.
I wish I could remap the fn key on my keyboard (Lenovo Trackpoint II).
First, I’d like to swap the control and fn keys.
Then I’d like to be able to use the fn modifier in keyboard macro programs (like AutoHotkey on Windows). There are a few already configured (like fn-S for print screen) but most of the fn modified keys do nothing and that feels like a waste. For some reason, the fn key mostly seems invisible to the OS (and it doesn’t seem to matter which OS I use.
I picked up remapping Caps Lock as an extra Backspace. Turns out Backspace is a very common key while typing sometimes and it can be very nice to avoid the hand movement/extreme stretch. I don't think people often realize they use Backspace far more than Ctrl or Escape, because it is so common it starts to be a very "unconscious" key.
It was a million years ago so my memory may be incorrect. But, I vaguely recall in some first person shooter, probably Quake, the shift key was (or could be mapped to) spring. The way it was implemented, you could use Caps Lock as an always-spring button. It was nice in the days when they were still working out the details of game controls, haha.
Then how would you type uppercase letters? /s
But on a more serious note, it does appear that some people are not aware that the shift key capitalizes letters and exclusively rely on the caps lock key.
The Home key on the ADM-3A is also the key where the tilde is. Interpreting "~" as "home" means that there is a mnemonic for "home" built right onto the keycap legend.
The world would be a better place if `jkl;` took off instead of `hkjl`!
It's impossible to switch now since everything uses `hjkl` despite some people trying (for instance, the default navigation keys on i3wm are `jkl;` but everyone always changes it to `hjkl`)
Not the whole world; on my keyboard 'hjkl' is 'hjkl' but the other thing is either 'jklé' or 'jklö'. (that said, there's nothing to be done about 'ролд')
I use Karabiner Elements on my Macs to bind right-side Command + hjkl as arrow keys throughout the system and it’s magical.
I also use Karabiner Elements to bind Caps Lock as a Hyper Key, and then I use Keyboard Maestro to remap Hyper Key + the j/k bindings above to backspace and forward delete.
It's also worth noting that the ADM-3A terminal may have chosen H/J for left/down due to ^H being backspace (like left) and ^J being newline (like down) as well as being on home row.
I think it would provide very little productivity boost if any (is anybody’s work seriously bottlenecked by the time it takes to find the navigation keys? What are they doing?). But also, I can’t think of any reason not to use the keys that you rest your fingers on for navigation. I mean, why not?
A good argument could be made that vi is all about the typing speed boost you get from not using a meta key like control (or later alt or fn). The specific keys didn't matter, although having them near the home row is helpful.
Vi has the same model input model as teco/xtec and shares their key press economy. Emacs which started life as a teco macros went the other way. Decades ago I tried both and abandoned Emacs when the finger in charge of the control key started to ache. It was not just slower, it was painfully slower.
The article does not draw any conclusions on whether hjkl navigation leads to a productivity boost or not. I’ll just say, it certainly feels cozy to have navigation where your right hand is meant to sit according to touch-typing canon. Maybe that’s why they put the arrows there in those legacy keyboards in the first place.
Then jkl; would make more sense, since it wouldn't require moving one's right hand from the home keys on a QWERTY keyboard. If I'm going to shift right anyway U for up, H for left, J for down, and K for right makes more sense (like arrow keys).
