Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Workman Layout for Vim

axiomatic.neophilus.net

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Workman Layout for Vim

#41

Post by lawn »

byebyebyebye wrote: post #26

First time hearing about this keyboard layout. I wonder how much marginal efficiency there is to be gained. My hands' physical travels reduced by a lot ever since I learned vim. But I don't think optimizing fingers' travel would give as much boost in overall speed. On the other hand, though, you can argue that fingers travel between keys a lot more often than between keyboard and mouse. What's everyone's experience?…

> What's everyone's experience? Was it worth it for you learning another layout?

I designed my own layout to fix my RSI, which was very worth it. But I don't think it's worth it if you're after speed, the effort is better spent practicing typing IMO.

I wrote big lost about my experience here: https://www.jonashietala.se/blog/2023/11/02/i_designed_my_ow...

Re: Workman Layout for Vim

#42

Post by eviks »

lawn wrote: post #39
eviks wrote: post #36

Earlier quoted context omitted.

In reality there is very little meaning, there is just this false sense there is that keep all these bad defaults in place. Like, is it word forward or word backwards? W doesn't tell you. So if you're used to qwerty W it makes perfect sense to keep the much stronger muscle memory intact when switching layouts and use non-W in the same spot

It does make sense because Vim by default is forward looking, so `w` moves forward a word and the secondary effect is to move backward with `W`. As another example `diw` reads "Delete Inner Word", or `dap` reads "Delete Around Paragraph". It's way easier to just learn the new new keys and rely on the mnemonics IMO.

Still doesn't, the forward looking part is misapplied for movements where you have both directions in separate keys (this principle could work for ops similar to tT (forward by default, backward shifted)), just like you can't explain why B is moving backwards by Words, not characters or something else (is there another important context you need to know that "vim is word looking by default"?). Or why it's not Below to move down

And in your D example your skipped the first part - why is it not delete forward/backward by character/word? Why is it not Dump for paste just like there is this weird Yank for copy? Why not Do to execute some command? Or maybe D should do something tied to its looks. After all X is delete based on visual mnemonic of crossing something out

It's even easier to learn relying on physical position mnemonics (like of your index J is go down by line, then go down by page is also index, but lower, so M). Or have adjacent fingers move left/right just like they move in cursors

(Btw, letter based mnemonics are also not useful for most of the world since they're tied to English)

Re: Workman Layout for Vim

#43

Post by lawn »

eviks wrote: post #42
lawn wrote: post #39

Earlier quoted context omitted.

It does make sense because Vim by default is forward looking, so `w` moves forward a word and the secondary effect is to move backward with `W`. As another example `diw` reads "Delete Inner Word", or `dap` reads "Delete Around Paragraph". It's way easier to just learn the new new keys and rely on the mnemonics IMO.

Still doesn't, the forward looking part is misapplied for movements where you have both directions in separate keys (this principle could work for ops similar to tT (forward by default, backward shifted)), just like you can't explain why B is moving backwards by Words, not characters or something else (is there another important context you need to know that "vim is word looking by default"?). Or why it's not Below t…

Just because you could apply a different meaning to a character doesn't change the fact that some meaning, once learned, is more helpful than only relying on physical positions.

Combining meaning with a physical position is even more superior than purely relying on one approach.

And to me, it was far easier to switch layout while relying on mnemonics than on key position, and this continues to be true even when I add new keybindings now when I switch between multiple layouts. Maybe other brains works differently though.

Re: Workman Layout for Vim

#44

Post by eviks »

lawn wrote: post #38
eviks wrote: post #35

Earlier quoted context omitted.

How is it best when it's just bad? Why would you make the ergonomic of shortcuts worse when the big point of another layout is better ergonomics?

Because the economics aren't "just bad". The only shortcuts that might be worse on an alternative layout is hjkl, and you can argue that people way overuse them and it's better get into the habit of using other movement keys instead. I've found that Vim ergonomics are way better on my own layout[0] than on qwerty, despite hjkl not being on the home-row. [0]: https://www.jonashietala.se/series/t-34/

Yeah, "the only shortcuts" worse are the most used ones!

And overuse argument isn't enough to even move them (it's an argument to maybe move word-based movements to the home row instead of them, but not to just move them out), let alone split them!

Your layout isn't relevant when talking about Colemak, it's trivial to make Vim way better even on qwerty since the defaults are very bad, so of course there are layouts where these letters magically appear in more ergonomic position, the argument is that it makes no sense to make it worse just to stick to the labels

Re: Workman Layout for Vim

#45

Post by johncoltrane »

linsomniac wrote: post #5
johncoltrane wrote: post #4

Earlier quoted context omitted.

^H, ^J, ^K, and ^L _had_ meaning and that meaning is why hjkl do what they do. Their location on the homerow of a number of layouts is an accident. And they are not very useful in practice anyway. "Remapping" the whole keyboard around them is IMO a silly idea.

How do vertical tab and form feed relate to "up" and "right"?

You would have to ask to the engineers at Lear Siegler who made that decision many decades ago.

That choice and the subsequent decision to print the arrows on the corresponding keys of a single model of their product line are why we got hjkl for cursor movement in Vi first… and now seemingly everywhere.

Re: Workman Layout for Vim

#46

Post by eimrine »

eviks wrote: post #42
lawn wrote: post #39

Earlier quoted context omitted.

It does make sense because Vim by default is forward looking, so `w` moves forward a word and the secondary effect is to move backward with `W`. As another example `diw` reads "Delete Inner Word", or `dap` reads "Delete Around Paragraph". It's way easier to just learn the new new keys and rely on the mnemonics IMO.

Still doesn't, the forward looking part is misapplied for movements where you have both directions in separate keys (this principle could work for ops similar to tT (forward by default, backward shifted)), just like you can't explain why B is moving backwards by Words, not characters or something else (is there another important context you need to know that "vim is word looking by default"?). Or why it's not Below t…

> you can't explain why B is moving backwards by Words, not characters or something else (is there another important context you need to know that "vim is word looking by default"?).

Yes, there is some concept inside of this. Some commands are singular such as zz, some are paired (allmost all), some are double-paired, and only one set of commands is triple-paired, this is the list:

w W b B e E ge gE

Take care to find the logic by your own, please.

Re: Workman Layout for Vim

#47

Post by johncoltrane »

lupire wrote: post #11
johncoltrane wrote: post #4

Earlier quoted context omitted.

^H, ^J, ^K, and ^L _had_ meaning and that meaning is why hjkl do what they do. Their location on the homerow of a number of layouts is an accident. And they are not very useful in practice anyway. "Remapping" the whole keyboard around them is IMO a silly idea.

Nope. hjkl are arrow keys. https://catonmat.net/why-vim-uses-hjkl-as-arrow-keys

"hjkl are arrow keys" because the arrows are printed on them and the arrows are printed on hjkl because pressing ^H, ^J, ^K, and ^L is what moved the cursor on the screen of the ADM-3A.

Re: Workman Layout for Vim

#48

Post by johncoltrane »

eimrine wrote: post #29
johncoltrane wrote: post #4

Earlier quoted context omitted.

^H, ^J, ^K, and ^L _had_ meaning and that meaning is why hjkl do what they do. Their location on the homerow of a number of layouts is an accident. And they are not very useful in practice anyway. "Remapping" the whole keyboard around them is IMO a silly idea.

> ^H, ^J, ^K, and ^L _had_ meaning I can parse only High and Low which is what ^H and ^L do.

On the ADM-3A, moving the cursor on the screen was done by pressing ^H, ^J, ^K, ^L. The convention had been established by no-one-knows-who at Lear Siegler even before that specific terminal model came out.

Re: Workman Layout for Vim

#49

Post by johncoltrane »

eviks wrote: post #36
johncoltrane wrote: post #2

This makes no sense. It is _meaning_ that bounds certain Vim commands to certain keys, not the position of the keys on your keyboard. Moving the keys around doesn't change their meaning—"w" is still "w", for "word"—so making all those mappings is utterly pointless. Unless one uses a layout different from that of their physical keyboard, in which case WTF?

In reality there is very little meaning, there is just this false sense there is that keep all these bad defaults in place. Like, is it word forward or word backwards? W doesn't tell you. So if you're used to qwerty W it makes perfect sense to keep the much stronger muscle memory intact when switching layouts and use non-W in the same spot

Single-letter commands have a clear meaning once you have learned enough of Vim. https://stackoverflow.com/a/7411851/546861

> Like, is it word forward or word backwards? W doesn't tell you.

W doesn't have to tell you anything. W being the reverse of w is a grammar rule that is supposed to be learned and internalized, like the other grammar rules (count, etc.).

> So if you're used to qwerty W it makes perfect sense to keep the much stronger muscle memory intact when switching layouts and use non-W in the same spot

No. What would make perfect sense would be to retrain your muscle memory around your new layout.

Re: Workman Layout for Vim

#50

Post by eviks »

lawn wrote: post #43
eviks wrote: post #42

Earlier quoted context omitted.

Still doesn't, the forward looking part is misapplied for movements where you have both directions in separate keys (this principle could work for ops similar to tT (forward by default, backward shifted)), just like you can't explain why B is moving backwards by Words, not characters or something else (is there another important context you need to know that "vim is word looking by default"?). Or why it's not Below t…

Just because you could apply a different meaning to a character doesn't change the fact that some meaning, once learned, is more helpful than only relying on physical positions. Combining meaning with a physical position is even more superior than purely relying on one approach. And to me, it was far easier to switch layout while relying on mnemonics than on key position, and this continues to be true even when I add…

> Just because you could apply a different meaning to a character doesn't change the fact that some meaning, once learned, is more helpful than only relying on physical positions.

It does precisely that - because "once learned" muscle memory / spatial orientation would beat your conscious efforts to map ambiguous semantic rules every time since they're more common/primitive/intuitive ("move finger up to move up")

> And to me, it was far easier to switch layout while relying on mnemonics than on key position

So wait, you've seriously tried home row cursor movements in different layouts, then seriously tried moving to keycap-based cursor, and found home row keys to be worse despite their objective ergonomic benefit that the alternative layouts tout as their benefit over qwertys?

Post reply on HN