[Question] Custom key bindings beyond those in Setup

[lkblkb]

Just started using typing-booster - it's amazing!

I also use an ibus based Chinese input pretty often, and have done for years.

The ibus Chinese input (and many other Chinese IMEs I've used) will commit the preedit when you type Return/Enter.

This creates a conflicting pattern with booster, because in booster Return commits & sends a Return keypress.

Is it possible to customize the Return key binding so that it just commits the preedit, without the additional Return keypress?

[mike-fabian]

Thinking …

Wouldn’t that be annoying to have press Return twice at the end of a line, the first to commit and the second to get to the next line?

The Chinese input methods I know do not commit the preedit on Return/Enter but the keys typed.

For example when using ibus-libpin and typing nihao, the preedit contains 你好.

Now typing space will commit 你好 and typing Return/Enter will commit the Latin letters nihao.

It is the same behaviour with ibus-table.

Japanese input methods like ibus-anthy, ibus-kkc, ibus-mozc usually commit the preedit on Return/Enter and use space to convert the phonetic input to Kanji.

[mike-fabian]

As you correctly noticed, the current settings for keybindings do not allow what you want.

But maybe I can make a small addition to make this possible:

Currently there are commands to commit certain candidates with or without adding a space, like:

commit_candidate_1            []
commit_candidate_1_plus_space ['1', 'KP_1', 'F1']

But there is no command to just commit and nothing else.

Maybe I could add a new command commit which would be empty by default:

commit       []

And when this is empty, the behaviour of Typing Booster to Return/Enter would be the same as now.

But one could set it to any keys one likes, for example:

commit       ['Return', 'Enter']

And this command would just commit and do nothing else.

As these hotkeys are handled before other key processing is done, if Return/Enter are bound to a command, they just execute that command and that's it.

So one would not be able to use Return/Enter for anything else but this commit command then.

But if there is no input, i.e. if the preedit is completely empty, Return/Enter would still work as usual.

When the preedit is empty, there is only one key binding command which is checked and that is toggle_input_mode_on_off.

[lkblkb]

Hi, thanks for your replies!

For example when using ibus-libpin and typing nihao, the preedit contains 你好.

This is 100% correct, sorry I was not entirely clear in the first message.

I guess the commit command can't simply be added in a file somewhere? If you are willing to add the option, it would be great! This is just an idea, it's your (amazing!) project, so please add or don't add as you see fit 😊

A related question I have is, is it possible to prevent spaces from being added when committing? E.g. I have various punctuation added as commit triggers, but they add a space which, god help me, after 30 years of mastering period-space, comma-space, etc., I simply can't stop myself from doing it and end up with extra spaces everywhere 😅

So an option to prevent spaces from being added on commit would also be amazing. 🙏

[mike-fabian]

For example when using ibus-libpin and typing nihao, the preedit contains 你好.

This is 100% correct, sorry I was not entirely clear in the first message.

I am thinking of adding the commit command which would commit the preedit or a selection in the candidate list if something is selected there.

It would not commit exactly the keys typed, i.e. it would not do what ibus-libpinyin and ibus-table do on Enter/Return.

For example:

When using the t-latn-post input method in ibus-typing-booster and one types gru"n, the preedit shows grün.

Executing the commit command would then commit grün, not the raw typed string gru"n. Or, if something was selected in the candidate list by typing Tab or arrow_down, it would commit the selection. I.e. it would commit exactly what Return would usually commit, only avoid adding the Return after the commit.

Would that be OK for you?

I could add yet another command commit_typed_keys which would commit exactly the keys which were typed, i.e. in the above example it would commit gru"n, not grün. This is basically what ibus-libpinyin and ibus-table to on Return.

If both commands were available, one can choose between the two behaviours. This commit_typed_keys seems a bit useless to me though, I am not sure whether to add that.

commit seems a bit more useful.

I guess the commit command can't simply be added in a file somewhere? If you are willing to add the option, it would be great! This is just an idea, it's your (amazing!) project, so please add or don't add as you see fit blush

No, it is a bit more effort than that.

[mike-fabian]

A related question I have is, is it possible to prevent spaces from being added when committing? E.g. I have various punctuation added as commit triggers, but they add a space which, god help me, after 30 years of mastering period-space, comma-space, etc., I simply can't stop myself from doing it and end up with extra spaces everywhere sweat_smile

So an option to prevent spaces from being added on commit would also be amazing. pray

I think you are talking about the “Auto commit characters”. The tooltip for that option says:

        self._auto_commit_characters_label.set_tooltip_text(
            _('The characters in this list cause the preedit '
              'to be committed automatically, followed by '
              'a space.  For example, if “.” is an auto '
              'commit character, this saves you typing a '
              'space manually after the end of a sentence. '
              'You can freely edit this list, a reasonable '
              'value might be “.,;:?!)”. You should not add '
              'characters to that list which are needed by '
              'your input method, for example if you use '
              'Latin-Pre (t-latn-pre) it would be a bad idea '
              'to add “.” to that list because it would prevent '
              'you from typing “.s” to get “ṡ”. You can also '
              'disable this feature completely by making the '
              'list empty (which is the default).'))

As explained in the tooltip, if these add a space a you may save typing one key per autocommit.

For example if you want to type "First sentence. Second sentence. Third sentence. ", you save 3 keys because you do not need to type the space after each sentence.

But if the autocommit character . would just cause a commit without adding a space, then you have saved no keys at all, you are typing both the . and the space then.

If you are used to typing period-space anyway, then just remove the . from the autocommit characters. The space you type will commit anyway, it doesn’t matter then if the period before did already commit, the result is the same and the number of keys typed is the same.

Personally I keep the autocommit character list at the default value, i.e. empty because

• like you I am very used to typing period-space
• As the tooltip explains, the period is used in some input methods, like Latin-Pre. Almost all of the reasonable autocommit characters “.,;:?!)” are used in some input method. As I switch between many input methods often for testing purposes, I got really tired of constantly removing and adding characters to the autocommit list. You can only use characters there no input method you are interested in uses as input.

