Shortcuts with newlines

[psads-git]

Dear All,

Is it possible to expand a shortcut with a text that contains newlines?

Example:

br

expanding to

"Best regards,

Paul"

Thanks in advance,

Paul

[mike-fabian]

The code which does this is here:

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

        # Update self._digits_used_in_keybindings:
        self._digits_used_in_keybindings = False
        for command in keybindings:
            for keybinding in keybindings[command]:
                if (keybinding
                    in ('0', '1', '2', '3', '4',
                        '5', '6', '7', '8', '9',
                        'KP_0', 'KP_1', 'KP_2', 'KP_3', 'KP_4',
                        'KP_5', 'KP_6', 'KP_7', 'KP_8', 'KP_9')):
                    self._digits_used_in_keybindings = True

and here:

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

            if self.is_empty():  # <- that means the preedit is empty!

                [...]

                if (self._digits_used_in_keybindings
                    and not self._tab_enable
                    and key.msymbol
                    in ('0', '1', '2', '3', '4', '5', '6', '7', '8', '9')):
                    # If digits are used as keys to select candidates
                    # it is not possibly to type them while the preëdit
                    # is non-empty and candidates are displayed.
                    # In that case we have to make it possible to
                    # type digits here where the preëdit is still empty.
                    # If digits are not used to select candidates, they
                    # can be treated just like any other input keys.
                    #
                    # When self._tab_enable is on, the candidate list
                    # is only shown when explicitely requested by Tab.
                    # Therefore, in that case digits can be typed
                    # normally as well until the candidate list is
                    # opened.  Putting a digit into the candidate list
                    # is better in that case, one may be able to get a
                    # reasonable completion that way.

                [... commit the digit immediately or transliterate it and commit it ...]

[mike-fabian]

As you can see in the comment in the second chunk of code, there is another way you could type digits into the preedit without removing them from all keybindings:

You could use the option “Enable suggestions by key (Default is the Tab key)”.

If that option is use, you only get suggestions on request. This is useful for user who don’t want to complete stuff all the time and find the candidate list popping up all the time annoying. But from time to time they want a candidate list because they are nor sure about the spelling of a word, want to input an emoji, want to expand a custom shortcut ...

With that option on, “1a” goes into the preedit and no candidate list pops up. Typing Tab then pops up the candidate list which contains “one artist” if you defined “1a” as a shortcut for this.

I don’t usually use the “Enable suggestions by key (Default is the Tab key)” option, I like to have the completions always.

[psads-git]

Thanks, Mike! If it does not imply too much work, it would be best if the shortcuts were (user) sortable by each field.

Can you open a new issue for that to remind me?

Done so meanwhile, Mike. Thanks!

[mike-fabian]

If you look a the code chunks above, you see that the decision whether number are allowed in the preedit or not is a bit rough.

When only a single digit, whether from the digit row or the keypad digits is in any keybinding, digits are not allowed into the preedit and are committed (possibly transliterated) directly.

This could be improved to more fine grained control.

For example, if the keyboard used has both a number row and a numeric keypad, then one could decide to commit candidates only with the digits from the number row but not commit candidates from the numeric keypad.

I.e. change the keybindings to something like:

commit_candidate_1_plus space   ['1', 'F1']

Then, if I implemented more fine grained control, I could allow digits typed using the numeric keypad to enter the preedit now because they are not used in keybindings anymore.

Or the other way around, if the keybindings were changed to

commit_candidate_1_plus space   ['KP_1', 'F1']

then I could allow digits typed with the digit row into the preedit and candidates would only be committed when typing the digits with the numeric keypad.

I would probably implement this based on individual keys if I do it.

I.e. if the preedit is empty and a digit is typed using 0, 1, ..., 9, KP_0, KP_1, ... , KP_9, then check whether this particular key to type a digit is used in any keybinding and if not allow it into the preedit and if yes commit it.

Currently it is quite rough: “If any digit key is used in any keybinding, do not allow any digits into the preedit but commit them all immediately".

[mike-fabian]

If you think I should implement that, please open an issue for that.

[mike-fabian]

By the way, probably from Monday on I will be away until the beginning of April so don’t be surprised if I cannot reply then.

[psads-git]

If you think I should implement that, please open an issue for that.

