For example, why is the default vim cursor hjkl? Well, it's just that the arrows on the physical keyboard of one of the vim designers were drawn there. That's it. There is no deep thought in search of the best cursor position, and understanding the why is just learning a useless piece of trivia.
To address your example: Why were the arrow keys on those particular keys? Who put them there? hjkl are on the home row, and touch typists end up having the movement keys under their right hand’s resting fingers. That’s suddenly quite convenient.
This is false, h isn't in the resting place. So go back and spend more time trying to explain that historic tidbid of design before trying to defend it (I'd also be curious to know why they shifted left instead of using resting places)!
Or don't and use this obvious principle directly and change keybinds to jkl;
Or go with the muscle memory of inverted T and use ijkl
But whatever you do, prioritizing the original design is a common bad heuristic because there is no reason to think that the original designer was great (not perfect!, don't twist it), so trying to understand the original reasons is a waste of "productivity" time (but if you're curious, it's not a waste of regular time)
They were placed on those particular keys by Lear Siegler who made the ADM-3A terminal Bill Joy was using at the time he made vi. End of story.
← ↓ ↑ →
← ↑ ↓ →
Not only because the most used used direction (↓) would be closer to my "neutral" finger position, but mainly because the the keys for progressing "back" and keys for progressing "forwards would be grouped together.
Honestly, I wouldn't even mind having them spread across two rows, like U I J K
↑ ↓
← →
I don't know what your mean by "Not only because the most used used direction (↓) would be closer to my "neutral" finger position" - what is your neutral finger position?
I also got lost in the sentence about "back" and "forwards" - what is back and forwards?
Sorry, I didn't realise that was unclear. By "back" and "forwards", I mean movement through the flow of text relative to the cursor position. Given any reference point in linear text, all surrounding content either precedes or follows that point. Moving through preceding content is "going back", and moving through following content is "going forwards". When we move to the preceding line (↑) or preceding character (←), we're going "back". When we move to the following line (↓) or following character (→), we're moving "forwards". My point was that ← ↓ ↑ → effectively represents "back one character — forward one line — back one line — forward one character", which feels counter-intuitive to me.
> strongest finger, the index finger.
Interesting. As far as I now, middle finger is usually considered stronger than the index finger. Index finger might be more dextrous, though (?). Personally, I also slightly prefer the middle finger for rapid pressing over the index finger, but cannot see strong definitive advantage of either one. (I guess most of us use the middle finger for regular ↑↓ keys, as well as W/S in WASD bindings in games/project just fine, and using index finger in that context instead would feel odd.)
> what is your neutral finger position?
Mostly index finger on "K". (So I guess I'd prefer having "down" (being the most frequently used when VIM binding is involved) on "L", where my middle finger usually dwells, and "K" for moving up, if I had to invent it from scratch.)
P(old thing being good | old thing still being used after N years) is pretty high. Certainly higher than the base rate of P(new design fad being good).
Keeping your fingers on the home row is great design for keyboard-first navigation.
All software design is historically contingent so you do have a point but assuming that old design = bad design is just wrong. Some things haven't changed.
Except you've just made that reason up since vim's defaults don't follow this logic. For example, the most frequent commands of going back/forward by word are not on the home row, they follow a different principle of name-based mnemonics.
Strictly speaking, this isn't even true for hjkl, that was due to the fact that arrows were drawn there, not because the designer followed some good design principles (granted, at least the physical arrows were likely driven by that principle, though there is still a mistery of moving off resting/home keys, which might be related to the fact that cutoff ASCII H code is backspace https://news.ycombinator.com/item?id=3684763).
> Some things haven't changed.
Indeed, and that universal fundamental thing that hasn't changed is that a few random people doing design blindly can't universally create a world of good design!
Vim command layout is not perfect, the worst offender in my opinion is $ (move cursor to the end of the line), which is commonly needed, but somewhat hard to reach.
HOWEVER - when you start to use an surviving piece of still used old software, a bit of humility goes a long way. Not because software or designers were necessarily better in the past, but the reason that the software is still in use is probably because there are some benefits to it. So learn the defaults first, modify later when you understand them.
Right, just like w/b are "close enough" outside the home row completely
> but the reason that the software is still in use is probably because there are some benefits to it.
You forgot to connect this principle to this discussion. How does it make the defaults good to support your faulty conclusion that you need to learn them first?
Yes, they are close enough, and w/b are executed often.
> How does it make the defaults good to support your faulty conclusion that you need to learn them first?
You need to at least study them because assuming a priori that they are either good or "universally bad" is a faulty conclusion - and some stuff doesn't become obvious until you use them for some time.
When you start learning VIM, you will be faster with arrow keys, because you are used to them from other programs. When you get enough muscle memory, you may discover that there is some value in having somewhere near where your fingers rest on the keyboard - or maybe you will still find that you are faster with arrow keys - whatever the conclusion, it can not be made objectively before you have enough proficiency with both.
Now, you get to say it is faulty, and when one thinks about it for a minute, that idea packs a whole lot less punch.
Just want to dilute some unnecessary implied authority out of this otherwise interesting discussion.
Frankly, I always learn the defaults for the high value idea of reducing my overall configuration and maintenance workload!
Secondly, when I communicate workload to others, I don't have to do as much because the defaults are in place and useful.
These days, I tend to run defaults everywhere I can. Doing this means I do not have to a ton of configuration when setting up new environments.
I have also found those defaults do make a lot of sense. Maybe not the absolute peak sense, but more than enough.
I end up able to move and do a lot very reasonably quickly.
I also find my skills do not need to refresh as often too.
In any case there is plenty of room to disagree here, sans the idea of someone's conclusion being " faulty.
... one still can't correct the fault. You haven't answered the question of the original disconnect in arguments.
Your new arguments aren't relevant either since they're also NOT connected to the original re. bad defaults. You can have bad defaults that aren't there for any good reason and still think that reducing maintenance is more valuable! Fine, but that's a different argument!
That needs evaluation, and that need to be done in context.
In many cases, the defaults are not bad. One finds that out by working with them.
Really, I just don't feel "faulty" makes any sense.
If anything, it is more establishing a baseline.
Whether someone bothers with defeats first is debatable. I am on the work with them first side for what should be obvious reasons.
Passersby can arrive at their own conclusions and life carries on.
Re: still think reducing config and maintenance...
Yup. I have shown it many times. This also depends on context. For most of my career, no brainer.
set tabstop=4
set shiftwidth=4
set expandtab
set showmatch
set nohlsearch
set background=dark
syntax on
I'm also an IDE user though. I tend to maintain a dichotomy between emacs(with evil-mode, of course) as the "kitchen sink" set up, with all the fixings, and vim with a config so short I can type it in as commands if I need to.
Vanilla vim is really perfect for quick edits to config files, scripts on random servers/VMs etc.
Bigger projects, at least for my usage, all happen on the same system , and having a bit more involved of an emacs set up makes sense there.
I suppose one could do a similar dichotomy with vim/neovim, if one had a distaste for emacs.
(I keep most of my dotfiles in a repository called "dotfiles".)
I get the emotional value/desire for a minimalistic .vimrc, but I also need the usefulness, and that necessitates, e.g., pulling in some plugins. E.g., lang-servers are just so valuable for immediate feedback in the editor.
Over time, someone of my vimrc has been pruned away just by development that has happened in/on vim itself, which is always lovely to see.
I'm not arguing for it, just saying I've seen it at multiple billion-dollar+-a-quarter companies.
There's no fixing it, though. I can know the "base tooling with zero config" … and I'm just less productive, that's all there is too it. Customized tooling makes me faster than the base tooling. (I did start trying to find "inventive" ways to try to work around the problem, of course. My case wasn't like military air-gapped or anything, just the only connection was via RDP. So for example, copy & paste is a communication channel.)
Basically, slowly "evolving" my environment by forcing me to try new things daily, without my doing massive "learning" runs where I try batches of new things at once
Seems like using a tool to its fullest potential to get more work done is better advice.
> I would be just as quick and comfortable on any system I would likely encounter.
How often are we encountering other systems…? And even where I am rarely ssh'd into something else … are we doing so much editing of code (live in production…?) that it matters? (I heavily customize my vim, but it isn't like I'm lost on a remote system with stock vim, or nano. ed is another matter.)
But if I need tons and tons of editing, … sshfs+local vim/terminal? But this just such a rare case, it seems like one of those "we should optimize for the common case" — which this is not.
For me personally it's a classic old timer habit from the days when you had to be prepared to fix a system using only the tools in /sbin. That doesn't mean you should operate like that all the time, but you should certainly know how to do so and be comfortable doing it.
```some examples " Quick access to commonly edited config files (and a directory for my Shell scripts!) map <leader>v :e ~/.vimrc<cr> map <leader>V :source ~/.vimrc<cr> map <leader>w :e ~/Workspace/myCo/tmuxp-session.yaml<cr> map <leader>W :e ~/.tmux.conf<cr> map <leader>z :e ~/Shell<cr>
" Super simple in editor note setup, amazing map <leader>x :vs<cr>:e ~/Documents/notepad.txt<cr> map <leader>X :vs<cr>:e ~/Documents/notes<cr>
" Quick terminal pane map <leader>t :vs<cr><c-w>l:term<cr><c-w>j:q<cr> " Pull file path into clipboard nmap <leader>b :let @+ = expand("%")<cr> " Pull current line into clipboard nmap <leader>B "*yy ```
Quick disposable terminals, tons of short cuts to get me into the config files that make it all happen (vimrc, zshrc, tmux.conf, a tmuxp session file) and to reload them, and super quick access to a well organized directory of notes are all huge boons during my workday.