[lkblkb]

I removed the autocommit entries and that is perfect. I got too carried away with the settings, it seems. Thanks!

commit is also the one I'd be using. Committing the post-processing preedit works for me. However I can imagine some multi-lingual applications wanting the commit_typed_keys however perhaps cross that bridge when you get to it ;-)

Your support has been much appreciated!

[mike-fabian]

I’ll work on this next week. I think there are some corner cases where it might be useful to bind a commit command to a key.

Binding Return/Enter to commit will cause the need for extra keystrokes in most cases though, so I am not sure whether this is a good idea.

For example, if you type text in a Language which has spaces between the words (like English, ...) and commit each word with Return then you need an additional keystroke to type the space. And at the end of a line you need to press Return twice once to commit and once to get the new line, i.e. one extra key press also at the end of a line.

Even if Return is bound to commit and you don’t really use it but usually type spaces to commit words. then you still have one extra keystroke at each end of a line because you need to press Return twice.

But not everybody uses Typing Booster to type text, I have heard from some users who use it only to type Emoji and symbols.

If one types several emoji in a row, one might not want spaces between the emoji so one might want a way to commit without adding a space or return.

Actually something like that sort of exists already: When I type something like:

“Happy birthday❣️🎂”

where I don’t want spaces after “birthday”, “❣️”, and “🎂”, I commit these three items using arrow-right.

When the cursor is at the right end of a preedit, an arrow-right also triggers a commit and sends an arrow-right event to the application. But, when one is at the end of the file/buffer already, the arrow-right send to the application cannot do anything. I.e. at the end of a file/buffer one can commit using arrow-right without adding trailing white space and without moving the cursor. If one commits with arrow-right while not at the end of the file/buffer, the cursor moves right one position after the commit though.

Adding a commit command which commits without doing anything else (no trailing white space added, no cursor movements) might be useful in some situations. Maybe such cases are quite rare, but adding this does not harm (at least not by default because no key will be bound by default to commit). And maybe there are some reasons why one might assign different keys than Return/Enter to commit. it seems like a possibly useful command to add.

[mike-fabian]

I made test builds of ibus-typing-booster-2.16.6 with the new feature:

For Fedora 35, 36, and rawhide: https://copr.fedorainfracloud.org/coprs/mfabian/ibus-typing-booster/builds/ For openSUSE: https://build.opensuse.org/package/show/home:mike-fabian/ibus-typing-booster

Or you can build from source using the release-candidate-2.16.6 branch:

https://github.com/mike-fabian/ibus-typing-booster/tree/release-candidate-2.16.6

[mike-fabian]

Setup tool with the new feature:

[lkblkb]

Amazing, thanks! :pray: Hugely appreciated!

This is definitely a niche feature, since as you say it adds keystrokes. Personally my use-case is for entering text e.g. in Krunner where I want neither Return nor space, or emojis, usernames and channel names in Discord where I need the preedit to appear in the text field. So it's somewhat specialized although not unlikely for booster users to encounter.

[mike-fabian]

Included in ibus-typing-booster 2.16.7: https://github.com/mike-fabian/ibus-typing-booster/releases/tag/2.16.7