I shall open an issue for that, yes, Mike. Thanks!

[psads-git]

By the way, probably from Monday on I will be away until the beginning of April so don’t be surprised if I cannot reply then.

No problem, Mike! Enjoy!

[psads-git]

The problem is not only with shortcuts. The following just happened to me:

Mac M1

expands to

Mac Mac.

I would expect the same problem while writing down telephone numbers.

[mike-fabian]

The problem is not only with shortcuts. The following just happened to me:

Mac M1

expands to

Mac Mac.

I would expect the same problem while writing down telephone numbers.

Yes, of course, if 1 commits the first candidate, you cannot write M1 into the preedit.

If you want to be able to do that, remove the keys 1, ..., 9, KP_1, ..., KP_9 from the keybindings.

But then you have to type F1 to commit. And on most keyboards the F1 key is further away from the fingers than the 1 key, so that might not be convenient.

Of course one can commit using the mouse but that is even less convenient because one hand has to leave the keyboard to grab the mouse.

Actually the way I personally most often select and commit a candidate is by hammering on the Tab key and then space. First hit of the Tab key selects the first candidate, second Tab key the second candidate, ... when the right candidate is reached commit with space (Shift+Tab goes backwards by the way).

So by default the digits 1, ..., 9, KP_1, ..., KP_9 are used to select and commit candidates, but there are other options and if one is happy with one of the other options one can remove the digits from the keybindings and then become able to type digits into the preedit.

If I improve the current code I can make it possible leave either 1, ..., 9 or KP_1, ..., KP9 in the keybindings to commit candidates and use the other which is not in the keybindings to type digits into the preedit. Currently it is all or nothing, currently you have to remove all digit keys from the keybindings to be able to type digits into the preedit. I can improve it so make it possible to type digits into the preedit with one set of digit keys and commit candidates with the other set of digit keys.

[mike-fabian]

https://download.copr.fedorainfracloud.org/results/mfabian/ibus-typing-booster/fedora-33-x86_64/02074075-ibus-typing-booster/

This build contains the above change plus one other change, this one:

commit fdf1b8b84c6c9ad34dceaf91a6366b3f28348950 Author: Mike FABIAN mfabian@redhat.com Date: Fri Mar 12 16:53:14 2021 +0100

Don’t use surrounding text if InputPurpose.TERMINAL is set.

I don’t know of any terminal which has working surrounding text support.
xfce-4-terminal and gnome-terminal claim to have surrounding text support
by setting the respective client capabilities, so ibus-typing-booster
thinks surrounding text should work. But it doesn’t work at all in these
terminals, it is even worse than not working at all because the surrounding
text retrieved is from the application used before changing the focus to the terminal.
See this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1847347
(“gnome-terminal and xfce4-terminal get surrounding text from previous application”)

But gnome-terminal and xfce4-terminal also set InputPurpose.TERMINAL.
So I can ignore surrounding text support when InputPurpose.TERMINAL is set.
That improves the current situation a bit for gnome-terminal and xfce4-terminal.
Better no surrounding text at all then a completely wrong one.

As soon as a terminal which sets InputPurpose.TERMINAL *and* has really
working surrounding text support, I have to change this again, but
for at the moment it helps.

[mike-fabian]

As you are interested in the user defined shortcut feature of ibus-typing-booster, what do you think of this?:

https://github.com/mike-fabian/ibus-typing-booster/issues/271

Is my implementation to allow punctuation in shortcuts and make shortcuts case and accent sensitive OK for you?

[psads-git]

Thanks, Mike, for asking me for my opinion. I hope you are well and in good health.

Your implementation of allowing punctuation in shortcuts is a real improvement! It allows for better discrimination among shortcuts, specially for users that define many shortcuts. Thanks!

Now, changing the subject a bit. Recently, I came across the following:

https://www.lightkey.io/

Maybe it will help us to get new ideas for ibus-typing-booster!

[mike-fabian]

Your implementation of allowing punctuation in shortcuts is a real improvement! It allows for better discrimination among shortcuts, specially for users that define many shortcuts. Thanks!

Thank you! And what about allowing upper case and accents to distingish user shortcuts? I think this is probably OK as well but I am not 100% sure.

[mike-fabian]

