Created attachment 133324 [details]
demonstrates both sets of steps

This behavior​ is the same in all LibO applications. Therefore I set component to LibreOffice, hardware to all and version to inherited from OOo because LibO 3.3.0 shows the same.

Tested with 5.3.1.2 and 3.3.0.

LibO uses the formatting of the space before the inserted character. I couldn't reproduce it without spaces.

Add keyword needsUXEval, maybe it's an intended behavior. But I also stumbled over this issue in Writer in the past.

I think it is a bug, because it leaves over an empty span element. If it was an intended behavior, the empty span element would have been removed.

Created attachment 133373 [details]
Screencast

I don't get the issue, see my screencast.

In general, we keep the style from the previous part for good reasons. Lets say want you enter a statement in bold, then you switch bold on first and enter the text later. If you do the same afterwards with a selection it makes of course no sense to keep bold active. The same is true for other style elements such as font color. Is that really different from other tools?

Your screencast does not contain the critical part. Mark the green G and enter a g.

Expected: You get a green g.
Currently: You get a red g.

Another hint (besides the empty <text:span> element), that this is really a bug: Do the same with RGB without spaces. Now you get a green g.

The same error is in Writer.

The behavior is different from MS Office and WordPad, SoftMaker and KingSoft Writer. Gnumeric gives a red g.

(In reply to Regina Henschel from comment #6)
> Your screencast does not contain the critical part. Mark the green G and
> enter a g.

Ah... on editing it takes the style from the character before. 

Make me *bold*.
Make me *b * (continuation the style is not questionable)
Make *me* bold. (entering text after the e keeps the bold style)
Make *me *bold. (entering text before the b keeps the bold style)
Make *me* bold. (entering text before the b has no bold style)

Doing the same with colors it works similarly:

RedR RGreenG GBlue
(Font color set to red/green/blue until the next word, ie. including the character. R=Entered text is red, G=Green.)

Same is true for LibO and Office2010

This has another manifestation - simply changing the font (or format) affects characters not even selected - see new attachment107857.ods.

1. insert blinking cursor between "I" and "N" in cell B3 (don't select any characters, just put the cursor in that position)
2. set the font to Symbol, planning to type the U+2665 necessary to get the heart

result: see D3 – simply change the font without typing anything automatically changes the font for the existing characters!

to reproduce without the ods file:

1. set the font to arial
2. type two characters
3. position the cursor between the characters
4. change font to symbol
5. the whole cell changes to symbol on its own (the user desires to type new characters in symbol font

Created attachment 133410 [details]
steps for alternate aspect of bug described in comment

If you have a whitespace between the characters you can change the font being entered. The same is true for selections.

But anyway, I believe there are good reasons to keep the formatting as it is. The continuation of formatting until a whitespace character is more convenient as the rare cases when properties are changed arbitrarily. Of course, I might be wrong.

Heiko: I see it different. Perhaps the problem is clearer, if I describe it with markup, although that is not the internal representation:

The text has the form
<text:p text:style-name="Standard"><text:span text:style-name="myRed">R </text:span><text:span text:style-name="myGreen">G </text:span><text:span text:style-name="myBlue">B </text:span></text:p>

Now I select the G and press key g.

Expected: G has been replaced with g
<text:p text:style-name="Standard"><text:span text:style-name="myRed">R </text:span><text:span text:style-name="myGreen">g </text:span><text:span text:style-name="myBlue">B </text:span></text:p>

But I get
<text:p text:style-name="Standard"><text:span text:style-name="myRed">R g</text:span><text:span text:style-name="myGreen"> </text:span><text:span text:style-name="myBlue">B </text:span></text:p>

It seems, that LO does a "delete" followed by an "insert" instead of a true "replace". For an "insert" it is the correct behavior to continue the style of the previous character, but here a "replace" is intended and the undo names it "Replace". To get what you want, you have to insert the g after the G and then go back and delete the G.

(In reply to Regina Henschel from comment #11)
> Heiko: I see it different. Perhaps the problem is clearer, if I describe it
> with markup, although that is not the internal representation:
> ...

If we talk about overriding a character only, as you describe very clearly, with the intention to keep and harmonize the current workflow I have no concerns. But when it's about how insert/edit works, we should make sure to not harm any other use case.

So actually this is not a UX question but an ordinary bug. Removing the keyword.

(In reply to Heiko Tietze from comment #10)

> Of course, I might be wrong.

As someone who has been using this small portion (formatting) of the program 8 to 12 hours a day, seven days a week, abd using it only to create graphics (no math functions), I hope I can convince you that you are indeed quite wrong. There's no substitute for the understanding gained from spending hundreds of hours trying to make a super complex spreadsheet look right, and there's no substitute for the experience gained from being forced to keep proofreading the content of the spreadsheet and having to re-enter cells to correct the data or format. It's down here in the trenches that the faulty logic of the program makes itself so painfully apparent.

I'm making an elaborate representation of all of the songs of The Beatles - well over 200 - and each one has many complex sections. Each time I get to a new section or a new song I use similar functions of Calc. I'm only using less than 1% of the code you've written but I'm using that 1% in every possible way - if I can find a more convenient way to do any single operation it will save me hours in the long run because of the repetitive nature of what I'm doing. I've tried many different workflows.

I've tried this in Excel and Calc. Calc - on balance - has less problems and that's why I'm taking the time to try to convince you to fix it. Trust me - it needs fixing very badly. The way you've got it coded now is enough to make the user rip his or her hair out in large bunches. The user needs to be able to act on a selection without the program changing something that's not selected. I can't say it enough - it's not enough to code the program - you have to USE the program to see why your users are so frustrated.

(In reply to Regina Henschel from comment #11)

> It seems, that LO does a "delete" followed by an "insert" instead of a true
> "replace". 

YES! When you select something, what you type should "replace" the text and retain the format. That's how users understand computers:

1. select something to the computer what you want to apply a command to

2. apply the command - it changes the selection

But the way Calc is coded, when you apply the command, it goes to an unselected part of the document and changes that!!!! 
How can that possibly not be a bug? How can you trust and become intuitive about a program that keeps changing things you didn't ask it to change?

I admit that I do not know how to write a line of code, but I was a full-time professional software tester for 15 years and the bugginess this behavior is supported by every instinct I learned during that time, in addition to the thousands of hours I've spent as a user of this type of program.

Here's another way that this problem manifests itself, including a bizarre mystery I can't solve. In the attached .ODS file (10857-b.ods) there are steps and two cells that LOOK completely identical but the buggy behavior only occurs in one of them.

Created attachment 133428 [details]
This goes with the comment that references 10857-b.ods (steps in spreadsheet)

Created attachment 133429 [details]
steps for the comment referencing 10857-c.ods

The new attachment, 10857-c.odsm demonstrates (and includes steps and notes for) another buggy behavior that I believe shares the same root cause. I could give you 50 or 100 different sets of steps, each producing another result that appears to be a separate bug, but I'm pretty sure they all stem from the same code behavior that you guys are discussing - this thing about "not doing a true replace", but as you can see, it goes well beyond just "unexpected UI behavior" - it can cause behavior that is unequivocally buggy (i.e., the same steps produce different results in seemingly identical situations), as opposed to simply being different from Excel but consistently different.

I don't use Writer, but I tried the original steps and it did indeed occur in that program (but not in Word or Excel or any other non-Office program).

I believe everything is clear now and the bug can be fixed: instead of delete+insert the override function has to work as a true replace. More comments would add confusion only.

(In reply to Kevin from comment #13)
> I'm making an elaborate representation of all of the songs of The Beatles -
> well over 200 - and each one has many complex sections.

Hope you will share the result with the community so that everyone can get an impression of the power of Calc :-). 
The design team has a nice blog for that purpose, in case you don't know how to do it.

Created attachment 134204 [details]
absolute simplest case

Reading some of the comments on other reports I'm starting to see that Calc differentiates between formatting set from within the cell versus to the cell itself. This attachment demonstrates the bug completely within a fresh cell - absolutely no complications.

*** Bug 112056 has been marked as a duplicate of this bug. ***

I agree that it is wrong behavior.

If you do the same text without spaces, so RGB, the selected G will be replaced with a green g.

(In reply to QA Administrators from comment #22)

Still unchanged in LODev7.0

*** Bug 108333 has been marked as a duplicate of this bug. ***

To reproduce in Writer:
1. Open a new empty document.
2. [A] [ ] [Ctrl [B]] [B] [Home] [Shift [→] [→]] [C]

Result: Bold "cb".

I can still reproduce in Calc using:

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: e37dcb3ca36bb6c23b15757e6e556ad25832398c
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded