That's great ideas and implementations, although there are some design questions I have (I worked on ExtraKeys 2 years ago and I wanted to add part of what you did before).

So you change the format allowed in the extra-keys matrix by adding more meaning to the keys.
My main idea to allow this kind of transformation was to allow each element of the matrix to be a string or an object :

extra-keys = ["a", "b", {key: "c", display: "C", popup: "€"}, "d", "e"]

Here we specify that the "c" key must be displayed "C" on the keyboard and has the key "€" as a popup.

In that case this :

extra-keys = ["a", "b", "c", "d", "e"]

would be a shortcut for this :

extra-keys = ["a", "b", {key: "c"}, "d", "e"]

For your weechat example, I would write it like this :

extra-keys = ["a", "b", {key: "esc A", display: "weechat next"}, "d", "e"]

Here the key would be displayed as "weechat next" but send the "esc A" code to the keyboard.

1) Configurable popups

extra-keys used to be a matrix of String, and now each element of the matrix can be either a string like before or an array, and the second element of the array is the popup.

A more versatile way to do it would be to allow for an json object, we can add more information in future versions of the app :

your implementation :

extra-keys = ["a", "b", ["c", "€"], "d", "e"]

my implementation :

extra-keys = ["a", "b", {key: "c", popup: "€"}, "d", "e"]

Another way would be to add a separate map (like you did for your macros) like this :

extra-keys-popups = {"c": "€"}
extra-keys = ["a", "b", "c", "d", "e"]

but I wouldn't choose that because it wouldn't allow two keys to have the same text displayed but having two different actions, although that's not very restrictive.

2) Style and display

I've seen you added a new parameter that allows users to choose which CharDisplayMap is chosen to render the keys. That's good, we can add more default display maps in the future, it changes the default display of keys.

Using my idea, we add an attribute called display :

extra-keys = ["a", "b", {key: "c", display: "C"}, "d", "e"]

Here, the key is "c" but it's displayed "C".

extra-keys = ["a", "b", {key: "RIGHT", display: "->"}, "d", "e"]

Here, the key is "RIGHT" but it's displayed "->".

As stated before, using an external map is also possible :

extra-keys-display = {"c": "C"}
extra-keys = ["a", "b", "c", "d", "e"]

3) Macros

You now consider strings in extra-keys to be a space separated list.
That would break previous configurations that have spaces like " " to represent a simple space or words like "hello world" on one keystroke. With your commit that must be spelled "SPACE" and "hello SPACE world" (I guess ?).

I'm okay with that, I'm pretty sure no one wanted to have spaces in their key.

Another way to do it without breaking previous configurations would be to use another keyword instead of "key" to emphasize it's a macro, like this :

extra-keys = ["a", "b", {macro: "esc A", display: "weechat next"}, "d", "e"]

Here the key would be displayed as "weechat next" and execute the macro "esc A".

We could also add a different keyword to specify it's not a macro but simple text :

extra-keys = ["a", "b", {text: "esc A", display: "ea"}, "d", "e"]

Here it writes "esc A" but displays the key as "ea".

extra-keys = ["a", "b", {text: "LEFT", display: "lt"}, "d", "e"]

Here it writes "LEFT" but displays the key as "lt", the fact that we use the "text" attribute mean it's simple text, no control characters, however I don't think people would really use this.

So, I'm okay with the fact that "esc A" is a macro.

4) Keyboard button

Very good idea :)

Conclusion

• You changed the meaning of the string in the extra-keys view by allowing to use macros, that breaks a little bit of backward compatibility (specifying SPACE) but I'm okay with that.
• For the popup, you allowed the string to be an array, I would suggest using a json object having the key "popup" because it's more versatile (can add different actions in future versions), or using an external map (extra-keys-popup).
• For changing the display of a key, i would add a display attribute to the json object, or using a map (extra-keys-display), that would replace your extra-keys-map by using a slighty different approach.

You now consider strings in extra-keys to be a space separated list.
That would break previous configurations that have spaces like " " to represent a simple space or words like "hello world" on one keystroke. With your commit that must be spelled "SPACE" and "hello SPACE world" (I guess ?).

No, the strings in extra-keys are treated just like before. Only the strings in extra-keys-map are split on space. I see that this can be confusing though, so I think your idea of using an object with either key or macro is good. We would have to decide what to do if both are specified though.

I like your other suggestions too. I don't remember why I made a separate config for macros, maybe to not change extra-keys too much. But I agree that allowing an object in extra-keys with key or macro, and optionally display and popup, would be a good solution. popup should be allowed to be specified either as a string or as an object with key/macro and optionally display (but not popup).

If display is specified, should we display that verbatim, or should it get mapped through CharDisplayMap?

is this already implemented?

@trygveaa Yes, popup could be a string or an object containing the same information, it's a kind of a recursive data structure :) (but a popup cannot contain a another popup !), and we could also imagine multiple popups like on a real keyboard

About macro, it's more safe to write it as { macro: "..." } even if a "macro string" doesn't look at all like a "single key" string or a "multi character" string like "if (".

About "what if both macro and key are defined" I'd say raise an error, those arguments are mutually exclusive, currently the configuration can already raise an error (if the json is malformed).

About display, It's verbatim, not going through CharDisplayMap, it makes no sense to say "the key LEFT must be displayed as RIGHT", the main idea for display is to provide your own Charmap anyway { key: "LEFT", display: "<-" }

Shall I implement those ideas or will you ? :)

@signotorez this is a pull request so the features described in the first post are implemented but the ideas of modifications I added aren't (yet).

Also, BKSP and DEL do not autorepeat when long pressed like the arrow keys do. It clearly should be. Speaking of PGUP and PGDN it could be autorepeated too although I think it's less useful.

love to see it at the next release, hope ;)

@trygveaa Yes, popup could be a string or an object containing the same information, it's a kind of a recursive data structure :) (but a popup cannot contain a another popup !), and we could also imagine multiple popups like on a real keyboard

Yeah, I thought about multiple popups too, but figured it could wait.

About macro, it's more safe to write it as { macro: "..." } even if a "macro string" doesn't look at all like a "single key" string or a "multi character" string like "if (".

Sure.

About "what if both macro and key are defined" I'd say raise an error, those arguments are mutually exclusive, currently the configuration can already raise an error (if the json is malformed).

👍

About display, It's verbatim, not going through CharDisplayMap, it makes no sense to say "the key LEFT must be displayed as RIGHT", the main idea for display is to provide your own Charmap anyway { key: "LEFT", display: "<-" }

Alright, agree.

Shall I implement those ideas or will you ? :)

I can do it.

Also, BKSP and DEL do not autorepeat when long pressed like the arrow keys do. It clearly should be. Speaking of PGUP and PGDN it could be autorepeated too although I think it's less useful.

I guess all keys except for the modifier keys could repeat?

I guess all keys except for the modifier keys could repeat?

Well, the standard keys on Android keyboard do not repeat, long press brings a popup. It's not very useful anyway to write "aaaaaaaaaaaaa" or "------" but hey, adding a { repeat: true } is still possible. But that's not a priority.

Well, the standard keys on Android keyboard do not repeat, long press brings a popup. It's not very useful anyway to write "aaaaaaaaaaaaa" or "------" but hey, adding a { repeat: true } is still possible. But that's not a priority.

I agree, I just thought that if I added repeat to all non-modifier keys, we wouldn't have to decide which are repeated and which are not repeated. Popups for these keys are triggered by swipe up, not by long press anyways, so repeat and popup works fine on the same key.

I'd suggest we're updating this PR to [WIP] and opening a PR on your repo so that I can put some code too ? Or do I just send a message here saying "please pull from my branch" (doing pull requests the old way ^^).

I've created a PR here :)

The changes @robertvandeneynde and I discussed are now implemented. Here is a new description of what this PR implements:

• The popup keys are now configurable.
• The popup keys interact better with long-press keys.
• You can configure a default style to display the keys as, e.g. if PGUP should be shown as text or an arrow character. This is done with a new option extra-keys-style.
• Each key can also explicitly be configured to display however you want.
• The modifier keys can be used together with other keys in the extra keys row. E.g. pressing CTRL then left.
• Support for sending multiple characters from one key, including sequences of modifier presses and normal keys. E.g. CTRL d to exit the terminal.
• Support for a KEYBOARD key, which toggles display of the keyboard.
• Fallback to the default extra keys when parsing extra-keys fails, instead of not showing any extra keys.
• The backspace and delete keys now repeat, like the arrow keys.

To configure these things, each key in extra-keys can now be either a string or an object.

• If it's a string, it behaves exactly as before, except that - and / won't automatically have popups, as popups are explicitly configured now.
• If it's an object it should have either a key or a macro property, optionally a display property and optionally a popup property.
  • The key property means the same as when specifying just a string.
  • The macro property allows you to send multiple keys, e.g. CTRL d. The keys should be separated by space. If you want to send space, you can use SPACE.
  • The display property allows you to configure what should be displayed on the key if you want something different than the key.
  • The popup property allows you to specify a popup key. This should have the same value as a normal key, except that if you specify it as an object, specifying popup has no effect.

The extra-keys-map option has been removed, since it's no longer necessary. Specifying the popup as an array with the key and the popup is also no longer supported, as it should be specified as an object instead. Both of these were things I initially added in this PR, not things removed from master.

As an example, this is the config I use:

extra-keys = [[ \
  {key: ESC, popup: {macro: "CTRL f d", display: "tmux exit"}}, \
  {key: CTRL, popup: {macro: "CTRL f BKSP", display: "tmux ←"}}, \
  {key: ALT, popup: {macro: "CTRL f TAB", display: "tmux →"}}, \
  {key: TAB, popup: {macro: "ALT a", display: A-a}}, \
  {key: LEFT, popup: HOME}, \
  {key: DOWN, popup: PGDN}, \
  {key: UP, popup: PGUP}, \
  {key: RIGHT, popup: END}, \
  {macro: "ALT j", display: A-j, popup: {macro: "ALT g", display: A-g}}, \
  {key: KEYBOARD, popup: {macro: "CTRL d", display: exit}} \
]]
extra-keys-style = arrows-all

@fornwall @Grimler91

The setting: { key: 'ESC', display: 'Esc' } still displays ESC in upper-case.