Now, changing the subject a bit. Recently, I came across the following:

https://www.lightkey.io/

Maybe it will help us to get new ideas for ibus-typing-booster!

Thank you! I’ll have a look!

[psads-git]

Thank you! And what about allowing upper case and accents to distingish user shortcuts? I think this is probably OK as well but I am not 100% sure.

It may be useful, Mike, specially if the expansion of the shortcuts is long. For short expansions, I do not see great usefulness, since the shortcut is more costly to type (e.g., accented characters take pressing two keys in sequence). Personally, I always avoid typing accents.

And this discussion is now triggering an idea on my mind: Should not misspelled words be automatically corrected? For instance, when one writes

tambem

(word that does not exist in Portuguese), should not ibus-typing-booster correct that to

também

?

[mike-fabian]

Thank you! And what about allowing upper case and accents to distingish user shortcuts? I think this is probably OK as well but I am not 100% sure.

It may be useful, Mike, specially if the expansion of the shortcuts is long. For short expansions, I do not see great usefulness, since the shortcut is more costly to type (e.g., accented characters take pressing two keys in sequence). Personally, I always avoid typing accents.

Yes, I probably would not use accents in my user shortcuts either. Maybe I would use capital letters, but probably not accents.

For normal words we investigated that saving the capital letters and/or the accents to the user database was not good and made the prediction quality on average worse.

For normal words, we also strip the punctuation before saving them to the user database, saving them together with the punctuation would also make the prediction quality worse.

Before I implemented the improvement for the user shortcuts, the user shortcuts were saved to the user database with the same restrictions as any other normal word, i.e. punctuation was stripped, everything was converted to lower case and accents were stripped.

But while changing the code to allow punctuation in user shortcuts, I noticed that I could just as well also remove the limitation not to use capital letters and accents because user shortcuts are a special case anyway. Although saving to the user database without punctuation, capital letters and accents improves the prediction for normal words, this statistical improvment doesn't seem to apply at all to user shortcuts.

So I thought there is no harm in making all of these (punctuation, capital letters, and accents) possible in user shortcuts. Might be useful to somebody and won't cause any harm.

I just had some remaining doubts and if I release it like that and later discover that allowing capital letters and accents in user shortcuts was not a good idea and I change this again, then the users who did define such shortcuts with capital letters and/or punctuation would lose these shortcut again if the update removes the support. Quite unlikely, I don't think it causes any harm so I probably will never remove that.

[psads-git]

Yes, Mike, I agree that it is quite unlikely that it will be needed to remove accented and capitalized user shortcuts as an ibus-typing-booster feature. So, I guess that you can go ahead.

[mike-fabian]

And this discussion is now triggering an idea on my mind: Should not misspelled words be automatically corrected? For instance, when one writes

tambem

(word that does not exist in Portuguese), should not ibus-typing-booster correct that to

também

?

If you type tambem while using a Portuguese dictionary, you will already get também as a candidate. It is even the first candidate by default unless your previous typing has made Typing Booster learn something different.

So you can just select the first candidate (e.g. by typing Tab) and commit (e.g. with space). Or select and commit in one go by typing 1 or F1.

So ibus-typing-booster already does correct this, just not 100% automatically.

ibus-typing-booster also already has an option

[✓] Automatically select the best candidate

If that option is on and you type tambem and também is the first candidate, it is already selected (blue background in the candidate list) and space commits it.

I.e. typing tambem + space would commit também.

SwiftKey on Android has a similar option

[✓] Autocorrect (Words will be corrected to the middle prediction as you type)

(Middle prediction is the middle one of the three prediction buttons on the smartphone, the middle prediction is the “best” prediction, i.e. this is what is the first candidate in ibus-typing-booster.)

I hate this option and always switch it off. If this is on, I always get some some automatic “spelling corrections” inserted while I just continue to type and don’t select any prediction candidates manually. And they are almost always wrong for me, they introduce lots of silly and sometimes funny mistakes but rarely help.

Sometimes I think adding the

[✓] Automatically select the best candidate

to Typing Booster was a mistake, for me it causes more harm than good.

But you can try to experiment with that option and see whether it does anything useful for you.

I.e. the feature you ask for already exists, misspelled words can be automatically corrected already by using that option, if there is any further work to be done it would be to improve the details of this automatic correction.

Spelling corrections are in most cases not unique, in most cases the spellchecking programs suggest many possibilities, for example:

$ echo carmel | hunspell -d en_US 
Hunspell 1.7.0
& carmel 6 0: calmer, camel, caramel, carrel, cartel, carpel

I you wanted to write camel but accidentally typed carmel and then get calmer committed just because it is the first candidate suggested by the spellchecker isn't really helpful.

At the moment, I find the option

[✓] Automatically select the best candidate

pretty useless. Maybe it could be useful if it would select the best candidate not always but only if this best candidate is really extremely good.

And we would need to figure out what extremely good means.

Maybe it could mean something like: “It has all the same base letters in the same order and only differs by accents”. That would select também automatically when typing tambem.

I could just change the behaviour of that option a to not blindly select the first candidate always but only in really good cases.

Or, I could change the checkbox option [✓] Automatically select the best candidate into a combobox option like

Automatically select the best candidate [Never|For very good candidates|Always]

[mike-fabian]

Typing tambem using a Portuguese dictionary with and without the option

[✓] Automatically select the best candidate

https://user-images.githubusercontent.com/2330175/155746663-a14c4dcd-c640-43f2-8b7a-8fdfb830dc15.mp4

[psads-git]

Thanks, Mike! I have been aware of the option

[✓] Automatically select the best candidate

And, like you, I do not use such an option, because it is not enough intelligent.

What I was meaning was something along what you discuss in the last part of your message. Sometimes, it can be determined, with almost full certainty, what the candidate selection should be: The example of word tambem. In fact, that is a word that does not exist in the Portuguese language and, moreover, almost coincides with a word belonging to the Portuguese dictionary: também. I believe that, at least in Portuguese, there are numerous words in the class I have just defined.

[mike-fabian]

Thanks, Mike! I have been aware of the option

[✓] Automatically select the best candidate

And, like you, I do not use such an option, because it is not enough intelligent.

What I was meaning was something along what you discuss in the last part of your message. Sometimes, it can be determined, with almost full certainty, what the candidate selection should be: The example of word tambem. In fact, that is a word that does not exist in the Portuguese language and, moreover, almost coincides with a word belonging to the Portuguese dictionary: também. I believe that, at least in Portuguese, there are numerous words in the class I have just defined.

Yes, that is the exactly the case I meant with the third possible option in

Automatically select the best candidate [Never|For very good candidates|Always]

Never would be the same as if the currently available option is off.

Always would be the same as if the currently available option is switched on.

For very good candidates would automatically select only in such cases where we have “almost full certainty”.

We might have “almost full certainty” if the typed word and the first candidate have the same length, have a minimum length of say 5 letters, all base letters are the same and the order of the letters is also the same. The only difference is that the typed word has no accents but the first candidate has accents. I guess in that case we have “almost full certainty” that this is correct (There maybe some corner cases where it is still incorrect, but probably not many).

[mike-fabian]

Thanks, Mike! I have been aware of the option [✓] Automatically select the best candidate And, like you, I do not use such an option, because it is not enough intelligent. What I was meaning was something along what you discuss in the last part of your message. Sometimes, it can be determined, with almost full certainty, what the candidate selection should be: The example of word tambem. In fact, that is a word that does not exist in the Portuguese language and, moreover, almost coincides with a word belonging to the Portuguese dictionary: também. I believe that, at least in Portuguese, there are numerous words in the class I have just defined.

Yes, that is the exactly the case I meant with the third possible option in

Automatically select the best candidate [Never|For very good candidates|Always]

Never would be the same as if the currently available option is off.

Always would be the same as if the currently available option is switched on.

For very good candidates would automatically select only in such cases where we have “almost full certainty”.

We might have “almost full certainty” if the typed word and the first candidate have the same length, have a minimum length of say 5 letters, all base letters are the same and the order of the letters is also the same. The only difference is that the typed word has no accents but the first candidate has accents. I guess in that case we have “almost full certainty” that this is correct (There maybe some corner cases where it is still incorrect, but probably not many).

So instead of adding a new option, I would just add an additional possible setting for the already existing option.

[psads-git]

Yes, Mike, it would not be a new option, but a level of the already existent option.

