[BUG] Ibus-typing-booster automatically removes accents

[psads-git]

Please, Mike, see the attached video, which shows the problem on gedit. Thanks!

Peek.2023-02-10.16-02.mp4

[mike-fabian]

What are your settings?

dconf dump /org/freedesktop/ibus/engine/typing-booster/

Especially I wonder whether you are using the autoselectcandidate option.

[psads-git]

Thanks, Mike. Yes, I am using the autoselectcandidate option:

$ dconf dump /org/freedesktop/ibus/engine/typing-booster/
[/]
arrowkeysreopenpreedit=true
autocapitalize=true
autocommitcharacters=''
autoselectcandidate=1
colorcomposepreviewstring='rgb(38,162,105)'
colordictionary=true
colorinlinecompletion=true
colorinlinecompletionstring='rgb(198,70,0)'
colorpreeditspellcheck=true
colorpreeditspellcheckstring='rgb(224,27,36)'
colorspellcheck=true
coloruserdb=true
debuglevel=0
dictionary='pt_PT,en_US'
emojipredictions=false
errorsound=true
inlinecompletion=2
inputmethod='NoIME'
inputmode=false
keybindings={'remove_candidate_6': <['Control+6', 'Control+KP_6', 'Control+F6']>, 'remove_candidate_1': <['Control+1', 'Control+KP_1', 'Control+F1']>, 'remove_candidate_2': <['Control+2', 'Control+KP_2', 'Control+F2']>, 'next_case_mode': <['Shift_L']>, 'next_input_method': <['Control+Down', 'Control+KP_Down']>, 'commit_candidate_5': <@as []>, 'lookup_table_page_up': <['Page_Up', 'KP_Page_Up', 'KP_Prior']>, 'previous_case_mode': <['Shift_R']>, 'setup': <['Mod5+F10']>, 'remove_candidate_8': <['Control+8', 'Control+KP_8', 'Control+F8']>, 'previous_input_method': <['Control+Up', 'Control+KP_Up']>, 'lookup_related': <['Mod5+F12']>, 'commit_candidate_6': <@as []>, 'remove_candidate_3': <['Control+3', 'Control+KP_3', 'Control+F3']>, 'select_next_candidate': <['Tab', 'ISO_Left_Tab', 'Down', 'KP_Down']>, 'remove_candidate_9': <['Control+9', 'Control+KP_9', 'Control+F9']>, 'commit_candidate_1': <@as []>, 'commit_candidate_7': <@as []>, 'next_dictionary': <['Mod1+Down', 'Mod1+KP_Down']>, 'remove_candidate_4': <['Control+4', 'Control+KP_4', 'Control+F4']>, 'toggle_input_mode_on_off': <['Control+Mod1+ISO_Level3_Shift']>, 'commit_candidate_2': <@as []>, 'speech_recognition': <@as []>, 'commit_candidate_8': <@as []>, 'lookup_table_page_down': <['Page_Down', 'KP_Page_Down', 'KP_Next']>, 'select_previous_candidate': <['Shift+Tab', 'Shift+ISO_Left_Tab', 'Up', 'KP_Up']>, 'remove_candidate_5': <['Control+5', 'Control+KP_5', 'Control+F5']>, 'toggle_emoji_prediction': <['Mod5+F6']>, 'toggle_hide_input': <['Shift+Control+Escape']>, 'commit_candidate_3': <@as []>, 'toggle_off_the_record': <['Mod5+F9']>, 'cancel': <['Escape']>, 'enable_lookup': <['Tab', 'ISO_Left_Tab']>, 'commit_candidate_9': <@as []>, 'previous_dictionary': <['Mod1+Up', 'Mod1+KP_Up']>, 'commit_candidate_1_plus_space': <['1', 'F1']>, 'commit_candidate_2_plus_space': <['2', 'F2']>, 'commit_candidate_3_plus_space': <['3', 'F3']>, 'commit_candidate_4': <@as []>, 'commit_candidate_5_plus_space': <['5', 'F5']>, 'commit_candidate_6_plus_space': <['6', 'F6']>, 'commit_candidate_7_plus_space': <['7', 'F7']>, 'commit_candidate_8_plus_space': <['8', 'F8']>, 'commit_candidate_9_plus_space': <['9', 'F9']>, 'commit_candidate_4_plus_space': <['4', 'F4']>, 'remove_candidate_7': <['Control+7', 'Control+KP_7', 'Control+F7']>}
labeldictionary=true
labelspellcheck=true
labeluserdb=true
mincharcomplete=1
offtherecord=false
pagesize=9
qtimmoduleworkaround=false
rememberinputmode=true
rememberlastusedpreeditime=true
tabenable=false
$

