Description: When the compose key is activated in order to produce special characters, an underlined middle dot character (·) and a blank space next to it are shown. In LibreOffice Writer, if the compose key is invoked at the end of a line with other lines below it, after the key sequence is entered the cursor just ends up on the next line and the · remains, while the character the user tried to enter does not appear. Steps to Reproduce: 1. Open LibreOffice Writer 2. Hit Enter a few times to create some lines 3. Click on any line besides the last one 4. Invoke the compose key to make a special character Actual Results: A · will appear and stay there, while the cursor moves down to the next line. Expected Results: The special character the user wanted to make using the compose key should appear. Reproducible: Always User Profile Reset: Yes Additional Info: If the compose key is invoked at the end of the final line of a document or the middle of a line, the character still does appear properly: it's at the end of a line when there are more below where the problem always occurs. This makes editing very frustrating. This seems to be a Writer-only bug: Calc (in a cell), Impress, and Draw at least all properly make the desired character when the compose key invoked at the end of a line with others below it. This also does not affect any non-LibreOffice application that I can find, such as other text editors. LibreOffice Version: 7.2.5.2 / LibreOffice Community Build ID: 20(Build:2) CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.2.5-0ubuntu0.21.10.1 Calc: threaded OS: Kubuntu 21.10 KDE Plasma Version: 5.22.5
Created attachment 178526 [details] LibreOffice compose key attempt The compose key was invoked on the third line to make an "é"; instead the dot remains and the cursor moved down a line.
Not clear misbehavior of "Dead keys", or <AltGr> composition including some notional "compose key" depending os/DE implementation is OUR BUG. Cross platform we provide the very functional <Alt>+X direct conversion of Unicode (for bug 73691); as well as the chart based character picker in LibreOffice's Special Character dialog, where a split-key pick list provides "favorites" and "recents" for efficient input. Likewise we don't support native macOS "PressAndHold" (see also bug 42437) nor any of the many os/DE extensions supporting special character input. I'd throw any mishandling of an os/DE "Compose key" into the same pot with the <AltGr> mishandling of special character composition on Windows.
I think you are correct: on further testing I now don't believe it is a LibreOffice bug, but something involving KDE since on older versions there the newest versions of LibreOffice work fine. For the record, the Linux compose key has worked just fine in LibreOffice since its inception (and on OpenOffice before it). Much easier and quicker than needing to select a character using a graphical interface or an obscure alt keycode string, especially useful for us who need to write in more than one language.