-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow using modifier symbols instead of their name abbreviations (same for longer key names) #205
Comments
This would be drastically easier to read and write, particularly the modifier keys. I personally have text expansion shortcuts setup for all of the common key symbols so it's effortless to write this way. |
On the writing side: another way is you can bind right alt as your "symbol key" in goku, so just pressing it with any modifier or backspace or enter etc would insert the symbol, so it's even faster to type (for the longer names) and more convenient to press the mod key rather than try to remember the letter representing it On the reading side, though, you'd need to allow tabs/spaces to reach greatness: so that in a long list of keys you could place the modifiers in a column, so e.g., all command keys are in the first column, all shift keys are in the second, then it's immediately obvious from modifier position which mods are required for a key But whitespaces might be too complicated to add (and even then might be alignment might be slightly off due to imperfect editor support of symbol width/variable tab width As an illustration of a more complicated example with optionals (here whitespace is a variable width tab needed for vertical alignment in a text editor) |
@eugenesvk Those symbols look great. But personally, I find the arrows to introduce too much visual clutter. Why not something visually ligther, like using apostrophes(or an even more subtle symbol) to the left/right of the principal symbol? I mean, something like this: |
Or maybe ‹ › with the benefit that you could have them on the same side if you'd like it a bit denser while maintaining vertical alignment of the modifiers?
|
Similarly, maybe !⌘ |
If using different symbols for left and right (like you do with I do agree that vertical alignment is a thing, but I was thinking of being able to use spaces when needed to maintain it, as you did in your examples. I agree too to the question mark being used for optional. Much more common for anyone with a regex background! ;-) |
Certainly, I agree that it's conceptually better to put the side indicators to their respective sides and also personally prefer it that way, the cost of extra spaces is not significant enough to me I was wondering whether that could actually be something dynamic, e.g., you would put at the top of a file one line with the symbol definitions to your liking (subject to parser constraints on the allowed symbols) |
Good news, everyone :)! I've added support for symbols in the from/to fields, see https://github.com/eugenesvk/GokuRakuJoudo/releases/tag/0.7.0 for more details, that page also has a prebuilt binary if you want to check it out and see whether it works Also added whitespace support for proper vertical alignment in strings starting with Don't think the dynamic part is a great idea since it might have harder to catch bugs due to duplicate partial matches that will be replaced into invalid combinations, so will leave it for now If you're able to build locally, you can add more symbols for the left/right/optionals etc. (in addition to Have converted a bunch of my config to the new format and preliminary seems to work fine, but obviously more testing is needed (don't forget to backup your pre-symbol files just in case) |
This commit lets the user choose between a left, right, or side-ambivalent modifier using the following unicode syntax: ⌘ - command ‹⌘ - left_command ⌘› - right_command etc. for other mods, ⌘, ⌥, ⌃, ⇧. Also added is an alias that's valid for hyper, ☆. e.g. ☆ | 8 would map to 'command+option+control+shift + 8' This syntax was discussed in this issue in the GokuRakuJoudo repo: yqrashawn/GokuRakuJoudo#205 so credit to the participants of that issue.
This commit lets the user choose between a left, right, or side-ambivalent modifier using the following unicode syntax: ⌘ - command ‹⌘ - left_command ⌘› - right_command etc. for other mods, ⌘, ⌥, ⌃, ⇧. Also added is an alias that's valid for hyper, ☆. e.g. ☆ | 8 would map to 'command+option+control+shift + 8' This syntax was discussed in this issue in the GokuRakuJoudo repo: yqrashawn/GokuRakuJoudo#205 so credit to the participants of that issue. Addresses #2
This commit lets the user choose between a left, right, or side-ambivalent modifier using the following unicode syntax: ⌘ - command ‹⌘ - left_command ⌘› - right_command etc. for other mods, ⌘, ⌥, ⌃, ⇧. Also added is an alias that's valid for hyper, ☆. e.g. ☆ | 8 would map to 'command+option+control+shift + 8' This syntax was discussed in this issue in the GokuRakuJoudo repo: yqrashawn/GokuRakuJoudo#205 so credit to the participants of that issue. Addresses #2
Hi all, what a great discussion. Really like your ideas of using
I wonder do you have needs in your config to have both side at the same time, or is it always (or most of the time) only on one side? Will the first character for the side applying to all modifiers enough? Like:
|
(you could check it yourself with this custom version of goku https://github.com/eugenesvk/GokuRakuJoudo/releases/tag/0.7.0 that implements this design, would be nice to know what the limitations are as it works great for my config, but obviously missed something)
Yes, I have rules like this (note that I prefer the smaller and thus much more visually pleasing/distinct {:des " ✱A+,/. to Select until Word Start/End: ⇪A,/. ⟶ ⎇⇧←/→" :rules [
[:‹⇧⇧›⎈›⎇›◆›comma :‹⇧‹⎇◀ ]
[:‹⇧⇧›⎈›⎇›◆›. :‹⇧‹⎇▶] ]} or this partially translated rule {:des " ◆›jkl; ⟶ ▼▲◀▶" :rules [
[:◆›‹⎈##l :‹⎈◀ ] [:‹⎇◆›##l :‹⎇left_arrow ] [:‹◆◆›##l :‹◆left_arrow ]
[:◆›‹⎈##semicolon :‹⎈▶] [:‹⎇◆›##semicolon :‹⎇right_arrow] [:‹◆◆›##semicolon :‹◆right_arrow]
[:◆›##j :▼ ]
[:◆›##k :▲ ]
[:◆›##l :◀ ]
[:◆›##semicolon :▶]]}
Mostly only one one side besides those hyper mapped combos or the types of rules mentioned above
No since then it's ambiguous, either side modifiers don't need a side indicator, so every side modifier requires side indicator (btw, goku also has a feature request to have "Structured config files instead of one big file", one file is indeed awful to work in, so would be nice to have "modules", though there is a trick to achieve the same currently with karabiner or goku using chezmoi #153 (comment)) |
Hi @eugenesvk, thanks for your reply and work on adding this to Goku; I would definitely use your implementation if I were still using Goku. Sorry, I was not clear on a few things. Firstly I had a script to write Goku config in modules myself. The reason for working on another format was mainly that I am not familiar with the edn format and had to constantly look for things which were not very productive. Secondly, my tool already has the alias feature and solves my own problems. The part I was thinking of adding was the more concise way of adding sides to modifiers (which is not required by my own config because I rarely use sides on modifiers unless I am mapping the modifier key itself). Thanks for pointing out Thanks for sharing your config for the need to map both sides' modifiers simultaneously. May I ask whether you have many of them or only a few and, most of the time, on the same side? |
With a goku mapped key combo, of course :), in a bracket mode @ space mode: (hold)␠d‹⌘/⌘›. Though I also have them maped directly in the keyboard layout to ⇧⎇9/0
a few |
Thanks @eugenesvk, I will add
As mixed sides are not common, it may be fine to be a bit more verbose, like |
Currently modifier keys are represented by this alphabet soup
Especially in various combos it's getting a bit hard to read as the is no separator between a modifier and a key and the abbreviations (especially the right ones) are less than memorable (but even for the left ones tripped a few times over C as control or command)
I'd like to suggest that in addition to the single-upper-case letters you could use these unicode symbols representing these keys:
...or using more traditional macOS symbols is also just fine
... or maybe allow both?
This would also allow you to get rid of the extra
!
after:
Similarly, some of the long-named keys could be replaced with much better looking
A larger illustration
This could also help with mouse buttons, for example, this monstrosity
could become this beauty
The text was updated successfully, but these errors were encountered: