H4cker extension for kjoetoms EN/DE 60/40 keymap (for terminals and programming)

[martin-braun]

@kjoetom shared some nice German + English optimized keymap with all European letters, so you can write in other Latin languages with it. My only problem with it was, that there was no space for special characters in the "short"-cuts. For some basic characters in programming I have to make big circles around the board, I wanted some better shortcuts. Due to space issues, there is only room for short NO_TOUCH keymaps, meaning that you have to lift the finger to type them, thus less elegant for writing letters, but should be less of a problem in Vim and co. Also there are versions with additional spaces, to make it a little more fluid.

Here is my the entire Yaml configuration incl. my add-on and his contribution: https://gist.github.com/martin-braun/3e3948413ba76532ada4956a223c5ad2#file-de_regular_german_kjoetoms-time-moves-1_mb-h4cker-edition_de60-en40_ext-yaml (Direct download)

[kjoetom]

@martin-braun I think your extension can be a really great tool for programmers.

I just checked if your extension is compatible with my xml-file regarding the movement sequences. As far as I can see, there should not be any problems if you extend my xml-file with it.

To check, I created and used a table. Then I thought that this could also be helpful if you want to look up the movement sequence of a particular (special) character.

So if you want, you can use the following sortable LibreOffice Calc table for this.
MovementSequences_._InputStrings.ods

For people like me who don't program, the effort of learning the required sequences is probably too much in relation to the benefit.

kjoe

[martin-braun]

@kjoetom Thank you! Yes, I had to build this when SSHing on a server from my phone and editing configs and such. The use-case is very minimal, programming on Android is not really a thing.

Thank you for the table. Unfortunately, it trims spaces. I went ahead and build a little Python script to generate a text file with compressed information. I copied and renamed your XML, enhanced it, and created a text file from it using the command ./8vim2txt.py de_regular_german_kjoetoms-time-moves-1_mb-h4cker-edition_de60-en40_ext.xml > de_regular_german_kjoetoms-time-moves-1_mb-h4cker-edition_de60-en40_ext.txt.

I believe using only letters for the maps makes it easier to read, also the NO_TOUCH is redundant, since it's always the case when the map is not a fluid INSIDE_CIRCLE-surrounding sequence.

I might add a few more things in the future, then I will update everything.

Thanks. :)

[martin-braun]

I now added shorter versions of !, ? and ., so I can spam those easily to emphasis without making too many circles, i.e. "really???" or "wait a second ...".

[flide]

@martin-braun Maybe I can add a configurable option to turn on or off these programming extensions to the keyboard, so that it does not hurt the uninitiated. But we would need a nice wiki page for all the additions you made.

[martin-braun]

@flide Cool idea, but how can we ensure that it will not collide with existing maps?

Let's say we extract my extra maps from my German+English keymaps, so that we can add those maps to the current keymaps of the user without him/her having to modify stuff just within the app. Then you have the potential that it might collide if the user indeed decided to make an own keymap.

If you ask me for my personal take about how this app should develop: You should make the keyboard mapping accessible and configurable right into the app settings. You'd need an UI to define new keymaps and this UI should also provide on/off toggles, so that you could add my extension maps to all layouts, but have them disabled by default. If you could introduce grouping of mappins you could also put my maps into a "programmer" group, so that the user could enable my mappings with a simple tab.

The benefit of this is that the user could also build his/her entire keyboard for himself/herself, but a new keyboard layout would require to setup everything. However, a user could also decide to make a duplicate of an existing keyboard to make adjustments and this would be the true benefit at this point: Big customization options without the pain to build own maps like we did.

I think this would be fundamentally the right direction to go to. Please tell me what you think about that. :)

Lastly this German+English keyboard should also be part of the preinstalled keyboards, as well as other bi-langual keyboard layouts, at least for English+XXX and maybe Spanish+XXX.

A lot of people on the world speak English and Spanish in addition to their mother language, so it feels natural to have those options available right away.

Finally, the number shortcuts are just too useful to be excluded from any layout if you ask me.

Another thing is that my current layout also supports to write large letters without caps or double round-trips, by moving back and forth on the final intersection right before entering the center field. This is another improvement that should make it into all keymaps, please check @flide's keymap here: #254 (reply in thread)

[flide]

Yea, not a new idea... sorry. I have wanted a way to have this ui to allow user to define his/her own keymaps from the very start, but the ui/ux seemed daunting and then language keyboards started, which solved a lot of the issues so I shelved it.

[martin-braun]

@flide I get ya, it's a lot to do to get things like those working. If you want to have a common middle ground, here is an alternative idea:

Implement a sort of keymap repository that allows to install alternative keymaps with changes. You need a preview mode for all hidden maps as well. The community will care about the rest, like adding more enhancements to existing keyboards and thus they will care about avoiding any conflicts.

Best regards!

[kjoetom]

Hi martin-braun,

Maybe the layout creator would be an option, which I presented in "Show and tell" a few weeks ago (#295). It's based on LibreOffice Calc and you just enter the letters and characters and it creates an xml file for the layout. You could just replace the unneeded diacritical characters with those you need for programming.

Or maybe you could at least use the layout representation for documentation purposes.

kjoe

[martin-braun]

I updated my post to include the full layout file in the new Yaml format that should work with recent versions of 8vim.

[kjoetom]

Great. I am not sure wich post you are referring to.
But I am curious to see what the finished yaml-file looks like. Maybe I can then adapt my layout creator spreadsheet accordingly

[martin-braun]

@kjoetom The file lost the capitalized shortcuts, though. See 8VIM/8vim-migration#3 and please consider supporting #330. I will update the Yaml once more when the migration is fully functional, so writing uppercase letters will be of ease, again.

[martin-braun]

@kjoetom I updated the Yaml, now it should feature everything we had before. I've changed the migration logic, so that it will map everything to the hidden layer to bypass the issue (see 8VIM/8vim-migration#4). So, we now have redundant entries in the hidden layers section, but at least all mappings are complete now.

Best would be to find a way to clean those redundant entries without deleting the necessary additional ones. The original quadrant detection simply had false positives causing a lot of our custom experimental keymaps to be missed in the output.

We also need a keymap explorer for those Yaml files to give users the opportunity to find letters and learn keymaps in general.

[kjoetom]

Well done - thanks for this. I have just been trying out the layout and it all seems to be working.
I had forgotten that you even included the "handwritten" numbers, which I particularly appreciated.

I've been thinking about how to visualise characters whose strokes don't start in the middle, but I don't have a good idea yet.

[martin-braun]

@kjoetom I love your "handwritten" numbers, so yes, they are part of the game. This is basically your brilliant layout with my symbol extensions on top.

In regards of your visualization attempts, I think your prior attempts were reasonable, but not practical enough, because you would try to show all possible combinations by showing the path that leads to the character. Imho, this is the wrong approach.

What I think is way better is to show the characters that lead to the sequence to take, because that's what the user is interested about. The question is always "How to I write the letter ...?" and the answer should be to find the letter and get the path to take.

Because of this, I made the text file listing the letters first, following the sequence in simple letters to reduce the cognitive overhead as best as possible. However, it still requires to use the search function which means you have to write the letter to find the letter that you want to write .... not good.

If we could group letters and symbols together and present them in a way that a path can be seen from following the letter, it would be perfect. Something like a mind map that cares about the characters, not the paths.