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: ASSIGNED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high normal
Assignee: Michael Warner
URL:
Whiteboard:
Keywords:
: 63889 119495 120039 120254 120872 121350 123977 124760 127432 129144 130331 130749 133427 134123 138346 138611 143296 143584 144856 (view as bug list)
Depends on:
Blocks: Character Selection CaseCycling
  Show dependency treegraph
 
Reported: 2012-04-21 01:53 UTC by Mike Kaganski
Modified: 2021-10-18 10:41 UTC (History)
32 users (show)

See Also:
Crash report or crash signature:


Attachments
concrete test cases (24.69 KB, application/vnd.oasis.opendocument.text)
2021-07-17 14:16 UTC, Michael Warner
Details
Changed per Comment 84 (18.37 KB, application/vnd.oasis.opendocument.text)
2021-08-27 14:38 UTC, Michael Warner
Details
Updated Test Set 4 (24.69 KB, application/vnd.oasis.opendocument.text)
2021-08-28 18:28 UTC, Michael Warner
Details
Test Set rev 5 (25.23 KB, application/vnd.oasis.opendocument.text)
2021-09-28 02:35 UTC, Michael Warner
Details

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 Comment hidden (obsolete)
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 2019-01-25 15:44:10 UTC Comment hidden (obsolete)
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 Comment hidden (off-topic)
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 Comment hidden (no-value)
Comment 36 Mike Kaganski 2019-01-30 06:59:11 UTC Comment hidden (off-topic)
Comment 37 Ljiljan 2019-01-30 07:04:09 UTC Comment hidden (no-value)
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. ***
Comment 66 Dieter 2020-02-01 06:57:25 UTC
*** Bug 130331 has been marked as a duplicate of this bug. ***
Comment 67 Dieter 2020-02-21 08:10:49 UTC
*** Bug 130749 has been marked as a duplicate of this bug. ***
Comment 68 Will 2020-04-30 14:37:19 UTC Comment hidden (no-value)
Comment 69 V Stuart Foote 2020-06-18 18:14:59 UTC
*** Bug 134123 has been marked as a duplicate of this bug. ***
Comment 70 pgborges 2020-06-18 19:01:35 UTC
Confirmed with:

LOdev 7.0.0.0.beta1
Build ID: 94f789cbb33335b4a511c319542c7bdc31ff3b3c
Manjaro Linux
CPU threads: 4; Kernel 5.6
UI render default; VCL: kf5
Locale: pt-BR (en_US.UTF-8); UI: en-US
Comment 71 Simon 2020-11-16 10:25:37 UTC
Fwiw and not wishing to add to the heat generated above, as a simple user of LibreOffice this is not expected behaviour: if I select a section of text and conduct an operation, I expect it to be restricted to the selection.  Please may I add my immense gratitude to all those who give their time and effort to make this such a superb piece of software.  Thank you.
Comment 72 V Stuart Foote 2020-11-19 20:12:57 UTC
*** Bug 138346 has been marked as a duplicate of this bug. ***
Comment 73 V Stuart Foote 2020-12-01 22:37:31 UTC
*** Bug 138611 has been marked as a duplicate of this bug. ***
Comment 74 Ming Hua 2020-12-01 22:45:59 UTC
*** Bug 133427 has been marked as a duplicate of this bug. ***
Comment 75 MK 2021-01-31 16:54:39 UTC
Fwiw and not wishing to add to the heat generated above, as a simple user of LibreOffice this is not expected behaviour: if I select a section of text and conduct an operation, I expect it to be restricted to the selection.  Please may I add my immense gratitude to all those who give their time and effort to make this such a superb piece of software.  Thank you.
Comment 76 Mihail Balabanov 2021-02-03 16:41:00 UTC
In version 7.2, the Cycle Case command is still largely unusable for the use cases that are important to me.

What can we, as users, do to help the developers fix it sooner?

- Is more user input needed for creating a new specification? Would it be helpful to provide some more use cases to help decide on the best approach that won't cause regressions for other users?

- Are the developers too few and/or too busy with more important stuff to tackle the issue for the time being? Can we agree on a quick, minimal temporary fix (like reverting the inclusion of Sentence Case in Cycle Case) and postpone any functionally better but time consuming refactor (like modifying Sentence Case or providing a separate Initial capital command, analogous to lowercase / UPPERCASE / Title Case, to replace Sentence Case in Cycle Case) for a better time?

