When cycling case by pressing shift+F3, and there is no selection, the sentence case formatting will be applied to the entgire sentence, but all other formats are applied only to the current word. So, the entire sentence will be affected even though I only intended to change one word.
Steps to Reproduce:
1. Type the sentence "Mary Jones met Joe Smith"
2. Put the cursor between the 'm' and the 'e' in met
3. Press Shift+F3 three times
Mary jones MET joe smith
Mary Jones MET Joe Smith
User Profile Reset: No
This is a follow-on from discussion in bug 49033.
It's not a problem when there is a selection, because all of the formatting commands will affect all of the selected words.
I can think of two possible solutions:
1. Change the behavior of case cycling such that it does not apply sentence case formatting if there is no selection; or
2. Change the behavior of each case format operation to store the command in the undo information ("cycle case" or "direct"), then whenever cycle case command is executed, have it check the top of the undo stack and if the undo information indicates that the previous command was a cycle case that applied sentence case, have it undo that command before executing the next case change.
Undo works for me. But the fact that case cycling is applied to the whole sentence without proper feedback is an usability issue. So how about selecting the whole sentence automatically? Would make the operation consistent with a clear feedback and shows how a single word/term can be cycled- by selecting this part.
The topic was on the agenda of the design meeting.
+ an automatic selection would be contra-productive because is force
to adapt users to the behavior of the application (Sascha)
+ the ideal behavior would be as OP suggest, only change current word
if no selection is done (Sascha)
So let's do this.
(In reply to Heiko Tietze from comment #3)
> + the ideal behavior would be as OP suggest, only change current word
> if no selection is done (Sascha)
If this is the decision then I submit that we should just skip applying sentence case formatting if cycling without selection, because applying sentence case only to the current word is equivalent to applying title case in this situation.
(In reply to Michael Warner from comment #4)
> (In reply to Heiko Tietze from comment #3)
> > + the ideal behavior would be as OP suggest, only change current word
> > if no selection is done (Sascha)
> If this is the decision then I submit that we should just skip applying
> sentence case formatting if cycling without selection, because applying
> sentence case only to the current word is equivalent to applying title case
> in this situation.
No, the cycle case is four distinct actions . For consistency, with or without selection must still be four states. So, logic for Sentence case without selection would need to apply at the word bound holding the cursor, just as TITLE_CASE.
So, either test that we are in the cycle case loop--and modify the SENTENCE_CASE handling, or fully remove the expanded run passed to the SENTENCE_CASE transliteration .
Put another way, SENTENCE_CASE would *require* a selection (now trivial to make at sentence bounds via mouse or keyboard) that would be honored exactly with no expansion. Otherwise it would no longer expand beyond word holding text cursor and behave like TITLE_CASE.
Probably simpler to do the later.
The Format -> Text -> Sentence case would be minimally effected--maybe adjust do nothing with out a selection. While the cycle case mode would gain consistency (with or without selection), the main complaint.
My understanding of what was desired in Comment 3 is that if there was no selection and user selected Format -> Text -> Sentence Case, it would continue to affect the entire sentence as before. It would only be restricted to the current word if there was no selection and user pressed Shift+F3.
My point from Comment 4 is that by continuing to apply Sentence Case to the current word when cycling without selection, now the user will see the same result twice in the cycle, once from the Title Case action, and once from the Sentence Case action. This will appear to be a bug to that person.
The downside to skipping Sentence Case when cycling without selection is there will appear to be three states; and when cycling WITH selection, there will appear to be four states, which would also seem like an issue, if there is only one word selected, then the user sees the same thing in twice again, so it doesn't fully solve that problem either.
I am starting to think there is no completely consistent behavior with Sentence Case in the cycle case rotation at all.
(In reply to Michael Warner from comment #6)
> I am starting to think there is no completely consistent behavior with
> Sentence Case in the cycle case rotation at all.
Right. Which was basis for my suggestion to eliminate the expand to sentence bound (which I'm not sure our ICU lib tests even do correctly) leaving either transliterate exactly the selection--or--expand only to the word bound (for title, sentence, upper, lower) when no selection was made.
Making an exact selection for word, sentence, or paragraph is now trivial--it was not before the UNO commands were implemented and made available to keyboard or mouse click actions.
Whatever solution we implement it probably makes some users unhappy. The point of this discussion is that we have transparency in case of incoming complaints. My concerns besides consistency and learnability¹ is a clear feedback (unfortunately the auto-selection idea was not accepted).
¹ It would be terrible if we have to show a notification if the user expectation is not met. I think no selection - no action is easy to understand and can be described clearly in the documentation.
I am un-assigning myself from this bug. The lack of response from committers to my patches for Bug 49033 and Bug 144851 leaves me with little confidence that any patch I were to provide for this bug would ever be merged.
(In reply to Michael Warner from comment #9)
> I am un-assigning myself from this bug. The lack of response from committers
> to my patches for Bug 49033 and Bug 144851 leaves me with little confidence
> that any patch I were to provide for this bug would ever be merged.
That would be a great pity! I see a comment on bug 49033 and would suggest to poke users at least once again (me inclusive; sorry for not responding immediately).
*** Bug 145121 has been marked as a duplicate of this bug. ***