Description: Issue: For years on multiple applications, I keep trying to EDIT previously typed incorrect case, such as CAPS LOCK inadeptly left on/off or deciding a String would be better presented if it wasn't in ALL CAPS, by selecting all the text in question and then pressing the CAPS LOCK button on the keyboard. This clearly does nothing, but it feels like it should. Solution: LibreOffice subscribe to status of CAPS LOCK on systems that support (PCs must allow this for it to show as overlay of CAPS LOCK ON such as on my work PC) and when text is selected (highlighted) and then a change in the caps lock state is identifed invert Cap to lowercase and vice versa. Steps to Reproduce: type word with caps lock on Highlight word with SHIFT+Arrow (or mouse) press CAPSLOCK button on keyboard Actual Results: No reaction Expected Results: CHANGE text from "yOUR mOM" to "Your Mom" Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 12; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
We already provide ICU library transliteration based UNO toggle to upper case, to lower case, to capitalize every word, and to sentence case each with an accelerator, as well as a cyclic widget to apply the affect in sequence (Shift + F3). If you don't like the shortcut or accelerators assigned, use the Tools -> Customize and set a keyboard or context menu. The os/DE keyboard mapping of the <Caps Lock> key is not otherwise available to customize, and not clear making it so would be of benefit cross platform for the unmoderated <Caps Lock> key to toggle between .uno:ChangeCaseToUpper and .uno:ChangeCaseToLower IMHO => WF
(In reply to gt1wp6k1 from comment #0) > ...it feels like it should. I guess there are not too many users with the same idea of caps lock. It would be unfamiliar for almost every user, block the default interaction (toggling between upper/lower case input), and orthogonal to the inbuilt autocorrect functionality (at least two upper case characters on the beginning are corrected, if enabled). Stuart explained the supposed workflow, and I agree with the WF verdict (as always: feel free to reopen in order to gather more opinions). Thanks for reporting your idea. Please don't hesitate to keep on.