[mike-fabian]

Does the problem also happen, if you switch the autoselectcandidate option off?

[psads-git]

It appears that the problem only occurs with autoselectcandidate option on.

[mike-fabian]

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

    def _update_lookup_table_and_aux(self) -> None:
        '''Update the lookup table and the auxiliary text'''
        self._update_aux()
        # auto select best candidate if the option
        # self._auto_select_candidate is on:
        self._is_candidate_auto_selected = False
        if (self._lookup_table_is_invalid
            and self.get_lookup_table().get_number_of_candidates()
            and not self._lookup_table.cursor_visible):
            if self._auto_select_candidate == 2:
                # auto select: Yes, always
                self._lookup_table.set_cursor_visible(True)
                self._is_candidate_auto_selected = True
            elif self._auto_select_candidate == 1:
                # auto select: Yes, but only when extremely likely
                first_candidate = ''
                user_freq = 0
                typed_string = ''
                if self._candidates:
                    first_candidate = self._candidates[0][0]
                    user_freq = self._candidates[0][1]
                typed_string = unicodedata.normalize(
                    'NFC',
                    self._transliterated_strings[self.get_current_imes()[0]])
                spellcheck_single_dictionary = (
                    self.database.hunspell_obj.spellcheck_single_dictionary(
                        (self._p_phrase, self._pp_phrase, first_candidate)))
                if (spellcheck_single_dictionary
                    and typed_string
                    and typed_string != first_candidate
                    and itb_util.remove_accents(first_candidate)
                    == itb_util.remove_accents(typed_string)
                    and user_freq > 0.2):
                    self._lookup_table.set_cursor_visible(True)
                    self._is_candidate_auto_selected = True
        self._update_lookup_table()
        self._lookup_table_is_invalid = False

[mike-fabian]

It appears that the problem only occurs with autoselectcandidate option on.

That is why I was very sceptical about the usefulness of that option. Automatically selecting a candidate can do bad things, it should only happen when it is really very certain that selecting that candidate is an advantage.
And that is very hard to tell.

In my last comment is the current code. In the elif self._auto_select_candidate == 1: part, the candidate is only automatically selected if

• the last two words and the first candidate can be found in a single dictionary (single language)
• the typed string is different from the first candidate
• the typed string and the first candidate differ only by accents
• the calculated user_freq for the first candidate is > 0.2

In your example, às veces as apparently all 3 words can be found in the Portuguese dictionary, your typed string às is different from the first candidate as and the difference is only in accents, and the first candidate has a score > 0.2. Which means that you have typed as in this context before a few times (maybe by accident).

If that was only an accident, you could remove as from the database by typing as and then type Control+number where number is the index in the candidate list showing as.

I am thinking about restricting the automatic selection even more though, probably like this:

• the last two words and the first candidate can be found in a single dictionary (single language)
• the typed string is different from the first candidate
• the typed string and the first candidate differ only by accents
• the typed string has no accents at all
• the calculated user_freq for the first candidate is > 0.2

That will avoid the problem you reported here and make autoselection happen more infrequently than now because it can only *add accents then if the typed word has no accents at all.

Theoretically, I could make it a bit more complicated and allow some accents in the typed word and require only that the first candidate just adds more accents and does not remove or change any existing accents. I am not sure whether this more complicated check is worth doing. Maybe it is better to autoselect only when the typed word has no accents at all and the first candidate does nothing but add some accents.

[psads-git]

Thanks, Mike. I think that restricting auto-selection is a good idea.

[mike-fabian]

Test builds of 2.21.2 with the new behaviour for autoselecting (never remove accents) are here:

https://copr.fedorainfracloud.org/coprs/mfabian/ibus-typing-booster/builds/

These builds also contain two new features which might be useful for you, see:

#328 (comment)

and the following comments.

In short, there is an option

 ☑️ Disable in terminals

now which disables Typing Booster in terminals like gnome-terminal, xfce4-terminal, konsole, xterm, rxvt, and urxvt completely without a way to turn it on there (no key binding can turn it on)

And there is a more complicated advanced option which makes it possible to change any setting to a different value when a window matching a regular expression gets focus.