That may be implemented without any programming: By using shortcuts! For instance, a shortcut for também could automatically be expanded to também. I am not sure what is the best approach.

[psads-git]

Actually, Mike, I think that maybe an option for automatic expansion of user-selected shortcuts should be added, as some shortcuts are candidates with full certainty.

[mike-fabian]

Yes, Mike, it would not be a new option, but a level of the already existent option.

That may be implemented without any programming: By using shortcuts! For instance, a shortcut for também could automatically be expanded to também. I am not sure what is the best approach.

But doing that with user shortcuts, the user would have to add thousands of shortcuts manually. I think that’s what dictionaries are for.

On top of that, shortcuts currently behave just like any other word with the option

[✓] Automatically select candidate

If that option is set, the first candidate is automatically selected, if not, it is not selected. Same for shortcuts and normal words.

But I think with shortcuts you have found another “almost full certainty” case. If the first candidate is a unique shortcut, i.e. there is no other shortcut which matches the same input, then the third value of the improved option (For very good candidates) should probably select it automatically, just like in the tambem/também case.

[psads-git]

Maybe, Mike, we can go even further with this idea of "almost full certainty": Perhaps, if the first candidate has a ranking too above the remaining candidates, the first candidate is an "almost full certainty" candidate!

[mike-fabian]

Maybe, Mike, we can go even further with this idea of "almost full certainty": Perhaps, if the first candidate has a ranking too above the remaining candidates, the first candidate is an "almost full certainty" candidate!

Yes.

[mike-fabian]

It sounds like a pretty good idea.

Not very easy to implement, I think I might have time for this in April.

[psads-git]

Thanks, Mike! There is no hurry: Implement that only when you can.

I think it will also lead to a cleaner database, as, in my case, with word tambem, for instance, I prefer to commit it and correct that after I finish my phrase.

Maybe, to define the ranking of the candidates, a classification machine learning model can be used.

[mike-fabian]

I think it will also lead to a cleaner database, as, in my case, with word tambem, for instance, I prefer to commit it and correct that after I finish my phrase.

As we save “normal” words to the database without accents, it does not matter here. “também” is always saved as “tambem” to the database.

[psads-git]

You are right, Mike: My example was badly chosen! But sometimes one writes with typos and prefers to wait to correct the type after having finished the phrase. Suppose that one writes tamben (notice the n instead of the m): With automatic correction, the database would get cleaner.

[mike-fabian]

You are right, Mike: My example was badly chosen! But sometimes one writes with typos and prefers to wait to correct the type after having finished the phrase. Suppose that one writes tamben (notice the n instead of the m): With automatic correction, the database would get cleaner.

Yes, but in a case like tamben versus também it is not clear anymore whether this is really “almost full certainty”.

For example in German, grüner, grünes, grünem, grünen are all valid words.

[psads-git]

I guess, Mike, that in the dictionary there is no word closer to tamben than também:

http://todaspalavras.com/starts-with-by-length/tamb/

So, this is also a case of "almost full certainty", I guess.

[mike-fabian]

I guess, Mike, that in the dictionary there is no word closer to tamben than também:

http://todaspalavras.com/starts-with-by-length/tamb/

So, this is also a case of "almost full certainty", I guess.

Yes, but it is more complicated than that.

One complication is that one could be using several languages the same time for example. Then you have to consider whether there is no closer word in several languages at the same time.

Hunspell isn’t so sure that there isn’t anything closer to tamben than também either. When asked for spellchecking suggestions for tamben in Portuguese, Hunspell gives:

[mfabian@fedora ~]$ echo -n 'tamben' | hunspell -d pt_BR 
Hunspell 1.7.0
& tamben 12 0: tambeense, entambe, tambetá, butambeno, tambetara, sambenita, intambe, mutambense, tambeiro, tambetaru, tatambear, sambento

[mfabian@fedora ~]$

também isn’t even in the list of suggestions.

Even though Hunspell knows that também is a valid Portuguese word:

[mfabian@fedora ~]$ echo -n 'também' | hunspell -d pt_BR 
Hunspell 1.7.0
*

[mfabian@fedora ~]$

No suggestions here means também is a correctly spelled word.

[psads-git]

