https://bugs.kde.org/show_bug.cgi?id=474086
--- Comment #2 from Friedrich W. H. Kossebau <[email protected]> --- Small update: Since 0.26.23 (released Aug 8th 2025) there is a change which does not yet fix the bug, but might serve more of the real world use cases like the one reported here: on a paste (or drop) the clipboard/drag content will be first checked if there is a plain text variant, if so, if it can be, depending on cursor focus, decoded using current byte value type or current 8-bit charset (supporting "\" escaping for non-printable bytes) and in that case then use bytes from the decoding, otherwise fall back to using as before raw data, either of some explicit application/octet-stream variant or the first available data variant. More, when dropping data to create some new byte array (on empty pane or next to tabs), again there will be a check for plain text and if it can be, with higher priority be decoded as hex values, or otherwise be decoded as (escaped) iso-8869-1 chars, only then again as before taking as raw data. So opening the mentioned web site, selecting the mentioned text and either dragging or copying via the clipboard into an existing byte array in Okteta, when the cursor is on the character side, will only insert the given text (as all text chars match the charset). Or drag the text onto the empty pane or the tabs will generate a new byte array, where the bytes will match the text as encoded in iso-8869-1. Allowing the user to chose what to use is still to-do, for now the above heuristic is hard-coded, so leaving the bug open. -- You are receiving this mail because: You are watching all bug changes.
