No repro with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 7a7eb4aa21ca0c83db825fe8d5a5278611b391d8
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded

Is your version LO 3.3 or did you tried it in actual version too?

Changed the release that this affects to indicate all releases in which I have personally experienced this behavior and remember doing so.

I see something different.
Using the following steps:
1. write "normal"
2. Ctrl + Shift + P
3. write "super"

On the undo stack there is (most recent at the top):
- Typing "super"
- Apply attributes
- Typing "normal"

I see two different behaviours depending on the next action:
(a) Ctrl + Z removes the superscript string, and continuing writing uses non-superscript characters *even though "Apply attributes" is still on top of the stack*
(b) Backspace until all superscript characters are gone, then continuing writing still uses superscript character

This not exclusive to superscripts, it is consistent with other formatting options (I tested bold, italic, font colour), but I feel like the two actions (Ctrl + Z vs backspace) are equivalent and should therefore have the same impact.
(a) seems particularly odd to me, in that "Apply attributes" is still in the history but new characters don't use the formatting. (I am aware this is the behaviour Coburn would prefer though.)

UX/UI team, what do you think?

Coburn, do you see something different following my steps? Please also share the info from Help > About LibreOffice.
I tested with this version:

Version: 7.5.1.2 (X86_64) / LibreOffice Community
Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: ru-RU (en_AU.UTF-8); UI: en-US
Calc: threaded

Same results in 7.0.6.2

We continue text with the formatting before. It is a convenience function that you "switch the state" to superscript or to bold allowing to type ahead. In fact you apply the formatting to the selection and continue the formatting before.

This corner case with undo is somewhat tricky. We definitely want to keep undo when it is applied to a selection but I could imagine to not keep it in the undo stack if done without any selection. Mike, what do you think?

(In reply to Stéphane Guillou (stragu) from comment #3)
> On the undo stack there is (most recent at the top):
> - Typing "super"
> - Apply attributes
> - Typing "normal"
> 
> (a) Ctrl + Z removes the superscript string, and continuing writing uses
> non-superscript characters *even though "Apply attributes" is still on top
> of the stack*

(In reply to Heiko Tietze from comment #4)
> This corner case with undo is somewhat tricky. We definitely want to keep
> undo when it is applied to a selection but I could imagine to not keep it in
> the undo stack if done without any selection. Mike, what do you think?

Try this:

1. Type "normal"
2. Ctrl+Shift+P
3. Ctrl+Z

What is your expectation here?

Personally I believe that the bug is in comment 3, (a), that the first undo must keep the cursor inside the empty text run with modified properties created on the previous step, and the first undo there must not join the adjacent text runs with the same "normal" formatting.

(In reply to Mike Kaganski from comment #5)
> 1. Type "normal"
> 2. Ctrl+Shift+P
> 3. Ctrl+Z
> 
> What is your expectation here?

My proposal was to make it depending on whether something was selected.

> Personally I believe that the bug is in comment 3, (a), that the first undo
> must keep the cursor inside the empty text run with modified properties
> created on the previous step, and the first undo there must not join the
> adjacent text runs with the same "normal" formatting.

We can do this too. Would be more consistent and easier to understand but more challenging for the implementation, I guess.

(In reply to Heiko Tietze from comment #6)
> My proposal was to make it depending on whether something was selected.

And my question was what was *your* expectation when you did *the exact steps that I suggested*. And you didn't answer ;)

(In reply to Mike Kaganski from comment #7)
> And my question was what was *your* expectation when you did *the exact
> steps that I suggested*. And you didn't answer ;)

Because my proposal was straight-forward, or not? Any DF is not taken into the Undo stack if there is no selection. So Ctrl+Shift+P wouldn't be in the list and undo applies to #1.

(In reply to Heiko Tietze from comment #8)
> Ctrl+Shift+P wouldn't be in the list and undo applies to #1.

Then it would be impossible to simply change one's mind and *undo* the direct formatting application. Consider this sequence:

1. Type "normal".
2. Ctrl+Shift+P
3. Change your mind, and decide that you don't need the superscript.

Your options now are one of:

* Ctrl+Shift+P - this will *apply another DF*, explicitly setting "no superscript", where originally no DF was present;
* Move cursor outside of your position, then back.

The latter would work, unless you are at the empty paragraph: in this case, your action would change the paragraph properties. Would then this action require an undo action? And if yes, how would an average user see the difference, when it works, and when it doesn't?

The Ctrl+Z is natural when a user wants to undo the last action. Unless there is a *very* good reason to do otherwise, I think that we should allow undoing even such "empty" actions.

My request is just that the various undo methods would work consistently. I would like to be able to get out of superscript mode using the keyboard. To be honest, I am not a "shortcuts" person, although I have been using a few shortcuts since about 1985. And so when I see "Ctrl-Shift-P" in the comments, that is a good workaround. However, if I undo a superscript using backspace or Ctrl-Z, and it disappears, I should not still be in superscript mode.

Thanks

Already in 3.5.