Bug 144853 - Sentence case applied around word, not undone when cycling case with Shift + F3
Summary: Sentence case applied around word, not undone when cycling case with Shift + F3
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 145121 (view as bug list)
Depends on:
Blocks: Selection CaseCycling
  Show dependency treegraph
 
Reported: 2021-10-01 13:23 UTC by Michael Warner
Modified: 2021-12-15 13:56 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Warner 2021-10-01 13:23:05 UTC
Description:
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

Actual Results:
Mary jones MET joe smith

Expected Results:
Mary Jones MET Joe Smith


Reproducible: Always


User Profile Reset: No



Additional Info:
This is a follow-on from discussion in bug 49033.
Comment 1 Michael Warner 2021-10-01 13:32:11 UTC
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.
Comment 2 Heiko Tietze 2021-10-18 10:37:53 UTC
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.
Comment 3 Heiko Tietze 2021-10-21 12:48:02 UTC
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.
Comment 4 Michael Warner 2021-10-23 17:24:58 UTC
(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.
Comment 5 V Stuart Foote 2021-10-23 18:23:37 UTC
(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 [1]. 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 [2].

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.

=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/unotools/source/i18n/caserotate.cxx?r=84f8e28d#25
[2] https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit4.cxx?r=6af0da48#2774
Comment 6 Michael Warner 2021-10-23 20:24:37 UTC
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.
Comment 7 V Stuart Foote 2021-10-23 22:34:56 UTC
(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.
Comment 8 Heiko Tietze 2021-10-25 08:16:48 UTC
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.
Comment 9 Michael Warner 2021-11-25 23:10:07 UTC
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.
Comment 10 Heiko Tietze 2021-11-26 07:29:44 UTC
(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).
Comment 11 stragu 2021-12-15 13:52:03 UTC
*** Bug 145121 has been marked as a duplicate of this bug. ***