- Is the issue currently considered unimportant? If yes, how can we verify objectively that the people complaining from it are representative for a larger group of users and not a random vocal minority as suggested several comments above?

***

As the commenters above, I would like to thank the developers for their tireless work on a wonderful project!
Comment 77 Heiko Tietze 2021-02-04 09:51:01 UTC
(In reply to Mihail Balabanov from comment #76)
> What can we, as users, do to help the developers fix it sooner?

Find a volunteer or get professional support. Changing the selection is not a simple task and at least beyond my skills.
Comment 78 Mihail Balabanov 2021-02-09 12:10:14 UTC
For the time being, I published my workaround solution as an extension. It is a LibreOffice Basic macro for Cycle Case which honors the selection, autoselects only a single word when there is no selection, uses the current case of the selected text for a starting point instead of a counter, and can cycle the case of word the user just typed (including when there is already a space between it and the cursor).

https://extensions.libreoffice.org/en/extensions/show/4036
Comment 79 V Stuart Foote 2021-07-11 14:09:14 UTC
*** Bug 143296 has been marked as a duplicate of this bug. ***
Comment 80 Michael Warner 2021-07-17 14:16:31 UTC
Created attachment 173648 [details]
concrete test cases

Since the discussion on this bug has been such a long winding road, I have attempted to boil down what I interpret as the consensus desired behavior into a set of concrete test cases (see attached). This incorporates the decisions in Comment 57.
Comment 81 Michael Warner 2021-07-17 14:17:20 UTC
As you can see in the SENTENCE_CASE tests, 7.2.0.1 will not only change the case of the first sentence (where the cursor or selection are) but also the P in the second sentence (where IMHO it shouldn't be changing anything at all). This may be another instance of what was observed in Comment 62.

In the case that there is no selection and the user presses Shift+F3, I personally like the idea of either doing nothing (as raised in Comment 51) or expanding the selection to show the specific characters that were considered in the operation, as raised in Comment 50 and Comment 58. The way it is now, it seems too likely that an action like SENTANCE_CASE would alter characters in my sentance that I wouldn't notice; for example, if the cursor is near the end of a long sentance, and I am looking at the cursor, but the command has altered the beginning of the sentance, where I wasn't watching. But I leave that idea out of the test cases for this bug as I don't want to expand the scope of this bug any further and that seems like an enhancement request suitable for another BZ item.
Comment 82 Michael Warner 2021-07-28 14:24:28 UTC
*** Bug 143584 has been marked as a duplicate of this bug. ***
Comment 83 V Stuart Foote 2021-08-27 04:28:29 UTC
Loss of selection is confusing folks into thinking bug 116315 is at fault.

Rather the issue is mishandling of target for the transliteration sequences. Addressing target for transliteration, both with and without a selection being made. Additional control logic is needed... 

@Michael W., great that you are poking at this, how are things progressing? Concur with your "concrete test casses" of attachment 173648 [details] implementing comment 51. That is with no selection, just text cursor position, target is only the current word bounds holding the text cursor. No expansion. That would be consistent and workable, especially as a triple mouse click now will select a sentence and quadruple click full paragraph.

And may need attention to handling at the ICU word bounds for sentence ends and punctuation.
Comment 84 Michael Warner 2021-08-27 14:33:30 UTC
(In reply to Michael Warner from comment #81)
> As you can see in the SENTENCE_CASE tests, 7.2.0.1 will not only change the
> case of the first sentence (where the cursor or selection are) but also the
> P in the second sentence (where IMHO it shouldn't be changing anything at
> all). This may be another instance of what was observed in Comment 62.

ICU does not detect the sentence break in this case. If I capitalize the T in Time, it works as expected. We could track this in another BZ item, but it's not our bug. I will modify the test cases for this bug to avoid that one.  


(In reply to V Stuart Foote from comment #83)
> @Michael W., great that you are poking at this, how are things progressing?

I have some local code modifications made but work is not complete yet. I know it's a slow pace but I am only a contributor.

> Concur with your "concrete test casses" of attachment 173648 [details]
> implementing comment 51. That is with no selection, just text cursor
> position, target is only the current word bounds holding the text cursor. No
> expansion. That would be consistent and workable, especially as a triple
> mouse click now will select a sentence and quadruple click full paragraph.

Actually what I put in test 1a is that it capitalizes the first letter of the current word, and down-cases the letters to the end of the sentence (you can see this happen on the S in Smith). But the downside to this approach is that letters that are down-cased when we apply the sentence case are not restored on the next press of Shift-F3, so from the user's perspective there is still an unintended side-effect there. 

Thinking about it some more, I agree with you that only changing the case of the current word when there is no selection is the best choice. It's consistent with the other actions. I will update Test 1a to reflect this.
Comment 85 Michael Warner 2021-08-27 14:38:14 UTC
Created attachment 174583 [details]
Changed per Comment 84

Now there's an inconsistency between tests 3a and 3b, in that the N in Jones is capitalized for sentence case, but remains lower for title case.
Comment 86 V Stuart Foote 2021-08-27 15:28:13 UTC
(In reply to Michael Warner from comment #84)
>This may be another instance of what was observed in Comment 62.
> 
> ICU does not detect the sentence break in this case. If I capitalize the T
> in Time, it works as expected. We could track this in another BZ item, but
> it's not our bug. I will modify the test cases for this bug to avoid that
> one.  
> 

No, believe we control the logic for the start/end of a sentence--pretty sure it is with ICU libs [1], but I've not followed it fully through the edit shell. But see here to start where we seem to use a DICTIONARY_WORD ICU break iterator to control expanding bounds for the sentence:

https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit4.cxx?a=true&r=492ea7e0&h=2785#2785

And, the SENTENCE_BREAK ICU iterator is available, but looks bit dated (and not to be used with the transliteration) as defined here:

https://opengrok.libreoffice.org/xref/core/i18npool/source/breakiterator/data/sent.txt?r=2b383d19

But if the no-selection case is only going to apply to the word with text cursor position--the ICU sentence bounding would not be helpful.

=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/i18npool/source/breakiterator/breakiterator_unicode.cxx
Comment 87 V Stuart Foote 2021-08-27 16:15:30 UTC
(In reply to V Stuart Foote from comment #86)

The ICU methods for "Break Rules" are described here:

https://unicode-org.github.io/icu/userguide/boundaryanalysis/break-rules.html

I get a sense now for why the DICTIONARY_WORD approach--it is needed for Thai, Lao, Khmer, Burmese, and Japanese--and with CLDR details is more precise for determining sentence breaks in general.

Again--key here is difference between transliteration done with a selection (which must honor the *initial* selection exactly as the transliteration cycles) and transliteration done without a selection.  

The without selection transliteration should be bounded on the ICU *word* holding the text cursor.

And if text cursor is on a space or punctuation--IMHO it is probably best to not perform a transliteration for that case.
Comment 88 elmau 2021-08-27 18:27:19 UTC Comment hidden (no-value)
Comment 89 Michael Warner 2021-08-28 18:28:04 UTC
Created attachment 174593 [details]
Updated Test Set 4

Fixed some errors in Test Set 4.
Comment 90 V Stuart Foote 2021-08-28 19:09:49 UTC
(In reply to Michael Warner from comment #89)
> Created attachment 174593 [details]
> Updated Test Set 4
> 
> Fixed some errors in Test Set 4.

That looks good! Any issue with no-selection and text cursor is not within a word? I.e. on a space or punctuation...

@Michael --if your local patches are producting those results perhaps push up to gerrit for additional review. Can wrap this up...
Comment 91 Michael Warner 2021-08-30 13:30:34 UTC
(In reply to V Stuart Foote from comment #90)
> (In reply to Michael Warner from comment #89)
> > Created attachment 174593 [details]
> > Updated Test Set 4
> > 
> > Fixed some errors in Test Set 4.
> 
> That looks good! Any issue with no-selection and text cursor is not within a
> word? I.e. on a space or punctuation...

I will add more test sets for this.

> @Michael --if your local patches are producting those results perhaps push
> up to gerrit for additional review. Can wrap this up...

This document I maintain by hand to ensure we have concurrence on what the behavior should be. My local build still fails a couple of test cases; I am continuing to work on it.
Comment 92 Michael Warner 2021-09-05 23:10:06 UTC
*** Bug 63889 has been marked as a duplicate of this bug. ***
Comment 93 Michael Warner 2021-09-11 20:18:24 UTC
https://gerrit.libreoffice.org/c/core/+/121966
Comment 94 Michael Warner 2021-09-28 02:35:08 UTC
Created attachment 175302 [details]
Test Set rev 5

Based on comments in code review, I changed the Proposed New State of Test #1a to revert back to the old behavior of operating on the entire current sentence when there is no active selection.
Comment 95 Michael Warner 2021-10-02 12:27:32 UTC
*** Bug 144856 has been marked as a duplicate of this bug. ***