mike-fabian
commented
2 years ago The problem is with the \, mapping just em to somethis@somewhere.domain works. So the shortcut can be independent of the expansion already, it doesn’t have to contain anything from the expansion.
The problem why \ does not work is because of:
https://github.com/mike-fabian/ibus-typing-booster/blob/main/engine/itb_util.py#L149
When ibus-typing-booster tries to complete a word, it strips off characters from these categories (Punctuation characters).
This is to make '(Hecomplete to(Helloeven though there is no '(hello in /usr/share/myspell/en_US.dic only hello.
Also when saving user input to the user database, these characters are stripped off, i.e. when typing (Hello, then hello is saved to the database (lower case and without the (). Storing the ( as well does make the database bigger without helping the quality of the predictions, similar as storing the case doesn’t help the predictions.
Currently, the shortcuts for these user defined expansions are treated as normal words, i.e. they cannot contain characters from the above punctuation categories.
You are right that currently ibus-typing-booster lets you define such an expansion even though it doesn’t work.
That should be improved.
I am thinking about how it should be improved.
- Maybe it would be OK if ibus-typing booster prevents you from typing such characters into the
Enter shortcut here:field in the first place? Maybe just beep if you try to type such a character into that field and do not insert the character (A popup with an explanation why this character cannot be used is probably too much ...) - Let the user type whatever he wants into the entry field but when clicking
Add shortcut, pop up a message like “The shortcut contains the following illegal characters:\”
A disadvantage of the current implementation not allowing characters from punctuation categories in shortcuts is of course that shortcuts interfere a bit with “normal” word prediction. Currently all of my shortcuts start with ms (sy shortcut). So if I have a shortcut like msem, then while typing the m the shortcuts starting with ms already fill the first few pages of the candidate list. I have to scroll down a few pages in the candidate list to find the first English words starting with m. This is not a really serious problem because no real words start with ms, at least not in English. So as soon as the second letter is typed it is clear whether I want a shortcut or whether I am looking for English words.
Another option which currently works is to use characters which are neither punctuation nor Latin letters as short cut starters.
For example defining
€so to expand to somewhere over the rainbow
is possible with the current implemtation. And € happens to be on my keyboard layout (my layout is “English (US, euro on 5)”).
I am thinking of making it possible to use these punctuation characters as well in shortcuts, but it looks a bit difficult with the current implementation.
Just making these punctuation characters work in shortcuts seems like the best solution though, I’ll keep thinking about it, maybe I can find a way to do it.
In the meantime, I hope the above explanation is at least somewhat helpful.
Adding an user shortcut that maps "\em" to expand into "somethis@somewhere.domain" don't work at all.
This also happens in a silent way, the application accepts the shortcut but, as far as I could see, it is not usable. I believe that the setup should either: