Options to improve coding experience

[i5ar]

I've used the Typing Booster to write code and I'd like to suggest two main enhancements:

1. An option to disable the space that is automatically inserted after the word/symbol;
2. An option to change the Esc behavior (I think the Esc key should escape the suggestions without removing the characters already inserted).

Thank you.

🙏🏻

[mike-fabian]

Can you explain why you think having Esc not remove the preedit is helpful?

[i5ar]

I'd like to be able to write smile = "😄" but when I start typing smile = "smil the smile emoticon is not present in the suggestions because the double quote is considered part of the word. The intruder can also be a single quote, a backtick, a dash, an underscore, etc.
I think is more natural to write " and then hit Esc just to reset the suggestions (without removing the double quote). After all, I can always press the Backspace to remove the last character or Shift+Backspace to remove the last word.

I'm not suggesting to change the Esc default behaviour but just to add one more option.

I'm also suggesting to get rid of the trailing space for reasons you may be already aware of:
As I've already said I'd like to be able to write smile = "😄", not smile = "😄 " (note the space before the last character).
Thank you.

[mike-fabian]

Do you know that in many cases you can commit the current preëdit without adding a space by typing Control+Space instead of just Space? Isn’t Control+Space just as good for this purpose as ESC?
Almost all other ibus input methods seem to use ESC to discard the current preëdit, it would be a bit weird if ibus-typing-booster did that differently.

For a list of keys which may trigger a commit, see:

https://github.com/mike-fabian/ibus-typing-booster/blob/master/engine/hunspell_table.py#L2620

        # These keys may trigger a commit:
        if (key.msymbol not in ('G- ',)
            and (key.val in (IBus.KEY_space, IBus.KEY_Tab,
                             IBus.KEY_Return, IBus.KEY_KP_Enter,
                             IBus.KEY_Right, IBus.KEY_KP_Right,
                             IBus.KEY_Delete,
                             IBus.KEY_Left, IBus.KEY_KP_Left,
                             IBus.KEY_BackSpace,
                             IBus.KEY_Down, IBus.KEY_KP_Down,
                             IBus.KEY_Up, IBus.KEY_KP_Up,
                             IBus.KEY_Page_Down,
                             IBus.KEY_KP_Page_Down,
                             IBus.KEY_KP_Next,
                             IBus.KEY_Page_Up,
                             IBus.KEY_KP_Page_Up,
                            IBus.KEY_KP_Prior)
                 or (len(key.msymbol) == 3
                     and key.msymbol[:2] in ('A-', 'C-', 'G-')
                     and not self._has_transliteration([key.msymbol])))):

Not all of these trigger a commit always, for example the arrow right key would trigger a commit only if the cursor is at the right side of the preëdit, if the cursor has been moved left in the preëdit, an arrow right key would not commit until the ride side of the preëdit is reached.

A space always triggers a commit.

If a commit is triggered by any of the above keys, the key itself is forwarded to the application.
I.e. if you commit by typing space, a space is added after the commit, if you commit by arrow-right, an arrow right is added after the commit (Which may do nothing if you are at the end of the file).
Control+space also triggers a commit and sends a Control+space to the applicatioņ. In most cases
this does nothing in the application so you can use Control+space to commit without adding a space
(In Emacs, Control+space sets a mark, but in most applications it seems to do nothing).

[i5ar]

Thank you for the detailed answer.
I didn't know about Control+Space: That solves the main problem.
Is there a way to use digits as select keys without the trailing space?

[mike-fabian]

At the moment there is now way to use digits (or the F1-F9 keys)
to select without getting the trailing space. Neither is it
possible to avoid the trailing space when selecting with the
mouse.

I am thinking about what would be the best way to make this possible.

1. Add an option "Committing a candidate by selecting it in the
   lookup table by using 1-9, F1-F9, or by using the mouse should not add a
   space"

(Of course with a more concise name for that option).

2. Use a special key binding to commit such a candidate without
   adding a space.

For example, just like Control+Space commits the currently
selected candidate from the lookup table (or the preëdit if no
candidate is selected in the lookup table) SomeModifier+Number
could commit the candidate with that number without adding a
space. Unfortunately Control+Number is already used, see:

http://mike-fabian.github.io/ibus-typing-booster/documentation.html#key-bindings

I.e. Control+Number removes that suggestion from the database
where ibus-typing-booster remembers the previous input. This is
useful if you have typed something wrong, maybe a word with a
spelling error, and want to delete it from the suggestions. Other
modifiers than Control would still be available so I could use
Alt+Number or Shift+Number for that. But would that really be an
improvement? After all, one has to press 2 keys for
Shift+Number. So no keystroke is saved compared to
Number+Backspace which one can already do now.

