Why was '~' chosen to represent the home directory?(unix.stackexchange.com)
unix.stackexchange.com
Why was '~' chosen to represent the home directory?
http://unix.stackexchange.com/questions/34196/design-question-why-was-chosen-to-represent-the-home-directory
16 comments
I learned to use hjkl(yubn) by playing Crawl on a macbook which doesn't have a numpad so it was impossible to move diagonally otherwise.
Nowadays I don't even need to think about using any of those keys for moving around. In fact, I use them in pretty much every application that supports them, including Firefox (with pentadactyl) and less.
Nowadays I don't even need to think about using any of those keys for moving around. In fact, I use them in pretty much every application that supports them, including Firefox (with pentadactyl) and less.
My mnemonic for J/K is that my index finger (on J) is "pointing down".
(I started to write "and my middle finger (on K) is pointing up", but then I realize that an upward-pointing middle finger means something entirely different.. <:)
(I started to write "and my middle finger (on K) is pointing up", but then I realize that an upward-pointing middle finger means something entirely different.. <:)
h and l are obvious for left and right as they're on the left and right. Lower case j goes below the baseline, so down, k is solid at the top so up.
I would prefer JKL; to HJKL because my index finger typically rests on the J. Then again, I am an Emacs user, so what do I know?
As you get more experienced in vim, you learn more powerful ways to jump around horizontally on a line (t/T/f/F, word navigation, incremental search, etc.), so the most common granular cursor movements become down and up -- which conveniently map to the home-row keys under the strongest and second-strongest fingers.
Right, that makes sense. In Emacs I generally use C-n (next-line) and C-p (previous-line), but for horizontal movement it’s usually thing like M-b (backward-word) and M-f (forward-word), or C-s (isearch-forward) and C-r (isearch-backward). Emacs isn’t really as good at raw text editing as vim, but clearly there is a lot more to Emacs than raw text editing.
This is exactly why I don't use HJKL for navigation in vim. Shifting my fingers causes me to mis-type all the other commands. I end up just using arrows or word navigation.
Put this in your .vimrc:
" Disable arrow keys
noremap <Up> <nop>
noremap <Down> <nop>
noremap <Left> <nop>
noremap <Right> <nop>
Every keyboard now has a set of hardware arrowkeys sensibly arranged in an inverted-T, where up means up, left means left, etc. Since everyone is used to that arrangement without any mental effort, macho vim types tell you to force yourself to write with your feet basically to show how hardcore you are. They tell you to use your customization ability in .vimrc to block the sensible arrangement in order to force yourself to learn a ridiculous one that has no advantage other than being the one that we old-timers had to learn before there were sensible arrowkeys.
I used that arrangement back in the 1980s myself, but when keyboards evolved, so did I. I remapped the movement keys to match the other movement keys (arrowkeys).
If you're going to go to the effort of customizing your vim to force yourself to learn a new keyboard arrangement, customize it so that the movement keys are ijkl instead of hjkl, so that both of your sets of arrowkeys are in the same, natural, modern, inverted-T arrangement. Then you don't have to deactivate those real arrowkeys, because there won't be any temptation to use them with the ijkl keys in the same arrangement and easier to reach.
"Oh, no!" people half my age will shriek. "Then what happens to the 'i' key? This would be impossible." Just use the now-unused key on the left ('h') for your insert-on-left. Reach left to insert on left. There, easy.
Funny how those who insist that YOU should relearn something as fundamental as the entire inverted-T arrowkey structure built into the hardware of every keyboard and used by almost all apps on all platforms including kids' game boxes find relearning a single, arbitrary 'i' key such an insurmountable obstacle to themselves.
But what if you have to use a copy of vim on a machine without your customized .vimrc? Sorry, but that's just an argument against ANY useful customization of vim. It's just not a problem, because the real arrowkeys on the keyboard are in the arrangement you're used to using on the ijkl keys. Just use the real arrowkeys temporarily or copy over your .vimrc. I've done it for years.
But what about other editors that have a vi mode? What about something like zsh with a vi mode? These things can be remapped to match your .vimrc unless they only offer a couple of keys, in which case they can be treated just like all apps with their own couple of local keyboard shortcuts.
Really, if the standard advice is, "You'll have one or two frustrating days, but after that your muscle memory will take care of remembering "hjkl" for you," then you can take your own advice and keep the inverted-T muscle memory you already have for the movement keys and reduce your task to learning a single 'h' key for insertion, and save the next generation from this nonsense.
If a 30-yr user of vi like me isn't stuck with the historical accidents of the past, why should new users have to be?
I used that arrangement back in the 1980s myself, but when keyboards evolved, so did I. I remapped the movement keys to match the other movement keys (arrowkeys).
If you're going to go to the effort of customizing your vim to force yourself to learn a new keyboard arrangement, customize it so that the movement keys are ijkl instead of hjkl, so that both of your sets of arrowkeys are in the same, natural, modern, inverted-T arrangement. Then you don't have to deactivate those real arrowkeys, because there won't be any temptation to use them with the ijkl keys in the same arrangement and easier to reach.
"Oh, no!" people half my age will shriek. "Then what happens to the 'i' key? This would be impossible." Just use the now-unused key on the left ('h') for your insert-on-left. Reach left to insert on left. There, easy.
Funny how those who insist that YOU should relearn something as fundamental as the entire inverted-T arrowkey structure built into the hardware of every keyboard and used by almost all apps on all platforms including kids' game boxes find relearning a single, arbitrary 'i' key such an insurmountable obstacle to themselves.
But what if you have to use a copy of vim on a machine without your customized .vimrc? Sorry, but that's just an argument against ANY useful customization of vim. It's just not a problem, because the real arrowkeys on the keyboard are in the arrangement you're used to using on the ijkl keys. Just use the real arrowkeys temporarily or copy over your .vimrc. I've done it for years.
But what about other editors that have a vi mode? What about something like zsh with a vi mode? These things can be remapped to match your .vimrc unless they only offer a couple of keys, in which case they can be treated just like all apps with their own couple of local keyboard shortcuts.
Really, if the standard advice is, "You'll have one or two frustrating days, but after that your muscle memory will take care of remembering "hjkl" for you," then you can take your own advice and keep the inverted-T muscle memory you already have for the movement keys and reduce your task to learning a single 'h' key for insertion, and save the next generation from this nonsense.
If a 30-yr user of vi like me isn't stuck with the historical accidents of the past, why should new users have to be?
What a rant! Unfortunately, it is entirely misguided. Nobody wants to force anyone to use the 'hjkl' arrangement, I was merely sharing a tip on how to get used to it if someone already wants to switch from arrow keys to 'hjkl' (like I did at some point in time).
The reason for doing this is, for me, simply that it is on the home row, and therefore I can reach it quicker. If you like 'ijkl', fine, do that. I feel more comfortably with 'hjkl'.
Or rather, what I am actually using is 'dhtn', being a Dvorak user. And my delete is on 'e'. Because that is how I like it.
Use whatever you like, but in any case switching from one variant to another (for whatever reason) will take a few days of retraining the muscle memory.
The reason for doing this is, for me, simply that it is on the home row, and therefore I can reach it quicker. If you like 'ijkl', fine, do that. I feel more comfortably with 'hjkl'.
Or rather, what I am actually using is 'dhtn', being a Dvorak user. And my delete is on 'e'. Because that is how I like it.
Use whatever you like, but in any case switching from one variant to another (for whatever reason) will take a few days of retraining the muscle memory.
[Your rant is entirely misguided.] Nobody wants to force anyone to use the 'hjkl' arrangement
No, instead, they advise all new users that they should force themselves. Why are new vim users so often advised to deactivate their arrowkeys? Apparently the arrowkeys tempt them to take their hands off the normal keys. Why are they so tempted to do something so awkward? Because to new vim users with a lifetime of experience with inverted-T arrangements, the weird, archaic hjkl arrangement is even more awkward. "Well," they're told, "the solution is to make your arrowkeys YET MORE awkward by deactivating them entirely."
What I'm saying is that the significant vim benefits that come from staying on the normal keys can be obtained with a carrot instead of a stick. Instead of making their arrowkeys even more difficult than the awkward hjkl keys, make their normal keys even more tempting.
No, instead, they advise all new users that they should force themselves. Why are new vim users so often advised to deactivate their arrowkeys? Apparently the arrowkeys tempt them to take their hands off the normal keys. Why are they so tempted to do something so awkward? Because to new vim users with a lifetime of experience with inverted-T arrangements, the weird, archaic hjkl arrangement is even more awkward. "Well," they're told, "the solution is to make your arrowkeys YET MORE awkward by deactivating them entirely."
What I'm saying is that the significant vim benefits that come from staying on the normal keys can be obtained with a carrot instead of a stick. Instead of making their arrowkeys even more difficult than the awkward hjkl keys, make their normal keys even more tempting.
I think they are simply advised to learn the 'hjkl' navigation because many of those already using have made good experiences with it. That's the nature of advice: Allow someone else to profit from your experience. But it's just that, advice, you're free to ignore it. I honestly don't see what's the big deal about it or why this in particular seems to irk you so much.
When I started out using Vim someone teaching me the basics pointed out the 'hjkl' navigation and recommended that I learn it, because I will be faster with it. Having to learn a lot of other commands, I kind of ignored the advice since it was simply a reflex for me to reach for the arrow keys. I happily used the arrow keys for years; nobody complained about it. At some point I finally decided to give the 'hjkl' navigation a serious try, and for that reason deactivated the arrow keys to help me break my old habit and take up the new one.
I would have found taking up 'ijkl' equally awkward, since either case I would have to retrain my muscle memory. Honestly, 'ijkl' and 'hjkl' doesn't seem to make much of a difference to me. Either one has to be trained a bit, and then it's automatic.
The one advantage of 'ijkl' that I see is that it forms a basis for the quaternions :-).
When I started out using Vim someone teaching me the basics pointed out the 'hjkl' navigation and recommended that I learn it, because I will be faster with it. Having to learn a lot of other commands, I kind of ignored the advice since it was simply a reflex for me to reach for the arrow keys. I happily used the arrow keys for years; nobody complained about it. At some point I finally decided to give the 'hjkl' navigation a serious try, and for that reason deactivated the arrow keys to help me break my old habit and take up the new one.
I would have found taking up 'ijkl' equally awkward, since either case I would have to retrain my muscle memory. Honestly, 'ijkl' and 'hjkl' doesn't seem to make much of a difference to me. Either one has to be trained a bit, and then it's automatic.
The one advantage of 'ijkl' that I see is that it forms a basis for the quaternions :-).
Well, I guess we can both agree that in the end, as usual, it all comes down to quaternions. ;-)
> No, instead, they advise all new users that they should force themselves.
Because it may make you slightly slower for a week, but it makes you faster for the rest of your life.
Depending on how much time you think you'll spend in Vim for the rest of your life, that tradeoff may be very smart indeed.
Doing what seems easiest or most "natural" at first may not always be the best user interface in the long run.
Because it may make you slightly slower for a week, but it makes you faster for the rest of your life.
Depending on how much time you think you'll spend in Vim for the rest of your life, that tradeoff may be very smart indeed.
Doing what seems easiest or most "natural" at first may not always be the best user interface in the long run.
So why not make ijkl the new standard? It has all the benefits of the "traditional" arrow key layout without losing the speed of staying on the home row.
If it ain't broke, don't fix it?
The only people that would benefit are people who have not yet learned hjkl, and those people have no influence. What are you expecting to be done, Vim wildly breaks standards, pisses off existing users, and changes the default key layout? Never going to happen, never should happen. First off, because it will piss off existing users for no reason whatsoever, and secondly because nobody in a position to make that call would make that call. Thankfully.
Distribute Vim yourself with these changes; see how far you get.
The only people that would benefit are people who have not yet learned hjkl, and those people have no influence. What are you expecting to be done, Vim wildly breaks standards, pisses off existing users, and changes the default key layout? Never going to happen, never should happen. First off, because it will piss off existing users for no reason whatsoever, and secondly because nobody in a position to make that call would make that call. Thankfully.
Distribute Vim yourself with these changes; see how far you get.
Bravo! From the other comments, I guess you are going against the 'common sense' of vim users, but actually hjml has been the reason I never bothered with vim. Having to replace years (or decades) of T-arrowkeys (in windows, and in every FPS) seems utterly insane to me (and probably to most people that grew up with them)
How can you be so attached to taking your hand off the home row to move around? Or to that arrow shape?
This comment thread is kind of blowing my mind, how can so many people have an issue with this? It's such a tiny simple thing to put into muscle memory. Are you guys all hunt and peck typers?
I feel a little bad for being insulting, but it really is hard to imagine so much resistance to memorizing j=down, k=up.
The hjkl pattern is the same pattern as the arrows at the top of dance dance revolution and people seem to pick that up pretty quickly.
This comment thread is kind of blowing my mind, how can so many people have an issue with this? It's such a tiny simple thing to put into muscle memory. Are you guys all hunt and peck typers?
I feel a little bad for being insulting, but it really is hard to imagine so much resistance to memorizing j=down, k=up.
The hjkl pattern is the same pattern as the arrows at the top of dance dance revolution and people seem to pick that up pretty quickly.
Touch-typist here: I don't hunt and peck and I can tell you that from a pure probabilistic standpoint if you're entering a typing contest with me you'll probably look like the one hunt and pecking ; )
It's not that it's hard to memorize: Emacs' 'p' for up and 'n' aren't hard to memorize. They're just utterly dumb. Just like 'jk'.
You're not sounding insulting: you're sounding like someone who has never put any thought into that issue arguing vs someone who did.
I'm an Emacs user and yet it's 'ijkl' for me (it's Emacs heresy of course).
Now I don't doubt that dance dance revolution players are representative of professional programmers... But lots of gamers (eg professional first-person shooter players) do use the inverted T arrow principle to quickly move up/down/right/left -- typically WASD and sometimes ESDF.
It simply makes more sense to "train your muscle memory" to something that also logically makes a lot of sense. You know, like... Up to go up. Down to go down. Left to go left. Right to go right.
It's not that it's hard to memorize: Emacs' 'p' for up and 'n' aren't hard to memorize. They're just utterly dumb. Just like 'jk'.
You're not sounding insulting: you're sounding like someone who has never put any thought into that issue arguing vs someone who did.
I'm an Emacs user and yet it's 'ijkl' for me (it's Emacs heresy of course).
Now I don't doubt that dance dance revolution players are representative of professional programmers... But lots of gamers (eg professional first-person shooter players) do use the inverted T arrow principle to quickly move up/down/right/left -- typically WASD and sometimes ESDF.
It simply makes more sense to "train your muscle memory" to something that also logically makes a lot of sense. You know, like... Up to go up. Down to go down. Left to go left. Right to go right.
You don't have to. The arrows work just fine. You can use 'hjkl' (or whatever pleases you), and many people choose to, for the main reason that having navigation keys in the home row is really nice.
Having navigation on 'hjkl' for me was never about a lack of arrow keys, and has always been about convenience. The reason it's specific to Vi/m is that you need a modal editor to be able to pull it off.
Having navigation on 'hjkl' for me was never about a lack of arrow keys, and has always been about convenience. The reason it's specific to Vi/m is that you need a modal editor to be able to pull it off.
But it's easier for a touch-typist to hit 'i' than 'h' (your middle finger doesn't stretch as much when hitting 'i' than your index when hitting 'h'). Try it.
Then in addition to that ijkl is more logical than hjkl.
Then in addition to that ijkl is more logical than hjkl.
I wish Linux just came with Edit.com.
Arrow keys for movement, letter keys for input (what a novelty?!), and a working mouse. All available since MS Dos 6 or earlier.
I understand that some people like VIM and or Emacs, but why must UNIX people force such arcane editors down people's throats? Edit.com put them to shame almost twenty years ago.
Yes, I know, if you spend YEARS learning clever key combinations you can be ever so slightly more efficient, what a novelty...
Arrow keys for movement, letter keys for input (what a novelty?!), and a working mouse. All available since MS Dos 6 or earlier.
I understand that some people like VIM and or Emacs, but why must UNIX people force such arcane editors down people's throats? Edit.com put them to shame almost twenty years ago.
Yes, I know, if you spend YEARS learning clever key combinations you can be ever so slightly more efficient, what a novelty...
Vim happily uses arrow keys for movement and you can easily learn the basics in a day. Saying that edit puts it to shame is ridiculous, and I'm someone who occasionally types 'edit' out of habit in a dos prompt to edit text files.
You can use Nano/Pico if you want edit.com capabilities... but there is a reason nobody takes them seriously.
Non-modal (I consider Emacs modal too) non-programmable editors are toys.
Non-modal (I consider Emacs modal too) non-programmable editors are toys.
Nano and pico gives you that... Available on most unix systems.
+1 for nano... I only make relatively quick config changes from a console... so nano is much less of a learning curve... I'd rather not have to memorize a bunch of commands for my general text editing. I do prefer a GUI editor, and ironically enough, Sublime Text has been increasingly my goto editor (needing to remember certain hotkeys, but still works for general arrow-key and mouse editing).
Creating custom mappings is great until you need to ssh into an unfamiliar production system and you begin mashing up config files and cron jobs because your muscle memory doesn't match the standard mappings.
This is the number one reason I've kept my .vimrc to 11 lines. Anything else I've tried adding - particularly in the way of plugins - has only caused me annoyances when working other machines.
all of Vim is just a bunch of muscle memory, to one degree or another, and i think you're overstating the intuitiveness/stubborness of the navigational keys. i use Programmer Dvorak and i've never messed with any navigation bindings, and i don't have a problem navigating. (hjkl -> jcvp. not even on the same hand, though it does have some incidental "intuitiveness")
more importantly though, is you should almost never use hjkl in the first place. these are the commands you should be using:
more importantly though, is you should almost never use hjkl in the first place. these are the commands you should be using:
b B w W e E ge gE
H M L I A $ ^ 0 %
{ } [[ ]] [] ][
t<char> T<char> f<char> F<char> ; ,
/<chars>
(search counts as a movement command,
d/foo<enter> will delete everything to foo)
I found this while using vim, too. Perhaps I could have eked out a little more efficiency by switching from the cursor keys to hjkl, but I found the (substantial) gains from being consistent about using the higher-level motion commands large enough to keep me happy.
Yes. The character-at-a-time motion commands are not really that common in idiomatic vi usage.
You use a lot of words to make one good point, which is that jikl for movement and h for insert is a sensible key mapping. Whether or not you're aware of the advantages of near-home-row movement keys, all the snark surrounding your point is a disservice to it.
I'm going to try your suggestion though, it makes sense.
I'm going to try your suggestion though, it makes sense.
I barely even use h and l anyway, in favor of b and w. And it turns out j and k are ubiquitous in Unix by their own right.
Have you considered the possibility that having nav keys in the home row is a significant advantage over moving the (usually) right hand off the home row entirely to screw around with arrow keys, then back into the homerow to continue working?
I'm surprised you didn't mention it.
(nice rant though!)
I'm surprised you didn't mention it.
(nice rant though!)
I'm sure that, just like me, he did consider that possibility.
And he did realize that it's easier, from the home position of a touch-typist, to hit 'i' than it is to stretch your index finger and hit 'h'. Just ing try it and you'll see.
In addition to that, it's also more logical to have the inverted 'T' arrow.
Have you considered the possibility that you find what you're using a "significant advantage" simply because it is the same as what an old arcane keyboard did use back in the days?
And he did realize that it's easier, from the home position of a touch-typist, to hit 'i' than it is to stretch your index finger and hit 'h'. Just ing try it and you'll see.
In addition to that, it's also more logical to have the inverted 'T' arrow.
Have you considered the possibility that you find what you're using a "significant advantage" simply because it is the same as what an old arcane keyboard did use back in the days?
"Every keyboard now has a set of hardware arrowkeys sensibly arranged in an inverted-T"
I've never got into the habit of using anything other than arrow keys even though I've been an occasional vi user for 26 years. Indeed the ancient model of TeleVideo terminal I first learnt Unix on had arrow keys - although not in an inverted-T:
http://www.backglass.org/duncan/gimix/gimix_terminal.jpg
I've never got into the habit of using anything other than arrow keys even though I've been an occasional vi user for 26 years. Indeed the ancient model of TeleVideo terminal I first learnt Unix on had arrow keys - although not in an inverted-T:
http://www.backglass.org/duncan/gimix/gimix_terminal.jpg
The inverted-T has never made any sense to me. It makes it easy to keep your fingers on left and right, but you can only easily have a single finger on either up or down.
The only time I use an inverted-T is when playing games that use wasd and it really doesn't make sense there, to the extent that when I used to be really into Q3A I started using asdf. (asdf, unlike hjlk, has unfortunately not stayed in my muscle memory.)
The importance of any sort of t-shape is only clear to me if the user cannot type.
The only time I use an inverted-T is when playing games that use wasd and it really doesn't make sense there, to the extent that when I used to be really into Q3A I started using asdf. (asdf, unlike hjlk, has unfortunately not stayed in my muscle memory.)
The importance of any sort of t-shape is only clear to me if the user cannot type.
Back in the really old days.. I used to map the left ctrl-shift, and z-x as down,up,left,right respectively... it was pretty comfortable, and the muscle memory made it really effective... the position on ctrl, vs shift was physically up/down, but let my hand still be in a natural shape. After around Q3A though, I just got used to wasd, and got tired of remapping all my games around, since it usually messed up other keys, and the inverted T is very common.
I was having some trouble trying to figure out how ctrl/shift/z/x was comfortable at all, but then I realized the idiotic ctrl/fn positioning on this thinkpad was my issue. Seems like a layout with some potential.
You can probably swap Ctrl/Fn in the BIOS settings on your ThinkPad -- I have, it's much more sane.
> The inverted-T has never made any sense to me. It makes it easy to keep your fingers on left and right, but you can only easily have a single finger on either up or down.
Contracting fingers to slide between up and down keys is a lot easier than sliding them sideways.
Contracting fingers to slide between up and down keys is a lot easier than sliding them sideways.
Just adopt a "never retreat" policy in FPS. (I suck at FPS, BTW.)
[deleted]
+100 000
I'm on Emacs but... I'm doing exactly like you. Inverted 'T' arrows on 'ijkl' ("jkl" being, for a touch typist, the default position for already three of four fingers of the right hand).
It makes sense: pro-gamers for example (not programmers but 'pro-gamers') do often use 'wasd' or 'esdf' because most are right-handed, so they use the mouse with their right hand and they use an inverted 'T' arrows on their left hand (both 'wasd' and 'esdf' do work... I preferred 'esdf' backed when I used to game but that was a long time ago).
'ijkl' makes no sense besides for historical reasons.
Let's not talk about Emacs (and I love Emacs) 's totally stupid 'pbnf': that has to be one of the dumbest way ever way to move the cursor.
Yet people would rather catch RSI than take the time it takes to configure their Emacs to use 'ijkl' instead of 'pbnf' (Previous / Backward / Next / Forward... Zomg. They really did this).
Emacs has a lot of other stupid problems too: I saw some people were remapping the totally Control+x (which you need all the time) to other things using ctl-x-map. I'll look into that next.
And I agree with you: it doesn't take long to get use to a logical way of moving your cursor.
Oh well. We won't convince anyone but... At least both vim and Emacs (and probably many others) are configurable so at least the ones who put thoughts into that matter are able to modify their environment to use a saner configuration.
I'm on Emacs but... I'm doing exactly like you. Inverted 'T' arrows on 'ijkl' ("jkl" being, for a touch typist, the default position for already three of four fingers of the right hand).
It makes sense: pro-gamers for example (not programmers but 'pro-gamers') do often use 'wasd' or 'esdf' because most are right-handed, so they use the mouse with their right hand and they use an inverted 'T' arrows on their left hand (both 'wasd' and 'esdf' do work... I preferred 'esdf' backed when I used to game but that was a long time ago).
'ijkl' makes no sense besides for historical reasons.
Let's not talk about Emacs (and I love Emacs) 's totally stupid 'pbnf': that has to be one of the dumbest way ever way to move the cursor.
Yet people would rather catch RSI than take the time it takes to configure their Emacs to use 'ijkl' instead of 'pbnf' (Previous / Backward / Next / Forward... Zomg. They really did this).
Emacs has a lot of other stupid problems too: I saw some people were remapping the totally Control+x (which you need all the time) to other things using ctl-x-map. I'll look into that next.
And I agree with you: it doesn't take long to get use to a logical way of moving your cursor.
Oh well. We won't convince anyone but... At least both vim and Emacs (and probably many others) are configurable so at least the ones who put thoughts into that matter are able to modify their environment to use a saner configuration.
This is the first I've heard of ESDF instead of WASD for gaming. At least on this keyboard I'm using, it makes more sense, because F has a tiny ridge on the bottom to find by touch, but none of the wASD keys do.
My preferred method is a couple hours of Nethack.
Another vote for this method. This is the only way I managed to train myself to use hjkl when I first started learning Vim.
I also disabled Home, End, PgUp and PgDown:
I also disabled Home, End, PgUp and PgDown:
noremap <home> <nop>
noremap <end> <nop>
noremap <pageup> <nop>
noremap <pagedown> <nop>Duly added to my .vimrc, just in case. Cheers!
Although this can be helpful to force some people to learn hjkl, you may want to remove this after awhile.
I use whatever my hand happens to be closer to. 85% of the time that's the home row, hjkl. But if my hand is closer to the arrow keys I'll use that, and if my hand is on the mouse I'll use that.
I use whatever my hand happens to be closer to. 85% of the time that's the home row, hjkl. But if my hand is closer to the arrow keys I'll use that, and if my hand is on the mouse I'll use that.
I re-purposed mine for buffer switching:
" Arrow keys set up for easy buffer switching
nnoremap <left> :bprev<cr>
nnoremap <right> :bnext<cr>
nnoremap <down> :buffer #<cr>
nnoremap <up> :buffers<cr>:buffer<space>I know, did this at home and started yelling at my laptop shortly after. Got better, am using the keys nowadays, when using vim.
But non the less, the logic didn't register with me. (something like clockwise/counter-clockwise, or anything remotely recognizable ;-) )
But non the less, the logic didn't register with me. (something like clockwise/counter-clockwise, or anything remotely recognizable ;-) )
My fingers still remember the Apple II keyboard arrows keys: Left, Right, Down, Up.
http://jwvideo.free.fr/ImagesMac/AppleII/Apple%20II%20int%C3...
I've always thought that was so much better than the inverted T on PC keyboards, since you can press all the keys without moving your fingers - much faster for games.
http://jwvideo.free.fr/ImagesMac/AppleII/Apple%20II%20int%C3...
I've always thought that was so much better than the inverted T on PC keyboards, since you can press all the keys without moving your fingers - much faster for games.
I also have problems with 'hjkl'. I could never tell which is up and which is down. If it were up to me, the navigation keys would be mapped to WASD instead.
You could do that if you wanted.
When starting vim (any editor, really) you usually begin at the top. So you want to go down first...
Oh, this `j` key has an inset to distinguish it from the rest. Surely this means I need to press this one!
(You can easily figure out the three other keys from there).
Oh, this `j` key has an inset to distinguish it from the rest. Surely this means I need to press this one!
(You can easily figure out the three other keys from there).
What worked for me was:
H & L are left & right - fairly intuitive, leftmost is left, rightmost is right
J looks kinda like a down arrow
That leaves K, which must be up by process of elimination :)
H & L are left & right - fairly intuitive, leftmost is left, rightmost is right
J looks kinda like a down arrow
That leaves K, which must be up by process of elimination :)
I memorized HJKL thusly:
• H and L are leftmost and rightmost keys, therefore they move the cursor left and right respectively
• J kind of looks like it's pointing down
• This only leaves K as the up arrow (the only remaining choice)
I remember them because Ctrl-J is newline (moves down), and the rest are obvious after that.
Learn other motions instead (eEbBwW/?fFtT and so on).
Once you have integrated them in your workflow, you'll wonder why you even got into the trouble to force yourself to use hjkl instead of the arrows.
Once you have integrated them in your workflow, you'll wonder why you even got into the trouble to force yourself to use hjkl instead of the arrows.
The best way to learn the hjkl movement keys is to play a game like nethack.[1]
[1] - https://en.wikipedia.org/wiki/Nethack
[1] - https://en.wikipedia.org/wiki/Nethack
This was my thought when I first tried learning Vim, but I quickly realized that my right-hand home row position for roguelikes is one key too far to the left, meaning that I either had to unlearn those years of DCSS or else teach myself how to type all over again. Not to mention the incessant frustration of unintentional jumps, yanks, and undos when all you're trying to do is move diagonally.
Seconded.
Remapping the movement keys in Worms Reloaded also helped massively, though did result in me getting completely thrashed for the first twenty or thirty matches I played.
Remapping the movement keys in Worms Reloaded also helped massively, though did result in me getting completely thrashed for the first twenty or thirty matches I played.
Yeah, but I always played with number_pad enabled, so I never picked it up. (And then I wound up being incapable of playing the game sensibly on my laptop, alas: no diagonals.)
That's why you should learn nethack with hjkl, so you'll know about yubn (http://nethackwiki.com/wiki/Yuhjklbn)
[deleted]
hjkl: just learn them.
These four keys are the most basic thing about vim. Yes there doesn't seem to be much to remember them by, but for these at least, there doesn't need to be. Just muscle through it as long as it takes. It won't take long if you're using vim regularly. Soon you won't think about it, you'll just think "up" and you'll be up a line without consciously thinking "... um ... k".
There are ways to get around these four: arrow keys, macros, whatever. Don't. Just learn them.
Bonus, those keys show up in other vim-like command interfaces, including bash and other shell command line shortcuts. And if you use .inputrc, they'll show up in database and language repls and similar environments.
Just learn them.
These four keys are the most basic thing about vim. Yes there doesn't seem to be much to remember them by, but for these at least, there doesn't need to be. Just muscle through it as long as it takes. It won't take long if you're using vim regularly. Soon you won't think about it, you'll just think "up" and you'll be up a line without consciously thinking "... um ... k".
There are ways to get around these four: arrow keys, macros, whatever. Don't. Just learn them.
Bonus, those keys show up in other vim-like command interfaces, including bash and other shell command line shortcuts. And if you use .inputrc, they'll show up in database and language repls and similar environments.
Just learn them.
I'm surprised no-one has knocked together a tiny "game" to teach hjkl.
Display a big arrow, grab an input, make a nice boop noise if it's right and a nasty beep noise (with a graphic flash) if it's wrong. Keep score of how many key presses were right, and average time for each press.
Display a big arrow, grab an input, make a nice boop noise if it's right and a nasty beep noise (with a graphic flash) if it's wrong. Keep score of how many key presses were right, and average time for each press.
They have! Although it's not "tiny".
http://vim-adventures.com/
http://vim-adventures.com/
The original Rogue is a pretty tiny game. By modern standards, Nethack and Angband are fairly small as well.
Two of the four are simply the standard ASCII control characters:
· Control-H is Back Space: it moves the cursor one position left.
· Control-J is Line Feed: it moves the cursor one line down.
The other two seem to be arbitrary on the part of the ADM-3A designers, and having Control-L (Form Feed) perform cursor-right rather than clear-screen seems a bit dubious, but given their constraints and the desire to keep all the motions together, it's hard to argue for any different choices.
· Control-H is Back Space: it moves the cursor one position left.
· Control-J is Line Feed: it moves the cursor one line down.
The other two seem to be arbitrary on the part of the ADM-3A designers, and having Control-L (Form Feed) perform cursor-right rather than clear-screen seems a bit dubious, but given their constraints and the desire to keep all the motions together, it's hard to argue for any different choices.
Can't find the source saying hjkl ascii code is a simple bit-shift operation away from tty arrow code.
"hjkl", as there is (imho) no logical mnemonic for the directions.
right: "l" is rightmost in the group
down: "j" extends down below the baseline
up: "k" extends up to the topline
I'm no sure how much it'll help, but:
h: move left ctrl-h (which is backspace in ASCII): move left a space while doing something
j: move down ctrl-j (line feed): move down a space while doing something
Unfortunately, this doesn't extend to k (vertical tab) or l (form feed), but... maybe it's helpful?
If you need to practice, play robots or nethack...
h: move left ctrl-h (which is backspace in ASCII): move left a space while doing something
j: move down ctrl-j (line feed): move down a space while doing something
Unfortunately, this doesn't extend to k (vertical tab) or l (form feed), but... maybe it's helpful?
If you need to practice, play robots or nethack...
Funny how all roads lead to a discussion of the merits of vi/m.
At least some of you now understand that these tools were designed as you see them today because they were dealing with crippled hardware (from today's vantage point). There was no magical study on keystroke efficiency at the inception. They had lemons and made lemonade.
Now, quit arguing and get back to reading Facebook!
Yup, that's me ducking in the corner.
At least some of you now understand that these tools were designed as you see them today because they were dealing with crippled hardware (from today's vantage point). There was no magical study on keystroke efficiency at the inception. They had lemons and made lemonade.
Now, quit arguing and get back to reading Facebook!
Yup, that's me ducking in the corner.
HJKL is madness. It's more proof that "The Inmates are Running the Asylum" when it comes to usability. We programmers are so much more apt at remapping functions to arbitrary inputs/symbols that we continue to put up with things like this, decades after the reason disappears. This is also why we need to make special efforts at understanding non-programmer users.
I do agree that "we need to make special efforts at understanding non-programmer users." But this isn't a good example since Vim is a specialized editor mostly recommended for programers. If the general-purpose text editors (and word processors) required you to use HJKL, you might have a point. (EDIT: I misunderstood stcredzero's argument. See stcredzero's comment below.)
It's also true that functions can be mapped to arbitrary inputs and systems. But I think there's value in learning HJKL rather than remapping them:
1. They're on the home row, giving a slight speed benefit for these commonly used actions.
2. You get used to the movement keys that will be the default in any copy of Vi/m and quite a few other tools. (HJKL, along with WASD and dedicated arrow keys, is probably the most common mapping of left, right, up, and down to keys on a keyboard.)
It's also true that functions can be mapped to arbitrary inputs and systems. But I think there's value in learning HJKL rather than remapping them:
1. They're on the home row, giving a slight speed benefit for these commonly used actions.
2. You get used to the movement keys that will be the default in any copy of Vi/m and quite a few other tools. (HJKL, along with WASD and dedicated arrow keys, is probably the most common mapping of left, right, up, and down to keys on a keyboard.)
> But this isn't a good example since Vim is a specialized editor mostly recommended for programers.
Arrgh. This is an example of why programmers are different, not of a bad interface for ordinary people. Thanks for considering me so daft as to think non-programmers people use VIM.
Arrgh. This is an example of why programmers are different, not of a bad interface for ordinary people. Thanks for considering me so daft as to think non-programmers people use VIM.
I apologize for my (unintended) insult. I should have read your comment more carefully.
I still disagree that HJKL is madness, however. It's not the best possible scheme, but it is reasonable to keep it for its remaining advantages.
I still disagree that HJKL is madness, however. It's not the best possible scheme, but it is reasonable to keep it for its remaining advantages.
i have tried both and hjkl is just faster. it's "madness" the same way having 88 white unmarked keys on a piano is "madness" to someone who doesn't play.
Sometimes stirring-up shit can be a win-win situation.
I could agree with you and get the anti-vim guys all worked up. I could even back it up with random links and examples from all over the web.
I could also disagree with you and get pro-vim guys all riled-up. Again, suitable links, stats and a photo of some guy with carpal-tunnel would do the trick.
That's great stuff!
To quote one of the most memorable lines in motion picture lore:
"Interesting game. The only way to win is not to play."
I use vim. And I've used everything else. I don't care. All of it pales in magnitude to the efficiency losses elsewhere in the process of developing a software product.
My guess is that on a daily basis I waste more time going for a cup of coffee, shooting the shit, reading/posting on HN, getting pulled in all manner of directions on the internet than any text editor could save me short of a brain-to-code interface.
And, of course, there's the actual work of figuring out how to code something. I've spent days diagraming state machines with, yes, hold-on, paper and pencil. Once there, an hour or two and the bug-free code is written and working. Yes, even if you use Notepad.
You want to be more efficient? Get really good at going from problem to finished, shippable, documented, flexible, reusable and bug-free code. What you use to enter said code probably does not matter.
I'm going back to polishing my keyboard.
Maybe you guys ought to do the same.
I could agree with you and get the anti-vim guys all worked up. I could even back it up with random links and examples from all over the web.
I could also disagree with you and get pro-vim guys all riled-up. Again, suitable links, stats and a photo of some guy with carpal-tunnel would do the trick.
That's great stuff!
To quote one of the most memorable lines in motion picture lore:
"Interesting game. The only way to win is not to play."
I use vim. And I've used everything else. I don't care. All of it pales in magnitude to the efficiency losses elsewhere in the process of developing a software product.
My guess is that on a daily basis I waste more time going for a cup of coffee, shooting the shit, reading/posting on HN, getting pulled in all manner of directions on the internet than any text editor could save me short of a brain-to-code interface.
And, of course, there's the actual work of figuring out how to code something. I've spent days diagraming state machines with, yes, hold-on, paper and pencil. Once there, an hour or two and the bug-free code is written and working. Yes, even if you use Notepad.
You want to be more efficient? Get really good at going from problem to finished, shippable, documented, flexible, reusable and bug-free code. What you use to enter said code probably does not matter.
I'm going back to polishing my keyboard.
Maybe you guys ought to do the same.
I slightly disagree. Obviously you're entirely correct about the amount of time spent editing text versus figuring out how to code stuff. The "time efficiency" argument for vim is pretty rubbish.
For me (and I appreciate the irony) I like vim because it has a lower cognitive load. I can say things like "Change the contents of the quotes to say Goodbye Planet", rather than having to actually execute the instructions --
move left a word, move left a word, start highlight, move right a word, move right a word, move right a word, stop and check to see my cursor is in the right place, press delete, type phrase "Goodbye Planet"
The benefits measured in time are no doubt negligible (or even negative -- as you say, editing time pales in comparison to other work), but the benefits to my concentration are much higher. Tedious, repetitive work makes me frustrated, distracted, or both. If I can keep myself in a good mental space and not be constantly interrupted by having to babysit my source editor, I can be more productive.
PS: And then I spend the time on HN :/
For me (and I appreciate the irony) I like vim because it has a lower cognitive load. I can say things like "Change the contents of the quotes to say Goodbye Planet", rather than having to actually execute the instructions --
move left a word, move left a word, start highlight, move right a word, move right a word, move right a word, stop and check to see my cursor is in the right place, press delete, type phrase "Goodbye Planet"
The benefits measured in time are no doubt negligible (or even negative -- as you say, editing time pales in comparison to other work), but the benefits to my concentration are much higher. Tedious, repetitive work makes me frustrated, distracted, or both. If I can keep myself in a good mental space and not be constantly interrupted by having to babysit my source editor, I can be more productive.
PS: And then I spend the time on HN :/
robomartin: A voice of reason in a sea of inane babble.
Thanks for the vote of confidence. Now I have the challenge of actually trying to be that person.
Chad, while it's true that having your direction keys where you can easily reach them is faster than having them somewhere else, using the mouse is faster than moving one cell at a time with direction keys, and Jef Raskin's "LEAP" research in the 1980s showed that incremental search is faster than using the mouse. Try it in vim:
:set incsearch
:set hlsearch
I do love search for file navigation (incremental is even better, but not strictly necessary).
Do you have a link to the study about mouse vs cell-based key movement?
I have a couple of questions:
- While I fully believe that navigating by mouse is faster, on a desktop the overhead of switching between typing and mousing is quite high. On my laptop I often use the trackpoint over relevant keyboard shortcuts because it's already right under my fingers, but on my desktop I much prefer using the shortcuts due to the overhead of switching.
- For a movement that's three cells or fewer, I find it hard to imagine that mouse would be faster (unless perhaps it's set to follow the cursor?). I assume the study averages over a variety of distances across the entire screen. I hope that most vim users aren't using hjkl for adjustments of more than three or so cells. A combination of {}wb and especially ?/ will handle the bulk of jumps quickly. hjkl are then useful keys for adjusting just a couple of characters to refine your jump -- and now they're already right under your fingers.
Do you have a link to the study about mouse vs cell-based key movement?
I have a couple of questions:
- While I fully believe that navigating by mouse is faster, on a desktop the overhead of switching between typing and mousing is quite high. On my laptop I often use the trackpoint over relevant keyboard shortcuts because it's already right under my fingers, but on my desktop I much prefer using the shortcuts due to the overhead of switching.
- For a movement that's three cells or fewer, I find it hard to imagine that mouse would be faster (unless perhaps it's set to follow the cursor?). I assume the study averages over a variety of distances across the entire screen. I hope that most vim users aren't using hjkl for adjustments of more than three or so cells. A combination of {}wb and especially ?/ will handle the bulk of jumps quickly. hjkl are then useful keys for adjusting just a couple of characters to refine your jump -- and now they're already right under your fingers.
I don't have a link. I remember that one such set of experiments was done by a famous usability expert at Sun who's not Nielsen, but I can't remember who he was.
There's a slowdown associated with considering too many different options, too, btw. It's just more invisible.
There's a slowdown associated with considering too many different options, too, btw. It's just more invisible.
88 white unmarked keys on a piano would be madness. You forgot the black keys.
The piano/keyboard isn't my main instrument, but I'm not sure that the color of the keys would make a huge difference. Practiced/professional violinists, for example, don't use sight to figure out how to place their fingers, and pianists don't even have to worry about tuning the way violinists do.
The two people above you are pretty much saying the same thing. Piano keys being unmarked and making sense to pianists as the best way was being used as proof that using keys not marked with arrows could be the best way for editors. I'll throw in with agreeing as well, my piano teacher hated when music had finger numbers on it and things like that, using them just slowed you down and messed you up, especially when the hands changed positions. Labeled piano keys would be bad because it would prevent people from learning the right way to play.
In many (most?) early pianos the colors were reversed.
You would only really need a reference point every octave. I've always felt that having "sharp notes" on, basically, their own row of the piano was silly, and I've speculated on how one could design a sane keyboard that puts all (musical) keys on an equal basis... In short, the black (physical) keys are part of the madness. ;)
You may be interested in the Janko keyboard layout then:
http://www.engadget.com/2005/03/04/music-thing-the-chromaton...
https://en.wikipedia.org/wiki/Janko_keyboard
I really want one.
http://www.engadget.com/2005/03/04/music-thing-the-chromaton...
https://en.wikipedia.org/wiki/Janko_keyboard
I really want one.
Not quite what I had in mind, but definitely interesting.
So do I. That looks insane,
Sanity is having arrow buttons on your mouse.
(also Enter, ESC, space, delete, backspace, etc etc)
(also Enter, ESC, space, delete, backspace, etc etc)
You jest, I expect, but I've actually tried it, more or less, and it works quite well. I don't (can't) use a physical keyboard, and while I use a touch screen a lot now I used to do absolutely everything with a mouse, or, often, two mice so they don't need to be gripped so tightly, one for moving and the other (with a taped over sensor) for clicking. Then I replaced the clicking mouse with a USB numeric keypad with the keys remapped to mouse buttons, arrows, and "Enter, ESC, space, delete, backspace, etc etc". It was worse for my joints, but (obviously) a bit more efficient.
You expect I jest, but I actually spent $120 on a Razer Naga just so I could use the reprogrammable thumb buttons.
If I recall correctly, control-^ (i.e. 0x1e, aka control-~) would move the ADM-3A cursor to the "home" location on the screen (i.e. the top left) if sent from the host. If you were talking to a host that was echoing your keystrokes (and maybe if you set a DIP switch for half-duplex mode?) then typing control-^ (aka control-~) would do that too.
The terminfo entry seems to confirm this (apt-get source ncurses-term && less +/^adm3a ncurses-5.9/misc/terminfo.src):
The ADM-3A had direct cursor addressing, as referenced in the "cup" capability in the above terminfo entry, so the "home" feature was, strictly speaking, redundant. As you can see from the simplicity of the terminfo entry (notably its almost complete lack of escape sequences) logic was aggressively minimized in this termainal. I seem to recall from glancing inside the ADM-3As I bought at auction in my childhood that it was built almost entirely out of discrete 7400-series logic, so every extra control character involved adding several chips.
In light of this, I suspect that the "home" feature may have been retained for backwards compatibility with something else — maybe the ADM-3? But the ADM-3 terminfo entry doesn't mention "home", so I don't know.
More details about the ADM-3A can be found at <http://manx.classiccmp.org/details/11,5618>.
The terminfo entry seems to confirm this (apt-get source ncurses-term && less +/^adm3a ncurses-5.9/misc/terminfo.src):
adm3a|lsi adm3a,
OTbs, am,
cols#80, lines#24,
OTma=^K^P, OTnl=^J, bel=^G, clear=\032$<1/>, cr=^M, cub1=^H,
cud1=^J, cuf1=^L, cup=\E=%p1%{32}%+%c%p2%{32}%+%c,
cuu1=^K, home=^^, ind=^J, kcub1=^H, kcud1=^J, kcuf1=^L,
kcuu1=^K, rs2=^N,
The ADM-3A had direct cursor addressing, as referenced in the "cup" capability in the above terminfo entry, so the "home" feature was, strictly speaking, redundant. As you can see from the simplicity of the terminfo entry (notably its almost complete lack of escape sequences) logic was aggressively minimized in this termainal. I seem to recall from glancing inside the ADM-3As I bought at auction in my childhood that it was built almost entirely out of discrete 7400-series logic, so every extra control character involved adding several chips.
In light of this, I suspect that the "home" feature may have been retained for backwards compatibility with something else — maybe the ADM-3? But the ADM-3 terminfo entry doesn't mention "home", so I don't know.
More details about the ADM-3A can be found at <http://manx.classiccmp.org/details/11,5618>.
Why oh why did the ADM-3A keyboard not use a gamer configuration for its arrow navigation keys. What a noob designed that!
He could have gone for wasd or ijkl. But he had to go with hjkl!
Anyway, the fact that j looks like a down arrow is a very good thing that makes me remember it and allow me to play nethack.
He could have gone for wasd or ijkl. But he had to go with hjkl!
Anyway, the fact that j looks like a down arrow is a very good thing that makes me remember it and allow me to play nethack.
Even worse, it didn't use Cherry red switches, and it looked like crap. Where were the bright red LEDs, macro shortcut buttons, and elaborate wrist-rest?!
Cherry red, the linear ones? Why not Cherry brown or blue?
Reds appear to be preferred by the hardcore gamers that buy those monstrous gaming keyboards. I think it's because they're lighter, and also because they're linear.
[deleted]
Right. Reds are linear better if you're going to be pressing keys and holding them down, as for moving in an FPS. But Browns, are better if you want a single keypress event registered, as for using the keyboard to type.
I honestly can't tell if this is a legitimate conversation or a parody! : P
But seriously, I spent the longest time assuming that the talk about better keyboard were exaggerations or placebo effect deals, until I started using the MBP keyboard, which just felt significantly better than anything I'd used before, sort of satisfying.
So I've got an open mind now, and am planning on hand-me-downing my apple wireless to a friend in need. Does anyone have a specific recommendation for a keyboard for programming that might be a decent replacement?
But seriously, I spent the longest time assuming that the talk about better keyboard were exaggerations or placebo effect deals, until I started using the MBP keyboard, which just felt significantly better than anything I'd used before, sort of satisfying.
So I've got an open mind now, and am planning on hand-me-downing my apple wireless to a friend in need. Does anyone have a specific recommendation for a keyboard for programming that might be a decent replacement?
Blues make great "area denial weapons" to keep people out of your office. Typing on cherry blues sounds like someone typing on a regular keyboard very angrily. ;)
I use vim a lot, but as I was reading this, I realized that unless I was in a vim session (or pretended that I was in one), I couldn't remember which of the hjkl keys mapped to which direction.
I think playing Crawl a ton is the only reason I remember so well. But playing too much crawl makes me think I can also move diagonally in vim (yubn).
Looks like it also explains why caret (^) was chosen in regex and vi to mean "beginning of line".
What does the "Rub" key do ?
Delete a character i.e. "rub out", presumably.
Is that a carryover from the typewriter days ?
Teletypes, not typewriters, punching out paper tape.
ANd 'DEL' is 0x7F in ASCII - so it would punch all the holes, the only way to make 1 char punch turn anything to the same thing.
And this is why DEL is properly a forward delete operation: it erases the character under the cursor and advances (the tape) over the next.
I blame the VT220 for screwing this up.
I blame the VT220 for screwing this up.
Heh.
My only brush with that kind of thing was servicing computers that wrote to the paper tape punches we used in the Marines in the early 90s.
My only brush with that kind of thing was servicing computers that wrote to the paper tape punches we used in the Marines in the early 90s.
Rubber is the British English word for eraser.
Badly off-topic, but I found it amusing that the user asking the question was "Lelouch Lamperouge". The juxtaposition of Lelouch and "home" brought that series back into my mind full-force.
So why was '~' chosen over '^'?
So this is what HN has come to eh? Just random trivia links. Cat pictures can't be more than two weeks off.
I disagree. This is a very interesting data point representative of a broader pattern:
Why do we use X?
Because N years ago, the environment looked like E1, and so X made sense. Then, people got used to X as a convention, and even though our environment changed to E2, we still use X because of network effects.
A great way to improve the world is to understand where X came from, understand how E2 differs from E1, and then invent Y to better fit E2.
The hard part is that Y needs to be significantly better than X so that you can get people to switch given that X has stronger network effects.
Why do we use X?
Because N years ago, the environment looked like E1, and so X made sense. Then, people got used to X as a convention, and even though our environment changed to E2, we still use X because of network effects.
A great way to improve the world is to understand where X came from, understand how E2 differs from E1, and then invent Y to better fit E2.
The hard part is that Y needs to be significantly better than X so that you can get people to switch given that X has stronger network effects.
The link content is below par for HN but the tangential discussions that come from it make up for it.
Ah yes, I used the baby blue version. Probably my favorite terminal until the HP2621a (which had a great character set, "modern" housing, and nice loud beep). Since I used the line editor to program I only really used HJKL as cursor keys in rogue. :-)
Still using Sun Unix keyboard with tilde on the right, and no obnoxious Windows keys ;) Control in the middle row on the left is also helpful in order not to stress the pinky.
The Happy Hacking Keyboard has a similar layout, with Esc in the upper-left where it belongs, Ctrl in the middle-left where it belongs, and tilde in top-right where it belongs. :)
You can remap keys in modern operating systems. Any sane person will remap capslock to something they use more often (eg. ctrl or alt). Who needs capslock anyway?
I used to think the same way until I suffered neurological damage that affects the sensory nerves in my fingers. Holding down the shift key while I type some all-caps text, like "STUPID_SHOUTY_MACRO_NAME", is uncomfortable, so I now find the caps lock key useful. It would be nice to have it as a control key, but I would want some other way to activate the caps lock function. Maybe a double tap on the shift key, like on the iPhone keypad, would work.
I actually find holding shift nicer for STUPIDLY_LONG_MACROS and whatnot since those underscores require shift and don't work with capslock.
> Who needs capslock anyway?
C and Java programmers.
C and Java programmers.
Does your Sun keyboard have a "Stop" key? I seem to remember that for about 99% of the Sun machines I encountered hitting "Stop A" was pretty obnoxious.
What's even more fun is that depending on your LOM configuration -removing- the keyboard can send a Stop-A.
This is not entirely hilarious when a junior sysadmin 'tidies up' the keyboards connected to the main database server (and even further from funny when the slave is currently down for maintenance ...)
This is not entirely hilarious when a junior sysadmin 'tidies up' the keyboards connected to the main database server (and even further from funny when the slave is currently down for maintenance ...)
The serial terminals did that as well and you couldn't unconfiure it on early sun4 prom revisions. You could get around it by using a rs232 breakout box with a resistor soldered in it and then screw that box to the back of the unit. That was standard practice. I remember when sysadmins were good with a soldering iron...
Yes, all those extra keys work with OpenSolaris and OpenIndiana. Alas, they don't produce any scan codes with Linux. They are located in a separate area on the left, so they don't disturb your workflow.
http://docs.oracle.com/cd/E19683-01/806-6642/images/BR.unix....
http://docs.oracle.com/cd/E19683-01/806-6642/images/BR.unix....
They seem to work fine with RHEL 5 and Sun Type 6 keyboards. We do this at work on our systems. We just remap the keycodes to F keys. Something like
xmodmap -e 'keycode 232 = F13' for the Stop key.
That's probably because I'm using Sun Type 5 with mini-din convertor to USB. Under OpenIndiana these keys work fine, but aren't working on Linux. Must be some driver specifics. Type 6 and Type 7 work better indeed, but they are not so ergonomic as Type 5 for some reason.
It was also the quickest way to get root. Stop-a would drop you into the monitor, then b -s to boot into single user mode. Congratulations, you are root, now just edit /etc/passwd to put in a new user "toor" with uid 0, and reboot into multiuser mode.
That didn't work for us a we netbooted everything off an e1000 and used the local disk for swap only.
I still had the e1000 (and disk array) which was skip dived until last year but the wife made me get rid of it :( She didn't want that kind of coffee table...
I still had the e1000 (and disk array) which was skip dived until last year but the wife made me get rid of it :( She didn't want that kind of coffee table...
100+ upvotes for a lmgtfy answer :(
That wasn't a lmgtfy answer. It was a constructive link to an encyclopaedia article, with a relevant quote from that article, and a relevant image. There were also links to other sources of information.
lmgtfy is hateful because it often links to the same search that the asker has previously done, and returns the same not-useful hits. But the answerer doesn't check the returned hits, and just smugly slaps lmgtfy in to "teach" the asker a lesson about searching before asking.
lmgtfy is hateful because it often links to the same search that the asker has previously done, and returns the same not-useful hits. But the answerer doesn't check the returned hits, and just smugly slaps lmgtfy in to "teach" the asker a lesson about searching before asking.
Sometimes people just don’t know how to search for the topic that interests them. Asking the question is the only way they will find the answer. In that case, adding a well-framed presentation of your better-informed search results, along with some links, is actually a net gain. Search engines can now index your answer and ultimately enable fewer questions like this.
Thanks for this post.
Welcome! :-)
Actually, I stumbled over that question during my quest of unifying my keyboard-layouts (Mac=Work and Linux=Private) via xmodmap.
Actually, I stumbled over that question during my quest of unifying my keyboard-layouts (Mac=Work and Linux=Private) via xmodmap.
Is that even possible? No matter which way I've tried mapping the keys on OS X, something just can't be placed in the right spot on the keyboard - mostly because many uses of CTRL are placed on the equivalent of Mod-4 (the Command key).
Unless you're just trying to simulate an Apple keyboard configuration on Linux, that is.
Unless you're just trying to simulate an Apple keyboard configuration on Linux, that is.
The ctrl location on that old machine is much more handy. I've changed my caps lock to ctrl for years.
Same here. I do, however, hate that most keyboards have a `stepped' Caps Lock key, presumably to stop people accidentally activating it when they type an `a'. Thankfully, my laptop doesn't, and neither does my keyboard at home.
Considering I started on the early PCs (XT), I'm too used to the CTRL key where it is... I have a real problem on lenovo, and similar keyboards where the Fn key is in the corner. I also discovered, I favor the right shift, which makes a lot of mini/htpc keyboards a pain... the one I am on right now has the shift to the right of the up arrow.
The escape key is also in a better place.
On a side note, stackexchange is getting pretty impressive.
http://stackexchange.com/sites
http://stackexchange.com/sites
[deleted]
I really have my problems, to wrap my head around "hjkl", as there is (imho) no logical mnemonic for the directions. It is sadly just "learn by rote".