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 ?
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?
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.
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.
(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...
(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.
(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.
(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.
(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.
(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.
(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.
TLDR; DF/CS (direct formatting/character style) toggle the attributes on/off. If you type "Lorem" plus ctrl+B the next characters will have a bold font weight until you press ctrl+B again. This is the requested behavior. Meaning: I cannot follow the description.
(In reply to Heiko Tietze from comment #11) > TLDR; > > DF/CS (direct formatting/character style) toggle the attributes on/off. If > you type "Lorem" plus ctrl+B the next characters will have a bold font > weight until you press ctrl+B again. This is the requested behavior. > Meaning: I cannot follow the description. OK, lets go back to the start; say you have the text: Alpha Charlie and you want to change that into: Alpha Bravo Charlie But you want the Bravo to be in underline - how would you do that? The previous discussion came to the conclusion is we currently have no keybindings that enable you to do that (without having a dummy underscored space)
(In reply to Dave Gilbert from comment #12) > Alpha Charlie => Alpha Bravo Charlie Personally I would add Bravo, mark it, and make it bold. But you can go back to C (IOW, press alt+right after typing Alpha Charlie), toggle bold (ctrl+B), type Bravo and a space. What I mean: the formatting never "bleeds" into the word for me. > The previous discussion came to the conclusion is we currently have no > keybindings that enable you to do that (without having a dummy underscored > space) If the missing keybinding is "Emphasis" (.uno:EmphasisCharStyle), which is indeed not available for customization, I agree. The actual command is .uno:StyleApply with the parameter ?Style:string=Emphasis (and some other).
(In reply to Heiko Tietze from comment #13) > (In reply to Dave Gilbert from comment #12) > > Alpha Charlie => Alpha Bravo Charlie > Personally I would add Bravo, mark it, and make it bold. But you can go back > to C (IOW, press alt+right after typing Alpha Charlie), toggle bold > (ctrl+B), type Bravo and a space. What I mean: the formatting never "bleeds" > into the word for me. The typing 'Bravo and a space' doesn't work - that makes the 'space' have the new formatting; which for bold isn't noticeable, but if you do underline you'll see you get an underlined space after the 'Bravo' and *that* is the problem we're trying to fix. Marking would probably work; but the reporter said that in what they do, they have to do this a lot, so marking is a bit painful. > > The previous discussion came to the conclusion is we currently have no > > keybindings that enable you to do that (without having a dummy underscored > > space) > If the missing keybinding is "Emphasis" (.uno:EmphasisCharStyle), which is > indeed not available for customization, I agree. The actual command is > .uno:StyleApply with the parameter ?Style:string=Emphasis (and some other). I don't think that's it.
(In reply to Dave Gilbert from comment #14) > The typing 'Bravo and a space' doesn't work... Type Alpha Charlie, press alt+right (cursor is now before the C), press ctrl+U (toggles Underline on), type Bravo, press ctrl+U (toggles Underline off), and enter the space without formatting. My point is that DF functions are toggles. And we continue a formatting intentionally.
(In reply to Heiko Tietze from comment #15) > (In reply to Dave Gilbert from comment #14) > > The typing 'Bravo and a space' doesn't work... > > Type Alpha Charlie, press alt+right (cursor is now before the C), press > ctrl+U (toggles Underline on), type Bravo, press ctrl+U (toggles Underline > off), and enter the space without formatting. Nope, doesn't work either; when you press the ctrl+U the second time to turn it off, it removes the formatting from the Bravo you just typed. (Here I used ctrl-left to move back from the end of Charlie to the beginning of Charlie - I assume that's what you meant not alt+right???) This is what I had in d1/e1 in my report. > My point is that DF functions are toggles. And we continue a formatting > intentionally. Yeh I'm fine with them being toggles; that's great.
(In reply to Dave Gilbert from comment #16) > Nope, doesn't work either... Hm, I was pretty sure yesterday it worked this way (tested on macOS) but I see the issue now on Linux (and macOS too for some reason). At _Bravo_|Charlie (pipe indicates the cursor position) the formatting for the whole word is toggled. Obviously some users expect the function to detect the word boundaries, meaning you don't need to select the word before DF'ing "BravoCharlie". Your issue contradicts this convenience feature. And me tends to value the current workflow higher. Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 92b0f88a1f6eca12f4b5df280ba60e6153bf6520 CPU threads: 8; OS: macOS 26.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_DE.UTF-8); UI: en-US Calc: threaded
(In reply to Heiko Tietze from comment #17) > (In reply to Dave Gilbert from comment #16) > > Nope, doesn't work either... > Hm, I was pretty sure yesterday it worked this way (tested on macOS) but I > see the issue now on Linux (and macOS too for some reason). At > _Bravo_|Charlie (pipe indicates the cursor position) the formatting for the > whole word is toggled. > > Obviously some users expect the function to detect the word boundaries, > meaning you don't need to select the word before DF'ing "BravoCharlie". Your > issue contradicts this convenience feature. And me tends to value the > current workflow higher. Right, now if you see the original report, MS Word includes an option switch which lets you choose which behaviour you want; and our current behaviour matches the default setting; the user would like the same option because for their work they prefer the other behaviour. So if you see the suggestions I put at the end of my original report, I suggested that we either provide the same option that Word has, or we instead have an explicit command to do it; e.g. a toggle-bold-immediately that doesn't do the clever word boundary detection etc. This is quite interesting, in that both V.S.F and yourself both thought this was obvious but the actual behaviour we implement is much more subtle! Some people just want the obvious behaviour. Dave > > Version: 26.8.0.0.alpha0+ (X86_64) > Build ID: 92b0f88a1f6eca12f4b5df280ba60e6153bf6520 > CPU threads: 8; OS: macOS 26.1; UI render: Skia/Metal; VCL: osx > Locale: en-US (en_DE.UTF-8); UI: en-US > Calc: threaded
The option in MS Word is Advanced > When selecting, automatically select entire word "Select this option to select entire words when you select part of one word and then part of the next word. Turning this option on also causes Outlook to select a word and the space that follows it when you double-click a word." https://support.microsoft.com/en-us/office/editor-options-advanced-0b2b5644-41e2-42c4-990b-60ca36615600 If I start the selection before the last character of Alpha and continue right-wards to Bravo, the entire Alpha is automatically selected if this checkbox is on (the default). But formatting like ctrl+B or U is also applied to the entire word only if this checkbox is on. And consequently I can use ctrl+U as true toggle. We should not introduce the option in the sense of a selection. But I can imagine something like "[x] Formatting expands to word boundaries". (Thanks for patiently explaining the request.)
Thanks!