[ENHANCEMENT] Case-insensitive shortcuts

[psads-git]

Hi, Mike,

I have just noticed that, for instance, for the shortcut

London

when writing

l

(notice the L in lower case),

the suggestion of the shortcut is not triggered, whereas with typing

L

the shortcut is suggested.

Maybe lower case typing should trigger the shortcut suggestion. What do think about that?

[mike-fabian]

I think you are talking about the user shortcuts you define manually in the setup tool.

I made this case sensitive on purpose because you are free to define them any way you like. And making it case sensitive gives you the option to define different shortcuts for l and L which I thought might be useful.

By the way, since I improved the shortcuts to allow arbitrary characters in shortcuts, I stopped using shortcuts starting with letters, all my shortcuts are starting with \ now. That makes it interfere less with the normal predictions, I like that better. If I have a shortcut starting with l it is suggested with high priority when I just want to type some word starting with l and this is usually not what I want. At least for my usage it is better to have my shortcuts start with something I don't usually type in normal text.

[psads-git]

Thanks, Mike, for your answer. I am sorry for I was not very clear: I mean not the shortcut that triggers the expansion, but the expansion itself.

Suppose we have the shortcut

lo

that expands to

London

If we type L, we immediately get London as inline autocomplete suggestion, but not when we type l (lowercase L).

[mike-fabian]

If yo type l you cannot get London as an inline completion because completions are never shown inline when the completion would change anything you typed already. In this case, the lower case l would need to change to uppercase L, therefore no inline completion can be shown. Inline completions which do not just make what you typed longer but change something you already typed would be far to confusing.

As you can see in the video below, l does trigger the shortcut London, only it cannot be shown inline.

That means if you option to shown inline completions is "Yes. without fallback to popup”, then London is not shown immediatelyi but it is shown when you type Tab to force showning the candidate list.

My preferred setting for inline completions is “Yes, with fallback to candidate list”. Using that, typing l shows the shortcut London immediately, not inline but as the first candidate of the candidate list which pops up. I think this is better because it makes it clear that this might be more than just an extension of what you typed.

User defined shortcuts are case sensitive. Therefore, L does not trigger the shortcut expansion lo ➡️ London.

The reason why you see London as an inline completion when typing L is that the word London is in the English dictionary and probably also in the database of the words you typed before.

In the video you can clearly see that, I did set the debug level to 3 and switched off inline completion at the end of the video to always show show a candidate list and to show the weights calculated for the candidates. When typing l, I can see the candidate London 1000000. This shows that it was a shortcut expansion because shortcut expansions have weights >= 1000000. “Normal” completions always have weights between 0 and 1. When typing L I get the first candidate London 0.99… which shows that this is not a shortcut expansion but a “normal” completion with close to the maximum weight.

https://github.com/mike-fabian/ibus-typing-booster/assets/2330175/6e320fc1-58c8-47ca-9544-8cde14f518f3

[psads-git]

Inline completions which do not just make what you typed longer but change something you already typed would be far to confusing.

True, Mike. But the inline completion does not need to use the previously typed characters as part of the completion. For instance, suppose one types

l

the completion would be added to the l

lLondon

(notice the first l would not be replaced by capital L) and that would be converted to

London

only after committing the completion.

I am not sure whether this change is worthy the effort to implement it, Mike!

[mike-fabian]

No, I don’t think this makes sense. This would not be inline completion but showing a full candidate inline behind what you typed. That would be very confusing in practice.

[psads-git]

I understand, Mike. Thanks!

Since I do not have any other idea that might improve the inline completion of capitalized shortcuts, I would suggest to close this enhancement ticket.

[mike-fabian]

OK, I’ll close one.

But feel free to report more stuff, your reports are always useful. Even though I am closing this one now without having done any change to the code, it was good to think about it.