This more complicated option has no GUI yet, I am still working on that. But it is already usable by setting the option on the command line.

Using that option, it is possible to switch typing booster off when a terminal gets focus but keep the possibility to switch it on there again using a key binding.

[psads-git]

Thanks, Mike! The two new features you mention area great!

[mike-fabian]

New release:
https://github.com/mike-fabian/ibus-typing-booster/releases/tag/2.22.0
There is a GUI now for the “Autosettings” options. And because the new options are rather complicated, especially “Autosettings”, there are two new chapters in the online documentation:
Disabling in terminals: https://mike-fabian.github.io/ibus-typing-booster/docs/user/#2_2_6
Autosettings: https://mike-fabian.github.io/ibus-typing-booster/docs/user/#2_2_7

[psads-git]

Thanks a lot for the very great advance this new version brings to users, Mike! The "Autosettings" are really amazing!

I would suggest you to allow the users to edit the "Autosettings" already set up. For instance, to change inputmode to dictionary is not possible, at the moment, if the "Autosetting" is already set up.

[mike-fabian]

Thanks a lot for the very great advance this new version brings to users, Mike! The "Autosettings" are really amazing!

Just out of interest, what are you using the autosettings for?

I would suggest you to allow the users to edit the "Autosettings" already set up. For instance, to change inputmode to dictionary is not possible, at the moment, if the "Autosetting" is already set up.

Surely you have seen that you can change the value and the regular expression but not the name of the setting.

I thought about that and I might add the possibility to change the name of the setting later.

The reasons why I didn’t do that yet are:

When changing the name of the setting, almost always the value has to be changed as well. It absolutely has to change if the new setting needs a different type for the value, for example when it was an int before and then needs to be a bool or a str. If you change inputmode to dictionary then you had a bool (true or false) before and after the change you need a str (something like pt_PT,en_GB). Even if the type does not change, keeping the old value will be wrong in most cases. If you would change inputmethod to dictionary and had a valid content for the value when it was inputmethod (like t-latn-post,NoIME) then that value would not make sense as a value for dictionary. Therefore, when changing the name of the setting, I would need to clear the value and make it empty. This might surprise users who don’t really think about why the value would need to be reset to empty. Overall the only thing you could recycle from what was there before would be the regular expression. It is almost as easy to create a new entry then and copy and paste the regular expression from the old one, then delete the old one. It is only very little more work and one does probably not do that very often. But it would be a tiny bit easier to edit the name of the setting only, keep the regular expression and enter a new value. Therefore I already thought about this ...

But the main reasons why I didn’t do it immediately have to do with the user interface:

I don’t want to allow to edit the name of the setting as a free form text field like the regular expression where you can enter anything you like. The field for the values already does some very basic checks and refuses to let you enter some invalid stuff. For example if you try to type anything else but "True", "true", "False", or "false" into a value field expecting a bool, it does not accept that and sets the field to empty again, shows the hint bool again and lets you try again. Or if you type anything into a value field expecting int which is not parsable as a base 10 integer, it does not accept it.

When allowing to edit the field for the name of the setting by typing into that field, I surely should check for input which is not an allowed setting and refuse.

But making the user type the full setting is inconvenient anyway, when adding a new setting with the + button one can select from the list of allowed settings and maybe type a few characters to make the list shorter. So instead of letting the user type into the field for the setting name, my idea is to open the same setting name selection popover which is opened when + is pressed also when the user double clicks on the setting name.

That is pretty easy to do, but then I thought about where that popup should point to. When clicking the + button, the popover which opens is “relative to” the + button, i.e. it has a little triangle pointing to the + button indicating it emerged from there:

But when double clicking on an already existing name of a setting, having the popover point to that + button feels a bit wrong.

In Gtk3 (ibus-typing-booster is currently using Gtk3) I can set such a popover relative to anything I like. For example in emoji-picker I do this when you right click on an emoji:

The popover points to the emoji you right clicked on.

In Gtk3, this thing the popover points to can be anything one likes:

https://docs.gtk.org/gtk3/method.Popover.set_relative_to.html

I feel it would be natural to make the popover point to the setting one has just double clicked to edit it instead of making it point to the + button which one has not clicked.

In Gtk4, the popover does not have the set_relative_to() method anymore. See:

https://docs.gtk.org/gtk4/migrating-3to4.html

Adapt to GtkPopover changes

In GTK 3, a GtkPopover could be attached to any widget, using the relative-to property. This is no longer possible in GTK 4. The parent widget has to be aware of its popover children, and manage their size allocation. Therefore, only widgets with dedicated popover support can have them, such as GtkMenuButton or GtkPopoverMenuBar.

If you want to make a custom widget that has an attached popover, you need to call gtk_popover_present() in your Gtk.WidgetClass.size_allocate vfunc, in order to update the positioning of the popover.

So in order to make it possible that the popover points to the name of the setting which was just double clicked, I probably would need to put GtkMenuButton into the first column of the treeview listing the autosettings. Currently, these are just strings.

Eventually I want to port ibus-typing-booster to Gtk4. Therefore, I don’t want to add any more stuff which is easy to do in Gtk3 but makes porting to Gtk4 more difficult. If I want to do this now, I should probably try in Gtk3 already whether I can put GtkMenuButtons into the first column instead of strings. I then wondered how the look and feel would change if I do that. Probably the first column would look a little bit different then. Which might actually be a good thing. And it might offer some new possibilities like showing a tooltip on each of these menu buttons explaining in more detail what this setting is about and what to enter as the value. A tooltip for dictionary could explain the the value should be a comma separated list of dictionary names (That explanation seemed too long for me to put as a placeholder hint in the empty value field, so I just show str there, but as a tooltip it would be fine).

So when I thought about this and kept the future migration to Gtk4 in mind, I thought this is going to be quite complicated, I should think more about it before doing this.

A lot of extra work for very little effect.

And as I will be going on vacation soon, I wanted to finish the work on the autosettings GUI and make a release before going on vacation.

If you have more ideas about how this should work and how it should look like, please share your ideas. I will think about it and maybe improve the autosettings GUI after my vacation.

[psads-git]

Thanks, Mike, for your answer!

I find autosetting fantastic because now I can have ibus-typing-booster automatically switching on where I want it switched on: gedit, WhatsApp, thunderbird, etc. Until now, I had to manually switch on and off ibus-typing-booster.

Regarding the possibility of editing the first setting of autosettings, I agree with you: Too much work for such a small benefit -- I did not imagine the whole complexity you describe in your answer. Perhaps, the best is to leave it as it is.

I have an idea: To make the selection of the focused window easier. For instance, I have not been able to find a way to address Google Chrome. I have tried:

• chrome
• google-chrome
• google\-chrome

I do not know whether it is possible to have a search input box where one would insert chrome and it would be expanded to the proper regex expression. What do you think about that, Mike?

[mike-fabian]

gtk3-im:google-chrome: should work as a regular expression to match all google-chrome tabs.

If that does not work for you, my guess is you are using Gnome Wayland and did not set the environment variable to enable the accessibility interface to be used by google-chrome and firefox:

export GNOME_ACCESSIBILITY=1

See the end of the chapter about the autosettings in the online documentation:

https://mike-fabian.github.io/ibus-typing-booster/docs/user/#2_2_7

[psads-git]

Thanks, Mike, for your reply.

I guess I am not using Gnome Wayland, but the X Window System. Moreover, I can address Firefox with the autosettings, but not Chrome.

[mike-fabian]

I have an idea: To make the selection of the focused window easier. For instance, I have not been able to find a way to address Google Chrome. I have tried:

* `chrome`
* `google-chrome`
* `google\-chrome`

All these 3 should work (and they work for me actually).

You do not need to escape the - in a regular expression, I believe \- does the same as just -.

As all these 3 should work, but apparently didn’t work for you, my guess in the last comment was that you are using Gnome Wayland and did not set

export GNOME_ACCESSIBILITY=1

which is necessary to make this work for google-chrome.

Even though chrome, google-chrome, google\-chrome should work, I would recommend to use a more restrictive match.

Using just chrome would match if anything in the window title contains chrome as well. For example if you use gedit to edit a file called chrome or you use firefox and look at a website which contains chrome in the title of the website.

At the minimum, I would recommend to use:

:.*chrome.*:

Do you know regular expressions? The .* stands for any number of any characters.

As the format for the client id is

<im toolkit>:<program name>:<window title>

using :.*chrome.*: would match gtk3-im:google-chrome: Whatever but it would not match gtk3-im:firefox: some webpage title containing chrome.

Just using chrome would match that firefox webpage with the title some webpage title containing chrome.

But even :.*chrome.*: might match by accident. For example it would match:

gtk3-im:firefox: some webpage title containing :stuff chrome more stuff: even more stuff

So to make it even more reliable, better don’t just guess and use vague matches using .* but use the exact name of the program, which is google-chrome.

And add the toolkit in front to make it even less likely for the regular expression to accidentally match in some window title, i.e. better use

gtk3-im:google-chrome: as the regular expression.

This still could theoretically match by accident in the window title, so to make it perfectly safe, require that the match starts at the beginning by adding a ^.

So this would be the most reliable regular expression to match only google-chrome and nothing else:

^gtk3-im:google-chrome:

[mike-fabian]

Thanks, Mike, for your reply.

I guess I am not using Gnome Wayland, but the X Window System. Moreover, I can address Firefox with the autosettings, but not Chrome.

This is weird because on Xorg it should just work without setting any environment variables.
It does work for me for google-chrome running on Xorg without setting GNOME_ACCESSIBILITY=1.

[psads-git]

I have not set GNOME_ACCESSIBILITY=1, and it works fine with Firefox, Mike.

[mike-fabian]

Did you check what happens when you set the debug level in the typing-booster settings to >=1 and type into google-chrome using Typing Booster until you see a candidate list?

You should see a debug text on top of the candidate list starting with the window emoji 🪟, after that emoji you should see the client id which google-chrome has and which the regular expression must match.

[mike-fabian]

As in this screenshot:

[psads-git]

By following your instructions, Mike, I found that, in my case, we need to use:

^gtk3-im:google-chrome-stable:

The word stable is needed. I guess the reason is that I use the Google itself Chrome rpm to install Chrome.

And yes, I do know regex.

[mike-fabian]

Oh, surprising!

I installed google-chrome by having this repo:

mfabian@fedora:~
$ cat /etc/yum.repos.d/google-chrome.repo
[google-chrome]
name=google-chrome
baseurl=https://dl.google.com/linux/chrome/rpm/stable/x86_64
enabled=1
gpgcheck=1
gpgkey=https://dl.google.com/linux/linux_signing_key.pub
mfabian@fedora:~
$ 

and then

 sudo dnf install google-chrome-stable
Last metadata expiration check: 0:00:11 ago on Tue 28 Feb 2023 11:45:38 AM CET.
Dependencies resolved.
==============================================================================================================================================================================================
 Package                                             Architecture                          Version                                         Repository                                    Size
==============================================================================================================================================================================================
Installing:
 google-chrome-stable                                x86_64                                110.0.5481.177-1                                google-chrome                                 95 M
Installing dependencies:
 liberation-fonts                                    noarch                                1:2.1.5-3.fc37                                  fedora                                       7.8 k

Transaction Summary
==============================================================================================================================================================================================
Install  2 Packages

Total download size: 95 M
Installed size: 304 M
Is this ok [y/N]: y

[mike-fabian]

By following your instructions, Mike, I found that, in my case, we need to use:

^gtk3-im:google-chrome-stable:

The word stable is needed. I guess the reason is that I use the Google itself Chrome rpm to install Chrome.

And yes, I do know regex.

One could use ^gtk3-im:google-chrome.*: if one wants this to work for both your and my system.

[mike-fabian]

That one has to do this with regular expression makes the "autosettings" really a feature only usable by quite advanced users. But I see no other way to do it, I think the flexibility of the regular expressions is needed to allow the user to specify exactly which windows should match.

[psads-git]

Thanks, Mike. Yes, I think that its very reasonable to intend the autosettings to advanced users. And, therefore, regular expressions are the best option.

[psads-git]

Apparently, Mike, it is impossible to auto-set chatGPT:

In the image, we see the name of a conversation, but nothing like openai.

[mike-fabian]

Yes, then it cannot work, unfortunately. I have no idea at the moment how to get any more information than

<input toolkit>:<program name>:<window title>

[psads-git]

Thanks, Mike, anyway.

[mike-fabian]

This extension does the trick for Firefox:

https://addons.mozilla.org/en-US/firefox/addon/tab-retitle/

Using that, I can automatically rename all tabs for the domain chat.openai.com to ChatGPT $0 where $0 is the original title.

Maybe there is a similar extension for Google Chrome.

[mike-fabian]

Same extension for Google Chrome:
https://chrome.google.com/webstore/detail/tab-retitle/hilgambgdpjgljhjdaccadahckpdiapo/
I just tried it on Google Chrome and it worked there as well.

[psads-git]

Thanks a lot, Mike! That works fine!

[mike-fabian]