I thought Hunspell more accurate than in reality is. For instance, Microsoft Word guesses that tamben may correspond to também:

[mike-fabian]

One complication is that one could be using several languages the same time for example. Then you have to consider whether there is no closer word in several languages at the same time.

[mike-fabian]

In the example in my last comment I am learning French with duolingo. I have to type both French and English sentences. Therefore, I have setup Typing Booster to use both the English and the French dictionary.

In the above screenshot, I want to type “arrived”. As the French dictionary is also active, I get “arrivé” as the first candidate (Actually it is not even from the French dictionary but already from previous user input, I can see that because of the black colour and the missing dictionary symbol 📖). If I had typed the same context “would have arrived” recently, the first candidate would probably be “arrived” already, but apparently I didn’t type that yet.

So I get the French suggestion “arrivé”. This first candidate has the same base letters in the same order as the typed word and only adds accents. If we conclude “almost full certainty” now, then “arrivé” would be automatically selected. If I notice that,I could deselect it by typing Escape. But if I don’t notice and just continue typing the final d of arrived, then the selected “arrivé” gets committed and the d added. So the final result becomes “arrivéd”. And then I have a weird error in my final sentence:

“Without this traffic jam we would have arrivéd already”

This is the reason why I always switch the option

[✓] Autocorrect (Words will be corrected to the middle prediction as you type)

off when using SwiftKey on Android because it very often introduces such errors for me.

Similar things could happen with tambem/também maybe.

So it is really hard to figure out whether the first candidate really has “almost full certainty” to be correct or not.

[psads-git]

I am not still fully convinced, Mike. Take your example:

Without this traffic jam we would have arrivéd already

The trigram:

would have arrivéd

would have zero frequency of previous use. Then, in your example, of all 6 suggestions, only the correct one would qualify as “almost full certainty” candidate, as all the others would have a trigram with zero frequency.

Moreover, most of people use only a single dictionary or maybe two at most.

[mike-fabian]

I didn’t want to say that it is impossible to figure out when one really has “almost full certainty”, just that it is very difficult.

My example only showed that the simplistic rule “spelling is the same only accents are missing” is not good enough.

As you say one also needs to consider the frequency of previous use of the whole context.

And one probably should consider whether words are found in dictionaries for the whole context, not only for the current word.

For example, when one has typed “would have arrive”, then the last word “arrive” is found in both the French and the English dictionary but “would” and “have” are only found in the English dictionary. So the “arrivé” is definitely not a “full certainty” suggestion, even though it just adds an accent. As “arrive” without the accent is also a valid French word, even if the whole context is French it isn’t necessarily correct to add the accent.

“Le train arrive” = “The train arrives” “Le train à arrivè” = “The train has arrived”

So for “almost complete certainty” we probaly need something like:

1. the whole context can be found in a dictionary of a single language
2. the whole context has a high user score because it has been typed many times before
3. the suggestion doesn’t change the order of any letters
4. the suggestion doesn’t change the length, only adds or removes accents.

I guess 1. and 2. are really a necessary condition for a “almost complete certainty” suggestion. I am not sure about 3. and 4.

But overall it is a quite difficult problem, I have to think about it and try out several things.

Such a feature has to work correctly almost 100% of the time, if it introduces too many errors it is not helpful (like the current “Automatically select the best candiate” option is almost useless).

On the other hand, if the conditions to have “almost complete certainy” are so strict that they are almost never met, then such a feature would not help much either. It would help all that much if you get an automatic selection only once in a blue moon when the stars are aligned perfectly.

I think I will probably try to add a third value to that option to autoselect the best candidate if we have “almost complete certainty” for that candidate. But I think it is not easy at all.

[psads-git]

I think the 4 conditions you, Mike, enumerate for "almost full certainty" are good -- they will very rarely fail to predict the word wanted by the user.

The automatic selection will not for sure be of the type "only once in a blue moon". Why? Because that will allow the user to write completely without accents. Thus, automatic selection will always be in use, increasing typing speed a lot while providing a pleasant experience for the user.

[mike-fabian]

I will certainly try that when I come back from vacation.

[psads-git]

Thanks, Mike. Have a nice vacation!

[mike-fabian]

I opened a new issue for this: https://github.com/mike-fabian/ibus-typing-booster/issues/285