In case of committing with the mouse, the middle mouse
button (Button 2) is still unused. The left button (Button 1)
commits and Control+Button 1 removes the clicked candidate from
the database. So Button 2 could still be used to commit without a
space. But maybe I should reserve that button for something else
which might be more useful?

Option 1), i.e. an option to disable that extra space really does
save a keystroke. But in most cases, certainly when writing
normal text and not program code, one usually wants that extra
space. So one probably would need to switch that option between
on and off from time to time which might be annoying as well.

But even when an option is on, one can still commit a candidate
followed by a space by navigating to that candidate first by
typing Tab multiple times (or arrow-down, but I prefer Tab) and
then typing a Space to commit with space. Actually I do that much
more often then committing using the number keys, mostly because
I have the option “Use digits as select keys” switched off
because I want to be able to complete strings containing
digits. So I can only use F1-F9 to commit and as these keys are a
bit hard to reach for my fingers, it is easier to press Tab a few
times and then Space.

---

So which idea is better in your opinion? 1) or 2)? Or are there any
other possibilities I have not thought of?

If we choose 1), what would be an easy to understand but short name
for that option?

[i5ar]

Option 1)

The description can be something like "Trim (or strip) whitespace from candidate committed by a label".

Option 3)

Even if I understand now why there is a trailing space I'm not sure about this behaviour:

But even when an option is on, one can still commit a candidate
followed by a space by navigating to that candidate first by
typing Tab multiple times (or arrow-down, but I prefer Tab) and
then typing a Space to commit with space.

A more consistent option can be just "Trim whitespace from candidate" (always).

Option 4)

What if one wants to use the Tab key to navigate the suggestions and still not having the additional whitespace? In that case, he can use the Enter key or the Return key.
So, reverse thinking, this option would be something like "Add whitespace when the spacebar is used to commit".

This option is similar to option 1) but here the Space key is the only exception because it commits and adds a whitespace at the same time.
This option changes the current behaviour because one needs to add manually the whitespace in all remaining cases.
So maybe it's too late now, I don't know.

[mike-fabian]

A more consistent option can be just "Trim whitespace from candidate" (always).

I think when using the space bar to commit, the space should never be trimmed, that would be very inconsistent. All keys which can be used to commit add the same key after the committed text, it would be very weird to make an exception for space here. And one can use Control+Space already if one wants to avoid that extra space.

As you write, one can also commit using Enter or Return, but that adds an Enter or Return so it will go to the next line which is probably not what you want.

I think it should be enough to have an option which avoids adding the space when committing using the labels (1-9, F1-F9) or the mouse.

[i5ar]

All keys which can be used to commit add the same key after the committed text, it would be very weird to make an exception for space here.

You're right, probably I was confused by the F1-F9 (1-9) keys which I use more often: They don't seem to send any additional signal.
If I have any other ideas/options I let you know.
Thank you.

[mike-fabian]

Yes, I’ll probably add that option not to add an extra space when committing with F1-F9 (1-9) or by clicking with the mouse.

[mike-fabian]

The new option is in https://github.com/mike-fabian/ibus-typing-booster/releases/tag/2.1.2

[mike-fabian]

Does the new option help you?

[i5ar]

Yes, I think it's a great addition, thank you very much.

Sorry for the late reply, I wasn't able to answer before.

[mike-fabian]

No problem, thank you for the feedback!

[mike-fabian]

I am thinking about removing that option again and replacing it by something described in

#48

I.e.:

And for the commits using keys I think it would be good to have commands like:

commit_candidate_1 [] <- default keybinding empty
commit_candidate_1_with_space [1, F1] <- default keybinding not empty
... same for 2-9 ...

Somebody who wants to use 1-9 to commit without space would need to remove the 1-9 keybindings from “commit_candidate_1_with_space” and add them to “commit_candidate_1”. That is a bit more work than just clicking the current checkbox, but I don’t think it makes sense to change this setting often.

Do you change this setting very often? Am I right to assume that changing this setting very often makes no sense? I.e. a user would typically decide whether he wants the space added or not, set it up that way and then leave it like that?

The above idea gives much more flexibility to fine tune the behaviour, but switching between having the 1-9 keys add a space on commit or not add a space on commit takes a little bit more then just checking a checkbox, one needs to change the key bindings for several commands then. But if one does this only once and not often, this should be fine.

[i5ar]

It seems fair, I don't change this setting often.
These are my options:

[x] Enable suggestion by key
[ ] Use inline completion
[x] Use digits as select keys
[ ] Add a space when committing by label or mouse
[ ] Remember last used preedit input method
[x] Unicode symbols and emoji predictions
[ ] Off the record mode
[ ] Use a workaround for a bug in Qt im module
[ ] Arrow keys can reopen a preedit

[mike-fabian]

Thank you. Then I can implement the above idea for an improvement and without making anything worse for you. That’s great!