Capitalize suggestions when pressing shift

[eranl]

Capitalize suggestions according to the current keyboard shift state, and suggest the capitalized version of the current word.

Should this be guarded by a setting?
Should batch input be treated the same way?

Fixes #540, fixes #783, fixes #1800, fixes #1584.

Replaces #1745.

[Helium314]

This works well, but there is "weird" behavior in some cases.

• when typing "towar", I get towar, towards, toward. When pressing shift, it's towar, Towards, Toward, i.e. no way of typing Towar
• when typing "eggr", I get egg, eggs, egger. When pressing shift, it's Egg, Eggs, Egger, so the same but uppercase, and no way of typing Eggr
• when typing "fore", I get core, fire, force. When pressing shift, it's fore, Fore, Core, meaning now it will autocorrect

Incoming autocorrect makes the typed word show on the left. I think this is stil fine, but the typed word should follow the new caps rules.
Not sure if the "sometimes autocorrect" is acceptable. In the current state autocorrect should only happen when we already had autocorrect before pressing shift, or when the lowercase word is in a dictionary.
As for the second example, it might be good to add the capitalized typed word to the suggestions.

Should this be guarded by a setting?

I don't think so, we can add one later if some users dislike this behavior.

Should batch input be treated the same way?

Yes, it should be independent on whether the user used glide typing or not.

[eranl]

the typed word should follow the new caps rules.

Shouldn't the typed word always be exactly what you typed?

it might be good to add the capitalized typed word to the suggestions.

In what location?

Yes, it should be independent on whether the user used glide typing or not.

Done.

[Helium314]

Shouldn't the typed word always be exactly what you typed?

My reasoning for following the new capitalization rules is that having a lowercase suggesting with this feels strange, and otherwise it doesn't work with a word that isn't in a dictionary.

In what location?

I think the second (left) suggestion would be good. In my opinion it should be in the typedWordString, unless you have a reason to really always keep the exact typed word.

[eranl]

This works well, but there is "weird" behavior in some cases.

• when typing "towar", I get towar, towards, toward. When pressing shift, it's towar, Towards, Toward, i.e. no way of typing Towar

• when typing "eggr", I get egg, eggs, egger. When pressing shift, it's Egg, Eggs, Egger, so the same but uppercase, and no way of typing Eggr

• when typing "fore", I get core, fire, force. When pressing shift, it's fore, Fore, Core, meaning now it will autocorrect

Incoming autocorrect makes the typed word show on the left. I think this is stil fine, but the typed word should follow the new caps rules. Not sure if the "sometimes autocorrect" is acceptable. In the current state autocorrect should only happen when we already had autocorrect before pressing shift, or when the lowercase word is in a dictionary. As for the second example, it might be good to add the capitalized typed word to the suggestions.

Fixed.

I think the second (left) suggestion would be good. In my opinion it should be in the typedWordString, unless you have a reason to really always keep the exact typed word.

For non-batch, I used the existing logic of if (hasAutoCorrection) 2 else 1. For batch, for consistency, I put it in location 1.

Some minor issues:

• if you want to capitalize a (next-word) suggestion you picked, you have to delete the phantom space first, and using Shift for that doesn't work. Make deleting a phantom space a separate backspace press #1803 would help here.
• there's sometimes a strange difference in suggestion results depending on the shift-state of the keyboard. Try the word but. I'm guessing it's because of the proximity info containing lower- vs. upper-case letters.

[Helium314]

if you want to capitalize a (next-word) suggestion you picked, you have to delete the phantom space first, and using Shift for that doesn't work.

That's fine, because the PR is only about suggestions. A slight inconvenience trying to capitalize after picking a suggestion is ok.

there's sometimes a strange difference in suggestion results depending on the shift-state of the keyboard. Try the word but. I'm guessing it's because of the proximity info containing lower- vs. upper-case letters.

Ultimately it's coming from the approach of getting new suggestions when changing capitalization. And possibly the behavior is coded inside the native library.

[eranl]

there's sometimes a strange difference in suggestion results depending on the shift-state of the keyboard. Try the word but.

Ultimately it's coming from the approach of getting new suggestions when changing capitalization. And possibly the behavior is coded inside the native library.

It gets even stranger: if you type but, But, or BUT, you get different suggestions, and they change again for each of the three shift states.
Looks like it's not specific to this change.

[Helium314]

The "but" thing is weird, and knowing the problem already from the start is not ideal.
But fixing it would possibly need a different approach than getting new suggestions, which I expect to be be considerable work.

[summersab]

Unless I misunderstand, this doesn't implement #783. That is for capitalizing words that have been typed by pressing shift followed by space instead of having to retype, edit, or highlight the word.

[eranl]

It implements a variation of #783, proposed in the discussion. It still lets you capitalize words that have been typed by pressing shift without having to retype, edit, or highlight the word, but it requires that you pick the capitalized version from suggestions.

A direct implementation of #783, #1745, proved problematic.