Bug Hunting Session
Bug 49033 - Change case -> Sentence case doesn't honor selection; case of entire sentence changes (STR comment 20)
Summary: Change case -> Sentence case doesn't honor selection; case of entire sentence...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 119495 120039 120254 120872 121350 123977 124760 127432 129144 (view as bug list)
Depends on:
Blocks: Character Selection
  Show dependency treegraph
 
Reported: 2012-04-21 01:53 UTC by Mike Kaganski
Modified: 2019-12-02 20:01 UTC (History)
18 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2012-04-21 01:53:03 UTC
If a part of a sentence is selected, the Format->Change case->Sentence case ignores this selection and changes the case of all characters in this sentence. This is very annoying, when I try to normalize case of a sentence like "CURRENT IS EQUAL TO 10 A" - the unit should stay uppercase, and it isn't selected, but still becomes lowercase.
Comment 1 bfoman (inactive) 2012-04-26 04:38:56 UTC
Confirmed with:
LOdev 3.5.3rc1+ 
Build ID: 51648779-22e3d74-d554af7
Windows 7 Professional SP1 64 bit
Comment 2 Cody 2012-04-29 12:57:31 UTC
LibreOffice 3.5.2.2
Build ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45
Running on Windows 7 Pro, SP1, 64 bit edition

The results were reproducible.
Comment 3 Kriton Kyrimis 2012-08-19 16:14:29 UTC Comment hidden (obsolete)
Comment 4 Ljiljan 2014-09-19 07:07:36 UTC
The bug is still not corrected (Libre Office 4.3)

I recorded video so effects of the bug could be easily understood: 

https://www.youtube.com/watch?v=n3n5P5Aqu44&feature=youtu.be
Comment 5 Gordo 2015-04-30 16:27:10 UTC
Reproducible in 4.4.3.2.

If you right click anywhere in a paragraph and apply Sentence case then the whole paragraph is affected.  All of the other Change Case options either affect the word that has the cursor or a selection.

From the help:  Changes the first letter of the selected western characters to an upper-case character.
Comment 6 Peter Roelofsen 2016-08-18 08:04:51 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2017-09-01 11:19:41 UTC Comment hidden (obsolete)
Comment 8 Kriton Kyrimis 2017-09-01 11:45:29 UTC
The bug is still present in LibreOffice 5.4.1.2.

The only thing that has changed is that the relevant menu entry has moved to "Format->Text->Sentence case".

Tested under Linux (OpenSUSE Tumbleweed), using the official LibreOffice binaries.
Comment 9 Peter Roelofsen 2017-09-05 19:45:30 UTC
Still present in 5.4.1.2. Apart from that, the whole change case code should be checked. Applying Sentence case to selected text in lower case will not change the first letter following a full stop to upper case. There are several other irregularities.
Comment 10 QA Administrators 2018-09-06 02:59:52 UTC Comment hidden (obsolete)
Comment 11 Kriton Kyrimis 2018-09-06 07:54:10 UTC
The bug is still present in version 6.1.1 RC1.

Info from Help->About LibreOffice:

Version: 6.1.1.1
Build ID: 2718b4a18dfcc6a54ebe5f7b801ee7a47fa81e0c
CPU threads: 2; OS: Linux 4.18; UI render: default; VCL: kde4; 
Locale: el-GR (en_US.UTF-8); Calc: CL
Comment 12 Luis Fernandes 2018-10-02 15:36:26 UTC
The bug is still present on Version 6.1.2.1

Versão: 6.1.2.1 (x64)
ID de compilação: 65905a128db06ba48db947242809d14d3f9a93fe
Threads da CPU:4; SO:Windows 10.0; Realizador da interface: padrão; 
Local: pt-BR (pt_BR); Calc: group threaded
Comment 13 V Stuart Foote 2018-10-24 21:00:39 UTC
*** Bug 120872 has been marked as a duplicate of this bug. ***
Comment 14 V Stuart Foote 2018-10-24 21:00:57 UTC
*** Bug 120039 has been marked as a duplicate of this bug. ***
Comment 15 V Stuart Foote 2018-10-24 21:01:08 UTC
*** Bug 120254 has been marked as a duplicate of this bug. ***
Comment 16 V Stuart Foote 2018-10-24 21:04:57 UTC
Likely needs to be tweaked in the string being passed to caserotate.cxx for ICU lib transliteration.

see 

https://gerrit.libreoffice.org/#/c/59894/

https://gerrit.libreoffice.org/#/c/51696/
Comment 17 V Stuart Foote 2018-10-25 12:44:58 UTC
*** Bug 120872 has been marked as a duplicate of this bug. ***
Comment 18 Giuseppe 2018-11-11 13:11:52 UTC
*** Bug 121350 has been marked as a duplicate of this bug. ***
Comment 19 Dieter Praas 2019-01-25 15:44:10 UTC
Can't reproduce it in

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 411f3a050ac2be598019d512f8ccfe041080c28f
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-01-14_03:17:11
Locale: en-US (de_DE); UI-Language: en-US
Calc: threaded
Comment 20 V Stuart Foote 2019-01-25 16:56:23 UTC
(In reply to Dieter Praas from comment #19)
> Can't reproduce it in

Unfortunately it remains to be fixed. And here are STR that still indicate the string handling of selection for ICU filter is wrong:

1. new Writer document
2. add DT -> F3 autotext for the DummyText
3. select the 'h' form "him." ending the first sentence, and capitalize
4. select all but the "Him." of the first sentence "He heard quiet steps behind "
5. cycle the applied ICU Transliteration filter with <Shift>+F3

Watch it cycle. If corrected the "Him." should remain capitalized? 

Currently it still does not.  Rather, the full sentence textrun, rather than the selection/or word, is affected upon cycling to the SENTENCE_CASE transliteration [1].

Imagine that is caused by difference in the "default" string handling for SENTENCE_CASE, by definition no substrings of selection/word? Edit engine seems to expand the selection when SENTENCE_CASE transliteration is applied here [2].

So, while we may not like it--behavior could be considered correct.

=-testing-=
Windows 10 Ent 64-bit en-US with
Version: 6.3.0.0.alpha0+ (x64)
Build ID: ffa5b8a82eab18041bbee4d6914892b82c7801d3
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-12-19_03:24:54
Locale: en-US (en_US); UI-Language: en-US
Calc: CL

-=ref-=
[1] https://opengrok.libreoffice.org/xref/core/unotools/source/i18n/caserotate.cxx
[2] https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit4.cxx?r=492ea7e0#2785
Comment 21 V Stuart Foote 2019-01-25 17:37:30 UTC
(In reply to V Stuart Foote from comment #20)

> Edit engine
> seems to expand the selection when SENTENCE_CASE transliteration is applied
> here [2].
> 
> So, while we may not like it--behavior could be considered correct.
> 

Seems this was intentional to "keep it simple by just capitalizing the first letter or each sentence", and so temporarily expand selection(s) to the full sentence for applying the transliteration.

see https://bz.apache.org/ooo/show_bug.cgi?id=113587#c5

But 9 years on does this need revisit? 

Maybe, since for bug 116315 we've now added the SENTENCE_CASE transliteration to the <Shift>+F3 cycling, meaning more folks will experience this during use.
Comment 22 V Stuart Foote 2019-01-25 17:37:41 UTC
*** Bug 119495 has been marked as a duplicate of this bug. ***
Comment 23 Peter Roelofsen 2019-01-25 22:36:37 UTC
+1 for @Mike Kaganski

Please note that most users aren't programmers. Their logic is different than the logic of the programmers. So the question is: Whose logic is right? I'd say that as the product is a productivity tool, the logic of the user should take precedence over the logic of the programmer, who may not be aware how a user may use features of the software. Anything that reduces the usability or efficiency of a productivity tool shouod be seen as bad, a show stopper, etc.
We're not playing a game between users and programmers, and nobody should try to win that game by inventing some "logic" so that you can maintain the status quo and "win". Registering a bug, issue or enhancement request is a daunting task for many users, Please remember that.
Comment 24 Philip Rayment 2019-01-25 23:57:04 UTC
> So, while we may not like it--behavior could be considered correct.

No, it is NOT correct.  Repeatedly pressing F3 to get to the case you need *destroys* any capitalisation that already existed, and thereby makes this function unusable in many cases.  That is NOT correct.  See the extensive discussion of bug 119495 which has now been closed as a duplicate of this one.

And please... FIX IT!
Comment 25 Philip Rayment 2019-01-26 00:01:25 UTC
In fact, I'll repeat some steps to reproduce that I provided on that other bug:

Type the sentence "john smith and joe blow wrote to fred jones.

Now, using Shift-F3 as many times you like and selecting whatever parts of the text you'd like, capitalise the first letter of each name, and only those letters.
If you can do it, I'd like to know how.
Comment 26 V Stuart Foote 2019-01-26 01:02:52 UTC
(In reply to Philip Rayment from comment #24)
> > So, while we may not like it--behavior could be considered correct.
> 
> No, it is NOT correct.  Repeatedly pressing F3 to get to the case you need
> *destroys* any capitalisation that already existed, and thereby makes this
> function unusable in many cases.

No one discounts that it has undesired effects. 

In comment 21 I've simply pointed to what causes users grief--noting that at the time it was implemented in 2010, the OOo users and developers chose to handle the SENTENCE_CASE transliteration against full sentences--expanding any selection to the include sentence boundary.

It is clear from discussion of the feature, they did not consider that the SENTENCE_CASE would be added to the <Shift>+F3 toggle, and that users applying it from Format menu would "only" use it rationally when they were cleaning up blocks of text. 

It is correct as it was implemented, and behaves programmatically as expected. It simply does not have the additional logic needed to deal with users seeking to apply sentence case selectively--when developed they did not think it would need it, and folks would be better served working with sentences rather than word selections.

Since the <Shift>+F3 case cycle now includes the SENTENCE_CASE transliteration, working with selections consistently becomes more of an issue needing dev attention to remove the annoyance.
Comment 27 Mike Kaganski 2019-01-26 06:25:09 UTC
Please refrain from insulting others by declaring someone is "playing games" and "tries to win", without even carefully reading what has been said (let alone understand):

(In reply to V Stuart Foote from comment #21)

> Seems this was intentional to "keep it simple by just capitalizing the first
> letter or each sentence", and so temporarily expand selection(s) to the full
> sentence for applying the transliteration.
> 
> see https://bz.apache.org/ooo/show_bug.cgi?id=113587#c5
> 
> *But 9 years on does this need revisit?* 
> 
> Maybe, since for bug 116315 we've now added the SENTENCE_CASE
> transliteration to the <Shift>+F3 cycling, meaning more folks will
> experience this during use.

Secondly, what users like to call "programmer's logic" is always another user's logic, which happens to not fit you, but that was adopted by programmer as an implementation specification. This reflects multitude of ways anything may be used, and there's no way to please everyone. This is what users refuse to accept when they insist that their "logic" (in this context it's the way they use something) is universal. Yes, programmer's choice of specification may be bad in the sense that it doesn't reflects the majority's use case, but that needs proving, and it's not easy (in bug reports, you always see the PoV of those who disagree with the status quo, and those who agree are Just happily use it and don't visit bug reports).

In this case, my "logic" (as user who filed the report, also being a developer) differed from the "logic" adopted by the feature author, who considered multiselection usecase (which I didn't), but didn't consider normalizing pasted chunks of text that had bad case in the source (where author's presumptions doesn't hold).

Now that the feature started to be used in a scenario not meant initially, this became more important.
Comment 28 Peter Roelofsen 2019-01-26 23:36:29 UTC
Mike Kaganski: I am not insulting anybody. I feel insulted by programmes who refuse to consider serious error reports by competent users. And add to the insult by stating that tge cide is correct, implying that the users are stupid.

For a similar case, but for OpenOffice, see this discussion in the OO Issue tracker: https://bz.apache.org/ooo/show_bug.cgi?id=119407

(Orcmid, the last person to post a comment in that discussion, was then a senior staff member of AOO development at Apache.)

We're now several years later, right now I can't test if the bug still exists in AOO, but I'm fairly sure that it does. I rest my case.
Comment 29 Philip Rayment 2019-01-27 01:34:27 UTC
> It is correct as it was implemented, and behaves programmatically as expected.
You're probably right, but the issue is what "it" is.  This bug as opened was about how sentence case works.  The problem I see is that bug 119495 has been closed as a duplicate of this bug, but that bug was about sentence case being used in the Shift-F3 cycle.  So "it" now includes the latter.  Perhaps bug 119495 should not have been considered a duplicate, and should have remained open?

> It is clear from discussion of the feature, they did not consider that the SENTENCE_CASE would be added to the <Shift>+F3 toggle...
And to my mind, that is the key problem, because...

> No one discounts that it has undesired effects.
... the result is not just an "undesired effect", but a situation where Shift-F3 is largely UNUSABLE.

Perhaps the quick fix is to remove sentence case from the Shift-F3 cycle so that that is usable again, then come to some agreement about the original issue in this bug and how it can be incorporated into the Shift-F3 cycle without making that unusable.

But maintaining that the way that sentence case works is arguably correct ignores the bigger problem of the Shift-F3 cycle being unusable, and therefore misleads as to the urgency of fixing that clear bug.
Comment 30 Mike Kaganski 2019-01-27 09:54:38 UTC
(In reply to Philip Rayment from comment #29)
+1

(In reply to Peter Roelofsen from comment #28)
> Mike Kaganski: I am not insulting anybody. I feel insulted by programmes who
> refuse to consider serious error reports by competent users. And add to the
> insult by stating that tge cide is correct, implying that the users are
> stupid.

You show exactly what I said: users believe that they Hold The Truth. They believe that they are Competent Users, and thus what they raise is Serious Errors.

Now let's see this problem again. I reported it while back, when Shift-F3 didn't include this function yet, and so my specific bug report doesn't cover the side effects of the inclusion of it into the Shift-F3. So I believe that bug 119495 is another bug.

And thus let's discuss the original issue here, which both I and Peter Roelofsen raised here and at Apache. Which is affecting what is not selected (I don't tell about ignoring a char after full stop bit from Apache bug, which I cannot repro, and I didn't raise here).

And so now Peter Roelofsen says: "programmes ... refuse to consider serious error reports by competent users" - so he clearly just dismisses the others' opinions. He mentions another opinion of Orcmid as a "proof", and treats all others arguments as "insulting", which is clearly not constructive approach, but a technique to make own PoV look "ultimate truth".

But the original implementation specifically made it work like that, to cover *another user's* demand to be able to mark *parts* of sentences in multi-selection mode, and have the *full sentences* processed. It means that Peter Roelofsen declares that *another user* "stupid" (using his own terminology), not the programmer who implemented that.

Note that I still consider changing the implementation to only handle selection to be the right move; not because I suppose the implementation to be erroneous, but because I believe that change would cover larger set of use cases, and be more compliant with least surprise principle. But I understand that this is arguable; and I will never dismiss another's opinion contradicting mine to be insulting or dismissive, unless that opponent uses unfair argument technologies. Even less will I consider insulting posts that bring the original design bits into the discussion, which allows one to have fuller and better understanding of the picture.

Personally I would consider the seriousness of the problem that Orcmid caller serious as documentation problem [1], where the intended behavior of the function is not described. And then again, this my issue is about choosing if my suggested approach is beneficial to more users than existing approach, nothing more.

[1] https://help.libreoffice.org/latest/en-US/text/swriter/guide/text_capital.html
Comment 31 V Stuart Foote 2019-01-27 15:09:30 UTC
(In reply to Mike Kaganski from comment #30)
+1

But the original issue as summarized in bug 119495 was clearly a duplicate of this. 

Absent SENTENCE_CASE's default expansion of selection, adding it to the <Shift>+F3 transliteration cycling would have been a non issue.

The non-reset of the mode cycling, with a timer based patch attempt, was issue creep--and arguable as to merit. But IMHO agree a reset upon detecting a selection change/edit cursor movement is probably the way to normalize its behavior.

From UX perspective, honoring the user's selection--eliminating the legacy auto expansion (or reduction) to work with "sentence" runs--is now more urgently needed to close this out as efficiently as possible. 

No need/advantage to reverting bug 116315 that can't be handled with changes needed to make SENTENCE_CASE apply to user selection, rather than to expanded runs between "sentence" breaks as now. 

Dev choice, but the actual refactoring could be ambitious (where is it used and should behavior be user settable in Advanced Configuration) or simple (move SENTENCE_CASE from TransliterationModulesExtra to TransliterationModules, apply to selection only). 

Adjust things here and you fix legitimate corruption of <Shift>+F3 cycling.
Comment 32 Ljiljan 2019-01-27 16:47:21 UTC
The current "Sentence case" logic would make perfect sense in case you select no single character and you expect to change cases of a complete sentence. However, in the case when you invest the effort to select the part of your text, there is no single justifiable reason to extend this to complete sentence. So, there are no two sides to this story; just the one that is currently implemented and the one that should be implemented (in case some developer have time; not requesting anything because I don't use "Sentence case" anymore or SHIFT + F3... I adjusted my behaviour with custom menus and custom shortcuts).  

With the current implementation, we are saying: "Oh, you selected the part of the text, but we believe you should consider the full sentence."
Comment 33 Peter Roelofsen 2019-01-27 17:18:37 UTC
In reply to Mike Kaganski: thanknyou for posting some real insulting stuff. If you tell people that they should not insultbother people, then don't insult other people yourself. Your reply is so typical if what I call playing games by belittling the user, it's amazing. 100 % score on the bullying scale.

Lilian summarizes it very nicely. The user is an idiot.

I'm done here. Your attitude is sickening.
Comment 34 Mike Kaganski 2019-01-27 20:29:05 UTC
(In reply to V Stuart Foote from comment #31)

Let's discuss the details :-)

1. What should be done when a sentence start is selected, but not to the sentence end? (I'm pretty confident the sentence start here should be capitalized.)
2. What should be done if a sentence end is selected, but not from start? (This one IMO is not that straightforward: we can capitalize the first selected character, or we may skip the sentence; my take would be capitalize first selected character.)
3. What should be done if selection starts in the middle of a word (possibly not the first in a sentence)? We could capitalize first character of the word (again not good for Shift+F3); or first selected character; or skip the sentence. (I'd capitalize first selected character.)
4. What should we do when there's no selection? We could capitalize first character of current word (if any; like UPPERCASE at al work); or current sentence. (My take is Capitalize current sentence.)
5. What should be done with Capitalize Every Word function, that now also expands to whole words, even if only parts are selected? It's not in Shift+F3 IIUC, but it would become inconsistent. (I'd say change it consistently.)
6. Should we only do the change for Word, or for other modules (Calc/Impress/etc) too for consistency? (I'd say yes.)
Comment 35 Ljiljan 2019-01-30 06:46:40 UTC
I just find it funny that we invest so much energy in something that just cannot be user's logic. You select the text and you expect to see changes in the selection.    

My following reply should be considered only as the purpose to illustrate how far we can go regarding this issue (my answer are written as satire just to illustrate how pointless this can be). We don't have empirical evidence to support which logic is right, but current logic "selection -> only selection changes" make more sense than "selection -> both selection and the text until the next full stop".    

(In reply to Mike Kaganski from comment #34)
> (In reply to V Stuart Foote from comment #31)
> 
> Let's discuss the details :-)
> 
> 1. What should be done when a sentence start is selected, but not to the
> sentence end? (I'm pretty confident the sentence start here should be
> capitalized.)

Maybe changes should be extended to all sentences in the document, and all sentence starts should be capitalized because that is what the user wants since he/she selected the beginning of the sentence. In case he/she wanted to select only the current sentence, then he/she should select the current sentence. Otherwise, he /she indicates that the start of the sentence is important and it should be changed consistently in the document. No, the user did not select this part of the text (sentence start) expecting it to be changed, he/she was expecting more! 

> 2. What should be done if a sentence end is selected, but not from start?
> (This one IMO is not that straightforward: we can capitalize the first
> selected character, or we may skip the sentence; my take would be capitalized> first selected character.)

The first next sentence should be capitalized, but also it should recommend capitalizing all other sentences in the following paragraph. After all, the user did not intend to capitalize this sentence since he/she did not select it from the beginning. No, the user did not select the sentence end expecting it to be changed, he/she was expecting more!   

> 3. What should be done if selection starts in the middle of a word (possibly
> not the first in a sentence)? We could capitalize first character of the
> word (again not good for Shift+F3); or first selected character; or skip the
> sentence. (I'd capitalize first selected character.)

In this case, we should you SpellCheck to see it this word exists in our dictionary. The user is probably not sure about the selection of the word (maybe he/she wrote "upcoming", but now considering only using "coming"). No, the user did not select this part of the text expecting it to be changed, he/she was expecting more!


> 4. What should we do when there's no selection? We could capitalize first
> character of the current word (if any; like UPPERCASE at al work); or current
> sentence. (My take is Capitalize current sentence.)

This is a special case where we should use AI to detect eyes movement in order to detect sentence user would like to capitalize. 
 
> 5. What should be done with Capitalize Every Word function, that now also
> expands to whole words, even if only parts are selected? It's not in
> Shift+F3 IIUC, but it would become inconsistent. (I'd say change it
> consistently.)

I don't understand this, but AI might help here too. 

> 6. Should we only do the change for Word, or for other modules
> (Calc/Impress/etc) too for consistency? (I'd say yes.)

Definitely. Impress would be great since people use bullets, no full stops, so this will capitalize only first bullet, and the other points would be lower case... One slide should look like a long sentence! The same applies to Calc. Maybe all sentences in one column can be changed to make it look consistent! Or row. Not sure anymore!
Comment 36 Mike Kaganski 2019-01-30 06:59:11 UTC
(In reply to Ljiljan from comment #35)

I had decided to fix this, and so I found all relevant code and  saw the implementation; while thinking of possible reimplementation, I fount it useful to ask specific questions, so that the programming decisions would be clear and based on user requirements.

But now you are free to fix this yourself. I'm no more interested in this.
Comment 37 Ljiljan 2019-01-30 07:04:09 UTC
(In reply to Mike Kaganski from comment #36)
> (In reply to Ljiljan from comment #35)
> 
> I had decided to fix this, and so I found all relevant code and  saw the
> implementation; while thinking of possible reimplementation, I fount it
> useful to ask specific questions, so that the programming decisions would be
> clear and based on user requirements.
> 
> But now you are free to fix this yourself. I'm no more interested in this.

No problem, I also stopped reporting bugs because their only purporse is to make developer aware what makes me nervous. Their logic is always the right one, afterall we are getting software for free so learn to live with that.
Comment 38 Kriton Kyrimis 2019-01-30 08:31:38 UTC
The way I see it, things are pretty simple: If the user selects a piece of text and asks for something to be done with it, he expects that something to be done with only that piece of text. If the result is not what he expected, his reaction will be "oh, yeah, I should have made a different selection", undo the change and try again. On, the other hand, if that something is done with other parts of the document, the user's reaction could well be "why did this happen? I didn't ask for this", as, e.g., with that A, signifying Amperes, in the first comment.

Thus, if you can fix this issue, please do so, and do it in the simplest possible way, i.e., only applying case changes in the selected text, even if it means introducing a capital letter in the middle of a word. There is no need for LO to try and second-guess the user.

Thanks.
Comment 39 Philip Rayment 2019-01-30 08:55:13 UTC
(In reply to Ljiljan from comment #35)
> You select the text and you expect to see changes in
> the selection.    
In most cases, yes, but not always.  For example, it makes little sense to apply sentence text to only part of a sentence, especially part that doesn't involve the start of it.  So it may not be the case you expect to see changes only in the selection in that case.

Mike Kaganski's questions were fair, and your satire was unhelpful.
Comment 40 Philip Rayment 2019-01-30 08:58:53 UTC
(In reply to Mike Kaganski from comment #36)
> (In reply to Ljiljan from comment #35)
> 
> I had decided to fix this, and so I found all relevant code and  saw the
> implementation; while thinking of possible reimplementation, I fount it
> useful to ask specific questions, so that the programming decisions would be
> clear and based on user requirements.
> 
> But now you are free to fix this yourself. I'm no more interested in this.

Mike, please don't allow one commenter to put you off this.  I didn't realise that you were planning on fixing this, and I thought your list of questions was just to illustrate the problems rather than seeking feedback that would be taken into account in an actual fix.  I'll have a go at answering your questions in a separate reply.
Comment 41 Ljiljan 2019-01-30 09:05:04 UTC
Let's say I start with this sentence: 

"This is my SENTENCE I wrote as an example to ILLUSTRATE the how the user might use this function [here I intend to put a full stop after changing it to sentence case] and THIS SENTENCE HAS NO PURPOSE AT ALL."

Now, I decide to split this into two sentences. I select this first part expecting to change the first part of the text to sentence case, and then I will put the full stop after "this function" part. But LibreOffice decides to change the complete paragraph, and I did not want the second part to be changed.

In the context of the user stories, this is a real scenario and the current implementation does not help. 

So honouring selection is important. We don't know what user intends to do. Selection helps here, not guessing. That was the point of my satire... not to offend everyone.
Comment 42 Philip Rayment 2019-01-30 09:24:34 UTC
(In reply to Mike Kaganski from comment #34)
> (In reply to V Stuart Foote from comment #31)
> 
> Let's discuss the details :-)
> 
> 1. What should be done when a sentence start is selected, but not to the
> sentence end? (I'm pretty confident the sentence start here should be
> capitalized.)
I'd suggest that the sentence start should be capitalised, and the rest of the selection (not sentence) made lower case.
> 2. What should be done if a sentence end is selected, but not from start?
> (This one IMO is not that straightforward: we can capitalize the first
> selected character, or we may skip the sentence; my take would be capitalize
> first selected character.)
I think the selection should be made lower case.  That wouldn't do anything that selecting lower-case would do, but if that's not what the user wanted, he would realise that the "error" is his in not selecting the start of the sentence.  And changing the selection to lower case would give exactly the same outcome as that portion of the sentence would have if the whole sentence had been selected, so there is some consistency there.
I make those two comment, though, on the basis of a user selecting part of *A* sentence.  If one selects several sentences, but only parts of the first and last sentences, doing it this way would make it inconsistent with Capitalise Every Word (which you do raise in Q. 5). 
> 3. What should be done if selection starts in the middle of a word (possibly
> not the first in a sentence)? We could capitalize first character of the
> word (again not good for Shift+F3); or first selected character; or skip the
> sentence. (I'd capitalize first selected character.)
You're still asking about sentence case?  If so, I'd treat this the same as in my answer to question 2.
> 4. What should we do when there's no selection? We could capitalize first
> character of current word (if any; like UPPERCASE at al work); or current
> sentence. (My take is Capitalize current sentence.)
If there is no selection, like other cases, the entire sentence (in this case) should be assumed to be selected.
> 5. What should be done with Capitalize Every Word function, that now also
> expands to whole words, even if only parts are selected? It's not in
> Shift+F3 IIUC, but it would become inconsistent. (I'd say change it
> consistently.)
It is in Shift+F3.  I'm undecided on this one.
> 6. Should we only do the change for Word, or for other modules
> (Calc/Impress/etc) too for consistency? (I'd say yes.)
I'd agree yes, although Calc is the only other one I use more than rarely, and I'd rarely use these functions in Calc, so my opinion may not be worth much here.

Your questions are good ones, and I've offered some thoughts, but I probably haven't properly considered all circumstances, so there may be good arguments against what I've said.
Comment 43 Philip Rayment 2019-01-30 09:28:22 UTC
(In reply to Ljiljan from comment #41)
> So honouring selection is important. We don't know what user intends to do.
> Selection helps here, not guessing. That was the point of my satire... not
> to offend everyone.
Now THAT was helpful.  I think you've made a good case for that particular circumstance, and it's compatible with the suggestions I offered.  I do think that honouring the selection is important; I just think that there may be special cases where it doesn't apply.  However, honouring the selection should be the starting point.
Comment 44 V Stuart Foote 2019-03-10 15:51:11 UTC
*** Bug 123977 has been marked as a duplicate of this bug. ***
Comment 45 V Stuart Foote 2019-03-29 18:25:32 UTC
To UX-Advise to move this forward...

But my take remains that the original implementation applying the SENTENCE_CASE, via ICU transliteration, needs additional control logic. 

Believe we need to handle two cases for applying SENTENCE_CASE in edit engine [1].

1) Case -- an active selection made:

   expand only to the ICU -word boundaries- that hold the selection and apply ICU transliteration. Treat that "temp" string as the sentence--and apply transliteration.  Since the transliteration of the selection likely cross sentence boundaries, would need to break selection into multiple "temp" strings (an opening, middle(s), a closing)--but honor the selections at the word boundaries as the range.

2) Case --  only text cursor focus, no selection made:

   expand only to the ICU -sentence boundaries- that hold the text cursor and apply ICU transliteration.

The current implementation for sentence case always performs the expansion when applying SENTENCE_CASE transliteration, with or without selection--that's the issue. Current implementation probably could/should be retained for a no selection case, but need to provide new code for the with selection handling.

=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit4.cxx?r=492ea7e0#2665
Comment 46 Philip Rayment 2019-03-30 08:10:15 UTC
(In reply to V Stuart Foote from comment #45)

I don't know what ICU means, but if I understand you, this would make any use of cycling with Shift-F3 and no selection unusable.  Suppose you want to capitalise a single word, so place the cursor in that word but don't select it.  Instead of capitalising that word, you could end up applying sentence capitalisation to the entire sentence, an unwanted and unexpected outcome.
Comment 47 V Stuart Foote 2019-03-30 13:03:49 UTC
(In reply to Philip Rayment from comment #46)
>
> I don't know what ICU means, but if I understand you, this would make any
> use of cycling with Shift-F3 and no selection unusable.  Suppose you want to
> capitalise a single word, so place the cursor in that word but don't select
> it.  Instead of capitalising that word, you could end up applying sentence
> capitalisation to the entire sentence, an unwanted and unexpected outcome.

No! In fact the change in comment 45 of explicitly handling selection state--would restore consistent and expected behavior to the UI and there is only so much protection we can give to users without impacting function.
If premise remains as for bug 116315, that SENTENCE_CASE belongs in the Cycle case list (Title Case, Sentence case, UPPERCASE, lowercase). Usage notes in documentation is sufficient to warn users to make a selection for cycling a single word.

Besides, this is exactly the behavior now. No selection for the other transliterations applies just to the ICU word boundaries at text cursor position,- while SENTENCE_CASE expands from that position to the sentence boundaries so no regression involved.

=-ref-=
ICU -- https://en.wikipedia.org/wiki/International_Components_for_Unicode
Comment 48 V Stuart Foote 2019-03-30 13:35:40 UTC
(In reply to V Stuart Foote from comment #47)
Should have acknowledged that one other alternative would be to require a selection for any of the Case rotate tranliteration to apply. Force user to make a selection. 

Not very onerous as we select word with double click, sentence with triple click, and paragraph with quad click. With comparable keyboard selection at word bounds.
Comment 49 Philip Rayment 2019-03-31 09:08:18 UTC
(In reply to V Stuart Foote from comment #47)

> No! In fact the change in comment 45 of explicitly handling selection
> state--would restore consistent and expected behavior to the UI 

Sorry, I must have misunderstood.  But please explain how this works in more detail.  If you have this sentence:
 "Mary Jones met joe Smith"
and put the cursor in "joe", but didn't select it, and press Shift-F3 to capitalise "joe", but you're at the wrong step in the cycle, then sentence case is applied instead, changing "Jones" to "jones" and "Smith" to "smith".  How does your proposal prevent that?

(In reply to V Stuart Foote from comment #47)
> ... Usage
> notes in documentation is sufficient to warn users to make a selection for
> cycling a single word.

What documentation?  Without trying an extensive search, I couldn't find any documentation on Shift-F3 beyond it being mentioned in the menus.
Comment 50 Heiko Tietze 2019-04-01 07:48:17 UTC
(In reply to V Stuart Foote from comment #45)
> To UX-Advise to move this forward...

Basically I agree with the selection on/off consideration. But how about to select the whole sentence first when nothing has been selected ("text cursor focus")? And to apply the function as it works today but always to the selection. It has the benefit of being more transparent to the user and simplifies workflow and code.

(In reply to Philip Rayment from comment #49)
>  "Mary Jones met joe Smith"

How the transliteration works is another question to me. I would keep the status quo which means:

(without selection)
TITLE_CASE: Mary Jones Met Joe Smith
SENTENCE_CASE: Mary jones met joe smith
LOWERCASE_UPPERCASE: MARY JONES MET JOE SMITH
UPPERCASE_LOWERCASE: mary jones met joe smith

("Mary Jones met [joe] Smith" - "joe" is selected)
TITLE_CASE: JOE
SENTENCE_CASE: joe
LOWERCASE_UPPERCASE: Joe
UPPERCASE_LOWERCASE: joe

("Mary Jones met [joe Smith]" - "joe Smith" is selected)
TITLE_CASE: Joe Smith
SENTENCE_CASE: Joe smith
LOWERCASE_UPPERCASE: JOE SMITH
UPPERCASE_LOWERCASE: joe smith

Any if-then condition complicates the procedure and makes it hard for users to predict the result.
Comment 51 V Stuart Foote 2019-04-01 12:31:06 UTC
(In reply to Heiko Tietze from comment #50)
>
> Basically I agree with the selection on/off consideration. But how about to
> select the whole sentence first when nothing has been selected ("text cursor
> focus")? And to apply the function as it works today but always to the
> selection. It has the benefit of being more transparent to the user and
> simplifies workflow and code.
> ...

Might be cleaner to explicitly do nothing unless there is a selection made. Making the expanded selection to sentence boundaries (from text cursor position) would still be too late for the user to avoid an unintended action.
Comment 52 Philip Rayment 2019-04-01 13:22:47 UTC
(In reply to Heiko Tietze from comment #50)

> How the transliteration works is another question to me. I would keep the
> status quo which means:
... 
> ("Mary Jones met [joe] Smith" - "joe" is selected)
> TITLE_CASE: JOE
> SENTENCE_CASE: joe
> LOWERCASE_UPPERCASE: Joe
> UPPERCASE_LOWERCASE: joe

Only that's NOT the status quo, if by that you mean what happens now, and if you're using Shift-F3 to cycle (perhaps you weren't referring to that??).  What happens now is:

> ("Mary Jones met [joe] Smith" - "joe" is selected)
> First  keypress: Mary Jones met [Joe] Smith
> Second keypress: Mary jones met [joe] smith (sentence case applied; Jones and Smith decapitalised)
> Third  keypress: Mary jones met [JOE] smith
> Fourth keypress: Mary jones met [joe] smith

I hesitate to suggest this, but one option may be to change the process to be as follows:
> ("Mary Jones met [joe] Smith" - "joe" is selected)
> First  keypress: Mary Jones met [Joe] Smith
> Second keypress: Mary jones met [joe] smith (sentence case applied; Jones and Smith decapitalised)
> Third  keypress: Mary Jones met [JOE] Smith (sentence case reverted/undone before trying next option)
> Fourth keypress: Mary Jones met [joe] Smith

This would be regardless of whether a selection was made or not.  The problem is that if the cycling is also fixed to start from the beginning of the cycle rather than the next step after the previous when a new bit of text is selected, the user might move the cursor elsewhere after the second step and be stuck with the unwanted sentence case.  Although there's always the undo button.
Comment 53 Heiko Tietze 2019-04-02 07:42:54 UTC
(In reply to V Stuart Foote from comment #51)
> Might be cleaner to explicitly do nothing unless there is a selection made.

That would feel like a regression for people who are used to the function.

(In reply to Philip Rayment from comment #52)
> ... (maybe I missed one cycle)
> I hesitate to suggest this, but one option may be to change the process to
> be as follows:
> ...
> > Third  keypress: Mary Jones met [JOE] Smith (sentence case reverted/undone before trying next option)

Changing text outside the selection contradicts our effort. So I wouldn't touch "smith".
Comment 54 Philip Rayment 2019-04-03 14:04:58 UTC
(In reply to Heiko Tietze from comment #53)

> > I hesitate to suggest this, but one option may be to change the process to
> > be as follows:
> > ...
> > > Third  keypress: Mary Jones met [JOE] Smith (sentence case reverted/undone before trying next option)
> 
> Changing text outside the selection contradicts our effort. So I wouldn't
> touch "smith".

The cycling ALREADY changes text outside the selection.  That's the problem (or one of them).  That step I was suggesting merely /reverts/ that change when sentence case is not required.  (And it wasn't just Smith; it was also Jones.)
Comment 55 Heiko Tietze 2019-04-04 05:34:06 UTC
(In reply to Philip Rayment from comment #54)
> The cycling ALREADY changes text outside the selection.  That's the problem...

Seems we agree on the required change. Cycle case should work on the selection and if there is none on the full sentence (as today). The consideration of automatically selection or doing nothing was misleading and might confuse users.
Comment 56 V Stuart Foote 2019-04-04 15:48:24 UTC
(In reply to Heiko Tietze from comment #55)
> 
> Seems we agree on the required change. Cycle case should work on the
> selection and if there is none on the full sentence (as today).

OK, we should proceed--apply SENTENCE_CASE with a bimodal behavior [ selection | no selection ].

But, Mike K's list of questions from comment 34 need a resolution. 

Also there is Justin L's work on bug 63529 and his abandoned https://gerrit.libreoffice.org/#/c/33581/ which tweaked word boundaries and proposed some control over the transliteration sequence depending on current state. 

Should we address that from UX perspective--or let it be, and just be satisfied here  with consistent "bimodal" selection handling of the fixed transliteration sequence for caserotate.cxx, i.e.:

TITLE_CASE -> SENTENCE_CASE -> LOWERCASE_UPPERCASE -> UPPERCASE_LOWERCASE;
Comment 57 V Stuart Foote 2019-04-04 17:29:31 UTC
(In reply to Mike Kaganski from comment #34)
> 1. What should be done when a sentence start is selected, but not to the
> sentence end? (I'm pretty confident the sentence start here should be
> capitalized.)

Yes, with selection of start of sentence--but not the whole run should honor the selection--capitalize first character, the rest of the selection to lower case per sentence case).

> 2. What should be done if a sentence end is selected, but not from start?
> (This one IMO is not that straightforward: we can capitalize the first
> selected character, or we may skip the sentence; my take would be capitalize
> first selected character.)

Yes, with selection made--honor the selection. Capitalize the first selected character, remainder of selection to lower case.

> 3. What should be done if selection starts in the middle of a word (possibly
> not the first in a sentence)? We could capitalize first character of the
> word (again not good for Shift+F3); or first selected character; or skip the
> sentence. (I'd capitalize first selected character.)

Yes, with selection made--pass exactly that string for transliteration--and then only the TITLE_CASE would need to expand to its word bound.

> 4. What should we do when there's no selection? We could capitalize first
> character of current word (if any; like UPPERCASE at al work); or current
> sentence. (My take is Capitalize current sentence.)

With no selection, i.e. text cursor only, this remains the rub! But, if no selection--should probably not apply to the whole sentence, applying just to the word at the text cursor position would "protect" users from clobbering things. Sentence case would then match the other transliterations.

> 5. What should be done with Capitalize Every Word function, that now also
> expands to whole words, even if only parts are selected? It's not in
> Shift+F3 IIUC, but it would become inconsistent. (I'd say change it
> consistently.)

Hmm, looks like the TITLE_CASE transliteration has always been in the caserotate.cxx -- obviously it has to apply to the Word bounds, current word for no selection--and to all words of a selection (including the opening word).

> 6. Should we only do the change for Word, or for other modules
> (Calc/Impress/etc) too for consistency? (I'd say yes.)

Needs consistency across _ALL_ modules

As a side bar to handling this--added a request for an UNO action to "Select Sentence" as bug 124552, to more precisely select sentence via a keyboard shortcut rather than a mouse cursor drag.
Comment 58 Heiko Tietze 2019-04-08 08:20:27 UTC
(In reply to V Stuart Foote from comment #57)
> (In reply to Mike Kaganski from comment #34)
> ....
> Yes, with selection made--honor the selection.

Fully agree.

> > 5. What should be done with Capitalize Every Word function, that now also
> > expands to whole words, even if only parts are selected? It's not in
> > Shift+F3 IIUC, but it would become inconsistent. (I'd say change it
> > consistently.)
> 
> Hmm, looks like the TITLE_CASE transliteration has always been in the
> caserotate.cxx -- obviously it has to apply to the Word bounds, current word
> for no selection--and to all words of a selection (including the opening
> word).

We could introduce an (advanced) option "[ ] Expand selection to word boundaries for transliteration" that changes the selection first. Looking at Justin's patch note 

| enhance Shift-F3 rotating between UPPER, lower, Title cases. 
| - allow cursor at the beginning of the word
| - allow cursor at the end of the word
| - allow cursor in whitespace before a word 
| - rotate based on current status, not on a blind counter

supports the idea of simplification.
Comment 59 V Stuart Foote 2019-04-15 18:56:16 UTC
*** Bug 124760 has been marked as a duplicate of this bug. ***
Comment 60 Justin L 2019-04-15 19:28:29 UTC
Most of the duplicates here are complaints that Sentence case was added to the Shift-F3 sequence in LO 6.1 

author	heiko tietze 2018-03-26 14:58:23 +0200
commit	84f8e28d092676aad830a9fbae8145a57c6301bc
bug 116315 - Cycle Case including Sentence case
Sentence case added at position #2 in the sequence
Comment 61 V Stuart Foote 2019-04-15 20:50:11 UTC
(In reply to Justin L from comment #60)
> Most of the duplicates here are complaints that Sentence case was added to
> the Shift-F3 sequence in LO 6.1 
> 
> author	heiko tietze 2018-03-26 14:58:23 +0200
> commit	84f8e28d092676aad830a9fbae8145a57c6301bc
> bug 116315 - Cycle Case including Sentence case
> Sentence case added at position #2 in the sequence

Well sure--it functioned as intended when only applied via menu action (now at Format -> Text -> Sentence case). As Mike reported in OP, it was annoying then that the transliteration did not honor a selection if made.

Addition to the Cycle Case sequence for bug 116315 brought it to a head.

Fundamentally the same issue--it does not honor Selection and expands to affect entire sentence run. 

And, sidebar have a sneaking feeling that it is not using the ICU libs to delimit sentence runs at correctly set bounds, kind expect CTL and CJK scripts are not well handled but I've not dug deeply at them.
Comment 62 Wolf 2019-07-16 03:00:07 UTC
In 
my Version: 6.2.4.2
Build-ID: 1:6.2.4-0ubuntu0.18.04.1~lo1

it is even more odd:

* put the cursor in one word - hit Shift-F3: case of that word cycles
* put the cursor in another word - hit Shift-F3: case of that word cycles, BUT AS WELL THE CASE OF THE WORD TOUCHED BEFORE

Please repair that function, it's really important!
Comment 63 V Stuart Foote 2019-09-08 05:32:35 UTC
*** Bug 127432 has been marked as a duplicate of this bug. ***
Comment 64 Xisco Faulí 2019-12-02 13:19:45 UTC
Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20
Comment 65 V Stuart Foote 2019-12-02 20:01:55 UTC
*** Bug 129144 has been marked as a duplicate of this bug. ***