Bug 167015 - RFE: writer: Behaviour of ctrl-b/u/i
Summary: RFE: writer: Behaviour of ctrl-b/u/i
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on: 88512
Blocks:
  Show dependency treegraph
 
Reported: 2025-06-14 11:46 UTC by Dave Gilbert
Modified: 2025-06-15 14:45 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
sample of CS and DF with requested format as CS (34.80 KB, application/vnd.oasis.opendocument.text)
2025-06-14 14:52 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Gilbert 2025-06-14 11:46:01 UTC
This user wants to frequently change bold/italic/underline but finds the current semantics don't quite fit for them.
It turns out MS Word has two different modes, and we match one of them, they'd like an option for the other (or possibly another way to do this)

(This is reported on behalf of PAgent who discussed it on the Fediverse:
    see: https://social.chinwag.org/@PAgent/114672187711335443
)

Imagine you want the result to be 'Alpha _*Bravo*_ Charlie' (where _*Bravo*_ means Bravo in bold and underlined)
a) Start with the text 'Alpha Charlie'
b) Move the cursor back to just before the 'C'
c) Hit ctrl-b ctrl-u  (This turns on bold and underline but makes no change to the current text)

d1) Type 'Bravo'
e1) Type ctrl-b ctrl-u - this turns off the bold/underline - but also removes it from the 'Bravo' you just typed

d2) Type 'Bravo ' (space at the end)
e2) Type ctrl-b ctrl-u - this turns off the bold/underline - but you're left with an underlined (and bold) space after 'Bravo'

so neither d1e1 or d2e2 give you the desired result.
Apparently this matches Words default setting.

But word has an option that when deselected makes ctrl-b/u/i strictly just toggles the current state off and never changes the word you're in; apparently this is File->options->advanced->'When selecting, automatically select entire word'.

I have a few suggestions:

1) Add a similar option
2) Add commands that can be bound to keys, e.g. toggle-bold - which strictly flips the option and doesn't try any change to the current content
3) Set up some default options for (2) - e.g. ctrl-shift-b ?
Comment 1 V Stuart Foote 2025-06-14 14:41:22 UTC
But we have to be mindful of what formatting we push out to ODF.

These can be done with Direct formatting DF (individual "T" styles), or by applying a defined Character style CS in line with the span.

Compare the Italic DF, to the Emphasis CS

Or, I've attached a silly text run with mixed CS and DF. CS first line, DF second.

Any DF can be customized to assign a shortcut, likewise Customize -> Keyboard -> Styles category chosing "Character" and from the CS selections listed under the Function label.

Since users can create modify CS of their own, assign to keyboard or menu/context menu of their choice--we already provide means to create and laydown text:style-name to ODF as either DF or CS. All within a single text span, with or without word bounds.

What more would be needed?
Comment 2 V Stuart Foote 2025-06-14 14:52:28 UTC
Created attachment 201276 [details]
sample of CS and DF with requested format as CS

mix of CS and DF, with requested word formatting applied as a custom CS (StrongEmphUnder)

Such a CS can then be user assigned to any keyboard, menu or tb button.
Comment 3 Dave Gilbert 2025-06-14 15:10:33 UTC
This isn't about representation - it's about what the user has to do to achieve it.
For me, assigning alt-e to style->Emphasis has exactly the same problem as the original

i.e.

a) Alpha Charlie
b) Move back to just before the C
c1) Type Alt-E to activate emphasis Style
d1) Type Bravo
e1) Type Alt-E again

  That Makes Charlie emphasised as well

or

d2) Type 'Bravo ' (space)
e2) Type Alt-E again - the space is emphasised

