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)
(don't like the ← indicators, but maybe if left is much more common you could have left modifiers without an indicator, but then have another indicator for ↔left or right?)

@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:
'⌘ for left command
⌘' for right command
etc

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 # is too heavy and can be replaced with a more logical question mark for optionals?

!⌘
?⌘
﹖⌘
⌘?
⌘﹖

If using different symbols for left and right (like you do with > and <), then yes, it can be allowed to place them in either side of the main symbol. If using the same symbol (like the apostrophe or similar), then that option is not possible. Personally, I find it easier to leave the position of the apostrophe to mean "left" or "right". There's no decoding, it's visual. While, if you can put < or > to the left, you brain has to "decode" if it's a less than or a greater than symbol. I find that slower to my eyes. But that's personal preference. I think any of the proposed options would be great.

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! ;-)

if you can put < or > to the left, you brain has to "decode" if it's a less than or a greater than symbol. I find that slower to my eyes. B

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
(though I also like the extra boost from arrow-like ‹›)

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)
shift⇧ control⎈ option⎇ command◆ left‹ right› optional﹖

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 ‘ "‘ ⇧ ⎈ d"

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 ‹ ') in the tables at the top of this keys_symbols file and the resulting combinations should be auto-generated

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)

Hi all, what a great discussion. Really like your ideas of using <, > for left_ right_. I am working on a different config format and thinking about this feature, however I'd like to have strong typing so it will be too hard or complicated for supporting it on all modifiers, like

• <⌘⌥>⌃ for left_command, right_option, control.

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:

• <⌘⌥ for left_command, left_option
• >⌘⌥ for right_command, right_option

(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)

I wonder do you have needs in your config to have both side at the same time

Yes, I have rules like this (note that I prefer the smaller and thus much more visually pleasing/distinct ‹› instead of <>)

 {: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  	:▶]]}

, or is it always (or most of the time) only on one side?

Mostly only one one side besides those hyper mapped combos or the types of rules mentioned above

Will the first character for the side applying to all modifiers enough? Like:

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 ‹›. I was wondering about that (they look so much better). Sorry for the naive question, but how do you type them 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?

how do you type them out

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

many of them or only a few

a few

Thanks @eugenesvk, I will add ‹› to my key alias and use them for the sides. I think I will go with first character for the whole group

• ‹⌘⌥ or l⌘⌥
• ›⌥⇧ or r⌥⇧

As mixed sides are not common, it may be fine to be a bit more verbose, like ['‹⌘', '›⌥'].