Does there exist a modified Colemak keyboard layout designed specifically for programming?
I went cold-turkey on the Colemak keyboard layout a few days ago and I really like it for normal typing, but I have some issues for frequent programming characters like the ; (semicolon) key. A modified layout that has direct mappings for braces and parentheses would be nice.
Obviously I could remap these keys myself via trial-and-error, but I'm hoping someone has done some testing to determine an optimal layout for common language characters.
Background
I am obsessed with efficient workflows, and the results from my experiments are very compelling and I guarantee it is very much worth the endeavour. This is also my third major edit, and I have more or less settled upon the layout I use today.
I will be try to be brief and to the point.
Current Layout:
Your fingers rest on the highlight
Wide Angle Mod: Right hand has shifted one column. Benefits:
Less stress on right wrist
Layout is now symmetrical
Shift R + Level5 is easier to reach.
8 layer layout requires 3 modifiers:
Shift
Level3 usually known as Altgr
Level5
include "level3(lalt_switch)" // Left Alt
include "level5(ralt_switch)" // Right Alt
level5 is very obscure and extremely useful to know about, if you wish to expand. For example, on my layout, it would allow for around 200 extra characters to be added.
How 8 Layers works
Layer:
No modifiers
Shift
Level3
Level3 + Shift
Level5
Level5 + Shift
Level5 + Level3
Level5 + Level3 + Shift
Numbers
Accessed solely on Layer3
A programmer who uses numbers often, is a bad programmer. See:
https://en.wikipedia.org/wiki/Magic_number_%28programming%29
This was why it was taken off of Level1 ( No Modifiers )
For convenience, it is arranged in a number pad.
1230, constitute the most common numbers, and hence are found on the home row.
The right hand number pad has close access to -+.,#%$*/\;:=, the most relevant mathematical operators.
I search for keys about 10× less compared to a standard 1234567890 layout. I find this much easier and more intuitive to use.
Alternative Characters ( Requires Modifier )
The least common alternative characters were delegated to Level3 and Level5 modifiers. They were mapped with the following reasoning:
# resembles Q
& resembles B
$ resembles Z
× resembles X
~ resembles W
` is on C, "aCute"
| is on V, "Vertical pipe"
% is on M, "Modulus"
# is on H, "Hash"
< and > Easy Access for writing html etc.
^ is next to < and >
+ and - is next to the Numbers, with - easiest to access
Alternative Characters ( No Modifier required )
Generally the most common programming characters that you will type exist here:
? ! in the corner, because they typically close off sentences. Colemak was designed that letters that end sentences are more common on index and middle fingers, and placing it here on the pinky improves hand movement. ! also remains on its original position.
[ and ] are easy access, because Regular Expressions tend to use them a lot. They mirror ) (.
) ( are reversed because it is easier to roll the fingers from the pinky to the index finger. The following trigram is also very common: (); and works best in this orientation.
" is on an easy access area, and mirrors '.
' is on the opposite hand as s which is important for the 's bigram.
{ } are usually automatically handled by editors, so they are placed in the hardest to reach region.
* and / are for the /* bigram and are common vim commands.
\ is on the right hand at the far corner, to resemble Escape and to work best with the following bigrams, \t \n \r
; : = are all similar, and resemble Return. Again, because they exist near the corners, and they typically end sentences, they work best on the Pinky and Ring Fingers.
Prior Next aka Page Up Page Down are directional keys in the middle. This is exceptionally useful on Thinkpad Keyboards, as they are right next to the Trackpoint. Even without the trackpoint, it is nice when it comes to just scrolling through documents. The reason why they are not the same as Page Up Page Down is to grant more flexibility for run configurations.
_ the underscore here works well for writing object names, and works well with the m_ and s_ bigrams. It also is not a letter because that makes shifting it a painful exercise.
Directional Keys
Inspired by Vim
Without the "Wide Angle Mod", the thumb will cramp up reaching for Level5
Amazing for editting regular documents.
Letters
Shift + [A-Z]
Capslock and Enter Removed and replaced by Shift
Shift's are replaced by Control
Shift's are 3× more comfortable
Control's are 5× more comfortable
Capslock was not missed. Prefer it as Shift over Backspace or Escape provided that I have access to those keys on Level3 or Level5
Return
Placed on the o because in vim, its functionality is similar to Enter.
Sometimes can cause issues with Games which will not detect it.
Surprisingly, not a big issue. I would consider it maybe 1.3× more difficult to use compared to its original position, which is great tradeoff to be able to get Shift on the home row.
Functional Keys
Accessible by either modifier.
Backspace is on the left pinky, to be intuitive with the direction you are deleting.
Delete is on D, and is intuitive with the direction you are deleting.
Escape for some reason, feels best on the Ring Finger, rather than the pinky.
End and Home are inspired by a colemak Vim configuration:
InSert, which will go to the beginning of the line before editting.
Append being on the T, which goes the opposite direction.
Backspace is used 10× more ( Meaning that I will use the Home Row position 10× more, rather than its default position. ).
Delete is used about 20× more.
Escape is used about 15× more.
Home and End is used about 200× more often and utilized far more often, being especially useful in editting documents outside a vim environment.
Todo:
If you are up for the challenge, there are some useful ideas I have played around with, however was not able to formally add to the layout simply due to the difficulty of doing so.
In short, you could theoretically map characters or functions to the modifier keys, that only execute upon a key release. For example,
Press Shift and no other keys
If you release it within 1 second, Its alternative key would execute.
And that's that.
Lazy Installation:
Go here: https://paste.ubuntu.com/p/TbJJkm2vxM/
sudo vim /usr/share/X11/xkb/symbols/us
Replace the contents
WARNING: This will replace your default Colemak.
Configuration Files
.vimrc: https://paste.ubuntu.com/p/JSKMwrPMPY/
~/.config/sc-im/scimrc: https://paste.ubuntu.com/p/Vx64STMtHC/
.config/qutebrowser/config.py: https://paste.ubuntu.com/p/mcymX92tBF/
I realize this question is already a year old, but here is my reply in case it helps anyone else.
This is a problem I have dealt with more often than I care to elaborate.
Suffice it to say that no, even after months of search, I have yet to find a suitable "Colemak for programming".
It has the same annoyance as the usual QWERTY in overusing the right pinky for special symbols and a remap would have been desirable, but now that the mess is done, there won't be any immediate solutions.
There's only two things you can do:
1) Make a custom layout keyboard. There are various tools to do this on Win/Lin/Mac. This is neat as you can just rearrange everything as you see fit. The huge drawback, on the other hand, is that nobody else uses your keyboard layout, and if you ever are asked to type something on a computer, you will be in trouble, as your muscle memory is entirely different.
2) There is a keyboard layout called Programmer Dvorak, which aims to solve your problem. Here, the drawback is that programmer Dvorak is relatively unknown compared to the standard Dvorak keyboard, so same issue as above. It only rearranges special symbols, however, which means you could still use the standard Dvorak if so required (and it is far more widespread than Colemak). Be prepared to spend months in the transition, though.
Alternatively, you could try and opt for a third option and try to persuade the Colemak community in developing a programmer-friendly version of colemak. But this will take time and I wager you will find few supporters.
have you had a look at the dreymar wide angle mods on colemak.com?
you could stick the ; in the middle of the keyboard for easy access with [ and ] above and below it perhaps?
Related
I am trying to understand the Sliding Window algorithm for pattern match. I came across KMP and Rabin-Karp and these looks to be using Sliding Window way of finding pattern in the text. Can we classify KMP and Rabin-Karp types of Sliding window algorithms ?
Classification is always tricky. We can't really do it without a strict definition of what we are talking about, and such definitions are often rather arbitrary.
That being said, in my head a sliding window algorithm has a fixed-sized window that it shifts along the sequence, in each iteration moving a bit of the left part of the window out and shifting the same amount in from the right. With that definition, Rabin-Karp is clearly a sliding window algorithm. In each iteration, it removes one character on the left and add one from the right to update the hash value.
Knuth-Morris-Pratt doesn't do this. You certainly can think of it as having a window, but this window is a border of the prefix of your pattern that you currently match, and when you can extend the match the window size grows, while when you cannot match, it shrinks to the length of a shorter border. The size varies from zero to the length of the pattern during a run of the algorithm.
That being said, my definition of a sliding window algorithm is arbitrary, and others will surely disagree.
Is it useful to have this definition? I think it is. The sliding window idea is an abstraction that might let us construct new algorithms. Do we lose anything by allowing variable size windows? Perhaps not. But what do KMP and RK have in common that we can abstract to something that might be useful?
I don't think there is a lot. They scan the string from left to right (unlike e.g. Boyer-Moore), but they don't share much beyond that. One is hash based, the other is border based. The details are completely different.
You can always come up with a classification where they both will fit, but unless that class tells you something beyond the trivial, there isn't much use to it, would be my opinion.
Today I'm trying to do some nnoremap in vim.
Some keys have special meanings in this map, such as C for Control
I read these official two docs, and didn't find the representation map.
http://vim.wikia.com/wiki/Mapping_keys_in_Vim_-Tutorial(Part_1)
http://vimdoc.sourceforge.net/htmldoc/map.html#map-which-keys
I tried find all these representations, but I can't, maybe it's something like common sense?
But it's always these hidden common sense which hindered lots of beginners.
So far I find only some of the special keys can be the initial keys.
For example:
I can do <C-J> but not <SPACE-J> as {lhs}.
And it seems only special keys can be used in sequence greater than 2.
Like I can do <C-A-J> but not <C-K-J>
What are all the representations of these special keys, and what hidden rules are unknown for me to use sequences greater than 2? Is it able to use a special key + 2 normal key?
ps: So far I only know:
`C` for `Control`
`A` for `Alt`
`S` for `Shift`
But it seems there are B, M, D, etc. What are they?
Yes of course, there is such a resource, see :help key-notation.
Vim has slightly different capabilities in this regard depending on the platform and environment as well as a notoriously archaic key-handling mechanism so you are relatively limited.
For portability purpose, it is recommended to stick with universally usable mappings as much as possible. Mappings to avoid are (from the top of my head):
anything that involves the Alt key
anything that involves the Cmd key (works only in the GUI incarnation of MacVim)
anything that involves a modifier and an uppercase character
Short of writing my own plugin to do so, does there exist a mechanism with which I can add/subtract from multiple selected numbers?
I need to apply the same equation (in this case, subtract 5) to many values; and I'd rather not do it individually. Could this perhaps be a job for another program?
If you already use Emmet (which I highly suggest), use its Evaluate Math function. No need to install more plugins. Only issue is that it cuts the result at 2 decimal digits.
There's plugin called Sublime-Evaluate which allows you to evaluate bits of Python, and output it straight into your buffer. For example, [i for i in range(5)] evaluated turns itself into [0, 1, 2, 3, 4]. That can be used for arithmetic operations as well, just use those multiple selections and write +5 after each value, then select it all and evaluate. The plugin usually screws positions of your cursors, don't get confused by that.
Sublime Calculate evaluates selected text, and looks great for small calculations, especially paired with the replace option: https://github.com/colinta/SublimeCalculate
As stated before, Sublime Evaluate has python evaluation covered: https://github.com/jbrooksuk/Sublime-Evaluate
Saw this yesterday and thought I would take a shot at it. Basically does the same thing as the Sublime-Evaluate (to bad I didn't see that earlier, could have saved some time). Anyways, the benefit of mine is it allows you to predefine python snippets to run. It also does some variable substitution of the content selected by the cursor. It doesn't do any expansion so you will have to select the content to insert. I was thinking of creating a setting to modify the word separator for the plugin, but hadn't decided yet. If you have an opinion on it, let me know.
https://github.com/skuroda/EvalInsert
Suppose you are on line 640 and notice the following on line 671:
if (jumps_over(quick_fox[brown],the_lazy_dog)) the_lazy_dog.bark();
What would be the most key efficient way to navigate to "bark"?
This is a common misconception about Vim: Vim is not designed to be efficient.
Vim is designed to use small building blocks in repeatable, often complex combinations, to achieve your goal. It is not an inherently efficient process, but for a subset of complex tasks, it's useful. For example, [motion][macro], or [count][command], these are small building blocks combined together in chains. Clicking on the screen is the most efficient movement, but might not be useful in a subset of a large text manipulation task where you have to do it thousands of times.
Here are all the ways I normally use that I can remember, you can see none of these are efficient uses of movement nor my cognitive processing power. (IDEs do things efficiently by taking out all the work listed below).
Once on the line I would personally use f.l since a quick scan shows that's a unique character. Or T. if you're past it. If there ends up being more than one . I would use ; to repeat the find until I got to it. Or, mash w or W until I got close, since trying to guess where lowercase w will take you when punctuation is involved is basically impossible in Vim.
If you have :set relativenumber on you can see how many lines away it is, and type nj to go there, then type f. to jump next to it to it
If you have :set number on you can type (since you'd know the line number) 671G (or :671Enter) f.
If you had marked that line with, say ma you could jump to the line with 'a or the exact char with `a (but most keyboards make ` useless to reach :( You probably won't use this one if it's a random look-need-to-fix jump.
If you have EasyMotion installed you could type leaderleaderfbsubchar to jump right to it
You could search for it as #kev suggests and use nN to bounce around until you get it. If bark is common but the_lazy_dog is unique you could do /dog.b/eEnter (e places cursor at end of match) and pray to the Vim gods that your search was specific enough to only match that line. That's more of a fun guessing game.
Depending on where the line is on the screen, you could use (n offset)H, M or L (high middle low) to get closer to it and use jk once there.
Or if the line has empty lines above / below it you could type the super handy { or } to help you jump close.
Or you could use the mouse if you're on a laptop where the trackpad is nearby + in gvim . I'm serious about that, even though I'd probably never do it. if you've played enough first person shooters your trigger finger may be more accurate and fast than any keyboard shortcut ;)
Despite all of Vim'm crazy keyboard power, there is not always a direct nor good way to do something, like very specific jumps. You need to keep and continuously build a bag of tricks to help you move around and use the appropriate ones for the job. I use all of the above fairly evenly and often (I use relativenumber), depending on what I think would be fastest. EasyMotion is pretty handy except that 5 keystrokes to perform one command is really awkward and error prone to type.
So in my humble few years of Vim experience, I'd say there is no good way to do it, but there are a lot of mediocre ways, that you can combine into a decent way.
Press /barkEnter. (maybe n is required)
(It depends on the shape of text. Without the information, I cannot provide a best way.)
If you wanted to increase the likelihood of a hit (ie. reducing the likelihood of having to hit n) using #Kev's suggestion, perhaps change your regular expression to include more text and offset your cursor from there. eg:
/dog\.bark/e-3
Turn on relative line numbers and the 31j becomes a VERY natural motion; this gets you to the line you need to be on.
Then, look for a unique character to the line near where you want to be. In this case . is unique and just before bark. So, f.. Then l and you're good.
So in total: 31jf.l.
(This is not always how it will work. Sometimes it's just as quick to use /bark once you've jumped to the line. Sometimes it's quicker to use /bark initially and just n a number of times to the line. Vim give you the tools, your code will always differ.)
Kev's answer works assuming bark is an uncommon word. You could be hitting n quite a few times.
I'd go with
671G to jump to the line,
$ to jump to the end of the line, and
2b to drop the cursor on the b.
Edit: reading over Andy's answer, I really have to agree with this:
Despite all of VIM's crazy keyboard power, there is not always a direct nor good way to do something, like very specific jumps.
I would opt for navigating around in approximate steps, like 9j to go down 9 lines. When you do this on reflex, you can navigate much faster than it takes to read line numbers or character position. It might end up being more keystrokes, but I prefer the extra speed.
Actually, I don't want to say that I think the most efficient way is use your mouse,
another way use command line:
/.*dog\&.*bark
this will reduce the frequency compared to /bark(and many n maybe)
One way of jumping to char on the same line was not mentioned, yet.
Use
61|
61"pipe", to jump directly to [b]ark in control mode.
I didn't incorporate this into my regular jumping, because the number is usually a guess. with with fixed 80 chars per line you can get used to it and it will be very efficient. But the pipe key is inconvenient imo. I'm planning on using it more often because of its elegance and efficieny.
In many scripts that I write, I often construct programs in a "functional style". That is to say, I basically define a lot of functions at the beginning, and then later apply these functions. This results in a sequence of nested function calls, wherein I type out:
function name
its arguments
next function name
its arguments
...and so on.
For cases in which functions are "piped" together, the output of one function is an argument (usually the first, but not always) to the next function, the output of which is an argument to the next function, and ad infinitum. In prefix-notation, the key movements can be very jumpy if you type out this sequence from left to right. For example, how would you type out the second line of the following [Python] example (~mul~ is multiply, ~truediv~ is divide)?
from operator import add, mul, truediv
print(truediv(mul(add(1,1),2),4))
If I had to write the same set of operations linearly (from left to write, without jumping around), I am more likely to use the notation of function composition. Building on my previous example in Python, I might write
from functional import foldr, compose, partial, flip
print(foldr(compose,add,(partial(mul,2),partial(flip(truediv),4)))(1,1))
I think this is because I associate each function with its own arguments and prefer to type them out in succession, rather than filling arguments to another function before the argument list for the first function is complete (as would be required to type out the first example from left to right).
I noticed this because I've been an emacs user for a long time and only recently tried out viper/vimpuse and vim. In emacs, I might do something like
[type function name and arguments]
C-a
[type next function name]
C-e
[fill in rest of arguments]
C-a
[type next function name]
C-e
[fill in rest of arguments]
...and so on, with occasional use of M-b, M-f, M-DEL (backward-word, forward-word, backward-kill-word) if I mess up or forget something.
I recently found out about C-o in vim, which is a lifesaver - but I find that the equivalent keys would be
[type function name and arguments]
C-o 0
[type next function name]
C-o $
[fill in rest of arguments]
C-o 0
[type next function name]
C-o $
[fill in rest of arguments]
...and the rest; backward-word, forward-word, and backward-kill-word equivalents would be C-o b and C-o w, and C-w.
So this got me thinking that to program in vim, I may have to grow a larger working memory, so that I can pause the construction of one function as I fill out another, and so on down the stack. Also, in construcing text documents, I find that I edit (kill, copy, yank) quite frequently even before I finish a complete thought, which is not so amenable for vim's operational style of "stay in normal mode, burst of text in insert-mode, and back to normal mode", which seems to presume that I am capable of producing something worth editing during my forays into insert-mode. To use vim, I find that I deliberate more as I type to reduce the frequency of switching between modes. Is this because I'm naturally spastic, or once I master or commit a suitable range of vim key commands to muscle memory, I'll stop thinking they're so different?
If you program in both emacs and vim, do you find yourself thinking about and construcing your programs and blocks of text differently in each editor?
I used vi from the good old days of 1992 and now I use Emacs since 2001. I haven't noticed any difference in my thinking when programming functions and blocks of code. Both editors has their own peculiarities and ways of doing things, but they are not so strong that they could change your way of thinking and how you program.
I've always tried to find ways to do what I intend to do. I don't let my editor force me to do something I don't want. When I do procedural programming of a new piece of code, I use the technique called "wishful thinking" that is mentioned in Structure and Interpretation of Computer Programs :
You imagine yourself in the perfect world having all the procedures you need at your disposal. You code your algorithm with all those helpful functions that you'll need to implement but that you only have prototypes for the moment. It's similar to a top-down approach.