Sure, if you select the Bravo precisely afterwards and then select the style or formatting you're OK; but the user is saying they do a lot of word specific formatting so they want one key on/off for whatever they're doing, and so far we've not found a way to do it.
Comment 4 V Stuart Foote 2025-06-14 20:49:18 UTC
(In reply to Dave Gilbert from comment #3)
 
> Sure, if you select the Bravo precisely afterwards and then select the style
> or formatting you're OK; but the user is saying they do a lot of word
> specific formatting so they want one key on/off for whatever they're doing,
> and so far we've not found a way to do it.

Well that would be a one "button" click toggle to make an assignment.

And I'm saying that by use of Character styles we already provide sufficient granularity to assign keyboard accelerators to preferred and customized CS--including a 'No Character Style' to effectively toggle--by keyboard--to any desired CS or DF!

What do we gain by defining a bunch of additional button actions to shoehorn into the UI, or of overlaying additional actions onto existing buttons in the UI?

Seems more appropriate, with a simple support tail, to improve Help and documentation of how to effectively use the existing UI.

Just saying...
Comment 5 Dave Gilbert 2025-06-14 20:55:30 UTC
(In reply to V Stuart Foote from comment #4)
> (In reply to Dave Gilbert from comment #3)
>  
> > Sure, if you select the Bravo precisely afterwards and then select the style
> > or formatting you're OK; but the user is saying they do a lot of word
> > specific formatting so they want one key on/off for whatever they're doing,
> > and so far we've not found a way to do it.
> 
> Well that would be a one "button" click toggle to make an assignment.
> 
> And I'm saying that by use of Character styles we already provide sufficient
> granularity to assign keyboard accelerators to preferred and customized
> CS--including a 'No Character Style' to effectively toggle--by keyboard--to
> any desired CS or DF!

Can you explain this fully - as I said in the part of the message you've deleted, I couldn't get this to work.

> What do we gain by defining a bunch of additional button actions to shoehorn
> into the UI, or of overlaying additional actions onto existing buttons in
> the UI?
> 
> Seems more appropriate, with a simple support tail, to improve Help and
> documentation of how to effectively use the existing UI.

So far you've not shown it's possible in the current UI.
And if it's taking us this long to figure it out, it's going to be pretty hard on an end user.
 
> Just saying...

IMHO the use by the user makes perfect sense to me - wanting to insert an underlined word in your existing text makes a lot of sense - it doesn't seem esoteric; whatever their use case is they often do changes like this, so it makes sense for it to be easy.

As they say, MS word can already do this, so it's a loss of function for them.
Comment 6 V Stuart Foote 2025-06-14 21:27:06 UTC
(In reply to V Stuart Foote from comment #4)
> (In reply to Dave Gilbert from comment #3)

Guess specific changes in UNO will have to occur to change default behaviors when toggled as button actions.

And, don't want to get too far off track looking at the toolbars holding UNO button assignments specifically for CS. But enable the 'Formatting (Styles)' toolbar alternative to the 'Formatting' toolbar. Selection on the main menu View -> Toolbars.

They make use of .uno:StyleApply with string flags to control the button actions.

And the (Styles) tb already has button assignments to several of the CS UNO that behave as a simple toggle.  Think Maxim M. had gotten some of it worked out with Jay P. a while back but needed to be finished--bug 88512 seemed to have a lot left to do.
Comment 7 V Stuart Foote 2025-06-14 21:58:05 UTC
(In reply to Dave Gilbert from comment #5)
> 
> Can you explain this fully - as I said in the part of the message you've
> deleted, I couldn't get this to work.
> 

Simple really, use Tools -> Customize and assign some set of shortcuts to the Style -> Character functions. <Ctrl>+F 'No Character Style', <Ctrl>+H 'Strong Emphasis' and maybe <Ctrl>+K to 'Emphasis' (or create a new style from existing and edit it for font effect--size, color, etc. and assign it).

Now while typing, to change from no style (and current PS) to PS with a CS assigned use shortcut <Ctrl>+K, finish typing and <Ctrl>+F to drop CS. Continue typing, now <Ctrl>+H to enter a word or two--then <Ctrl>+F to drop CS. 

The UI for assigning shortcuts *is* a bit cumbersome, but the exact behavior desired is possible. Even if the current DF shortcuts/button actions don't.
Comment 8 Dave Gilbert 2025-06-14 22:42:43 UTC
(In reply to V Stuart Foote from comment #7)
> (In reply to Dave Gilbert from comment #5)
> > 
> > Can you explain this fully - as I said in the part of the message you've
> > deleted, I couldn't get this to work.
> > 
> 
> Simple really, use Tools -> Customize and assign some set of shortcuts to
> the Style -> Character functions. <Ctrl>+F 'No Character Style', <Ctrl>+H
> 'Strong Emphasis' and maybe <Ctrl>+K to 'Emphasis' (or create a new style
> from existing and edit it for font effect--size, color, etc. and assign it).
> 
> Now while typing, to change from no style (and current PS) to PS with a CS
> assigned use shortcut <Ctrl>+K, finish typing and <Ctrl>+F to drop CS.
> Continue typing, now <Ctrl>+H to enter a word or two--then <Ctrl>+F to drop
> CS. 
> 
> The UI for assigning shortcuts *is* a bit cumbersome, 

Yes, it's horrid!

> but the exact behavior
> desired is possible. Even if the current DF shortcuts/button actions don't.

No, suffers from the same original problem!
I bound Ctrl-H to style->character->Placeholder and
        Ctrl-F to style->character->no style

Following the original instructions, when I hit Ctrl-F it switches 'Bravo' back to no style, not just changing the current style, or similarly if I do 'Bravo ' the space is in the pretty style.
Note if you test it, it's important to type the original and then move back to before the C; it behaves differently if you try it just as you are typing a line for the first time.

> Guess specific changes in UNO will have to occur to change default behaviors when
> toggled as button actions.

I don't know Uno too know; but IMHO it makes sense to have simple commands (i.e. toggle or set style) that can be composed over clever ones (i.e. toggle and maybe change what you're editing)

Thanks for the pointer to the other bug.
Comment 9 V Stuart Foote 2025-06-15 14:27:35 UTC
(In reply to Dave Gilbert from comment #8)

> No, suffers from the same original problem!
> 
> I don't know Uno too know; but IMHO it makes sense to have simple commands
> (i.e. toggle or set style) that can be composed over clever ones (i.e.
> toggle and maybe change what you're editing)
> 

OK, you are correct. I Followed your steps more carefully ;-)

It would be helpful while modifying if--a text insertion with a change in DF/CS--would not affect DF/CS of adjacent words or their whitespace bounds. Just the current "word" text span being entered and not affect anything past its bounds to exclude its bounding whitespace.  Seems that would match the MS formatting mentioned?

The trouble occurs both with DF or CS being applied to *Modify* an existing text span. E.g. typing Alpha Charlie and reposition text cursor and insert Bravo with a DF/CS change. The word bounds (Spaces here) receive the DF or CS when it is toggled.

Different to handling while *Typing* the initial text spans which allow the DF/CS toggles between any characters of the span.

Likewise if making a selection, DF/CS is toggled up to the word bounds (double click) or sentence bounds (triple click) or paragraph extent (quad click). Where the DF/CS change occurs up to the selection bounds (but DF/CS then applies to the white space since they are no longer the breaks).

IIUC the logic is buried in the editshell(s) and we use ICU libs to define the break iterators. But the T/M distinction is used extensively, e.g. look at how the AutoCorrect Options are configured.
Comment 10 Dave Gilbert 2025-06-15 14:45:34 UTC
(In reply to V Stuart Foote from comment #9)
> (In reply to Dave Gilbert from comment #8)
> 
> > No, suffers from the same original problem!
> > 
> > I don't know Uno too know; but IMHO it makes sense to have simple commands
> > (i.e. toggle or set style) that can be composed over clever ones (i.e.
> > toggle and maybe change what you're editing)
> > 
> 
> OK, you are correct. I Followed your steps more carefully ;-)

Well at least we got there!

> It would be helpful while modifying if--a text insertion with a change in
> DF/CS--would not affect DF/CS of adjacent words or their whitespace bounds.
> Just the current "word" text span being entered and not affect anything past
> its bounds to exclude its bounding whitespace.  Seems that would match the
> MS formatting mentioned?

My understanding (although I don't have Word myself) is that our current behaviour
matches the default MS Word mode, so we can't change that since it would confuse
a bunch of users.  However, it's MS Word that has a switch they can change the behaviour.

> The trouble occurs both with DF or CS being applied to *Modify* an existing
> text span. E.g. typing Alpha Charlie and reposition text cursor and insert
> Bravo with a DF/CS change. The word bounds (Spaces here) receive the DF or
> CS when it is toggled.
> 
> Different to handling while *Typing* the initial text spans which allow the
> DF/CS toggles between any characters of the span.

Right.  IMHO this difference is damn confusing - I prefer keys to do the same
thing in any context; but hey we have to make the default match; but I can see why people
would want the simpler behaviour.
 
> Likewise if making a selection, DF/CS is toggled up to the word bounds
> (double click) or sentence bounds (triple click) or paragraph extent (quad
> click). Where the DF/CS change occurs up to the selection bounds (but DF/CS
> then applies to the white space since they are no longer the breaks).

I've not tried selections.
 
> IIUC the logic is buried in the editshell(s) and we use ICU libs to define
> the break iterators. But the T/M distinction is used extensively, e.g. look
> at how the AutoCorrect Options are configured.

I don't know that corner of the codebase.