Bug 474086

Summary:	Add a way to force plain text paste
Product:	[Applications] okteta	Reporter:	J. T. Elscott <merry.pen9079>
Component:	general	Assignee:	Friedrich W. H. Kossebau <kossebau>
Status:	CONFIRMED ---
Severity:	wishlist
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=398638
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description J. T. Elscott 2023-09-03 10:36:26 UTC

N.b. this was created per the developer's request at https://invent.kde.org/utilities/okteta/-/merge_requests/19

I have used Okteta to, for instance, write little synthetic HTTP requests to test a program. For headers, it can be convenient to copy and paste them from references on the Web, but when I do this in Okteta it includes the HTML formatting from the page. For instance if I copy (what appears to my human eyes as) "Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5" from https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding , and paste it into Okteta, I instead get pasted in Okteta:

<meta http-equiv="content-type" content="text/html; charset=utf-8"><pre class="brush: http notranslate" data-signature="F3kb6sFqFVY+FfwSVKQyyDwYdjRNT74vno0W0W7N5NE="><code><span class="token header"><span class="token header-name keyword">Accept-Encoding</span><span class="token punctuation">:</span> <span class="token header-value">deflate, gzip;q=1.0, *;q=0.5</span></span></code></pre>

which necessitates the use of a text editor as an intermediary.

I don't have much of a preference for how this would be handled to bypass this extra step, and to allow explicit selection of formats. Either a mandatory "paste as" (like, I believe, Libreoffice has) dialog upon ctrl-v, or alternatives in the edit menu, or something else would work for me.

Comment 1 J. T. Elscott 2023-09-03 14:44:56 UTC

Correction, Libreoffice gives options for type on ctrl+shift+v.

Comment 2 Friedrich W. H. Kossebau 2025-08-09 21:37:32 UTC

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.