I have some ideas about how to improve figuring out the window ids. Currently the best way is to set the debug level to >= 1 and type in the window you are interested in and see what the debug string on top of the candidate list shows. Or grep through the debug.log.

But ibus-typing-booster sees all these strings while you click around. It could collect them. To communicate these to the setup tool, one would need to store them somewhere, where the setup tool also has access, one could for example store it in a special gsettings key. As the window titles may contain private information, one could store only the <input toolkit>:<program name> part. That should be enough information, especially that is the hidden information which the user cannot easily see and has to figure out using that debug stuff. The window titles are easily visible to the user anyway.

In the "Autosettings" tab of the setup tool, ibus-typing-booster could then also show a searchable list of window ids which it already has seen before. If one has been using typing-booster for a while, most of the windows a user typically uses should already be there and if it is searchable, searching for "chrome" in your case would have easily found gtk3-im:google-chrome-stable:.

Such a searchable list could be displayed below the list of autosettings. Or, maybe better, such a searchable list could popup when one starts to edit an empty regexp field and one could search and choose one of these offered or choose none and start from scratch. And then refine the regexp for the chosen one by adding window title stuff for example.

A friend suggested, that one could ask the user to click a window to get a window id for that window filled into the regexp field. Like when you add a key binding, you don't have to type Control+Tab into some free text form, but you are asked to type the keys and then the result gets filled in.

So the setup tool could ask: Now click the window you want! Then typing-booster could get that window id and communicate it via gsettings back to the setup tool and the setup tool could then fill it in and let the user do more editing to refine it.

This is quite complicated though. And there are many problems in the details. Quite often, clicking a window does not yet give that information immediatelyl For example, when clicking a firefox tab which shows the language learning site www.duolingo.com, that duolingo page might be in a state where no input is possible at the moment and then typing-booster may not see a focus_in event. Or sometimes it sees focus_in events which have fake:... instead of something like gtk3-im:.... That happens sometimes when no input is possible. Sometimes this is seen when clicking on the desktop background or sometimes when clicking on a program which has an input field but it is a password input field where the input is disabled. I.e. it is possible that one gets something like fake:keepassxc:keepass.kdbx [Locked] - KeePassXC and I have also seen fake:firefox:....

So the idea of "Click the window you want!" and then fill in the regexp has a lot of problems in the details, I am not sure whether it is possible to make that work reliably.

But showing a searchable list of already known window ids when starting to edit an empty regexp field might be very helpful.

But as I am going on vacation soon, I just write down this ideas for improvement, I might work on this later.

[psads-git]

Thanks, Mike, for the ideas that you advance: They are all very good!

And yes, I have noticed that, from time to time, ibus-typing-booster does not turn on in the window selected: One needs to leave the window and come again. Perhaps, as you say, the window is busy with something else.

[mike-fabian]

Thanks, Mike, for the ideas that you advance: They are all very good!

And yes, I have noticed that, from time to time, ibus-typing-booster does not turn on in the window selected: One needs to leave the window and come again. Perhaps, as you say, the window is busy with something else.

It is possible that in that case when it does not turn on, that the window id is fake:google-chrome-stable: and not gtk3-im:google-chrome-stable: because input was impossible for whatever reason.

So maybe if you change the regexp to ^.+:google-chrome-stable: it turns on more reliably.

With the ^.+: I try to match both fake and gtk3-im, one could even be more restrictive and try ^(fake|gtk3-im):google-chrome-stable: to be more sure to avoid accidental matches.

Although turning it on when input is not possible anyway is not really useful, it may look more natural that it switches to the 🚀 icon instead of the 🐌 more reliably on entering the window, even if no input is possible.

Not sure whether this helps, but it might, would be interesting to try it out whether this works better for you.

[psads-git]

Thanks, Mike. By using

^(fake|gtk3-im)

it seems that it works better, in the sense that I have not noticed any delay, up to now, in ibus-typing-booster switching on in the selected windows. If the problem recurs, I will report that here.

[mike-fabian]

Great that you tested that!

One can never see these client ids starting with fake in the debug output above the candidate list because this fake occurs when input is not possible and one could not get a candidate list anyway. But one can find them grepping in the ~/.local/share/ibus-typing-booster/debug.log file.

So I should think about how to make this a bit easier to figure out.

[psads-git]

It has worked just fine, Mike!

The autosettings is really a very great improvement of ibus-typing-booster: It avoids the constant manual switching on and off.