carriage return when pasting from terminal

[marilmanen]

Is there some way to exclude \r characters before pasting text? If I copy lines from terminal the displayed text in nedit-ng window is

 % ls -d /home<cr>
/home<cr>

with old NEdit the pasted text is without the carriage return characters, so do you know what is causing this difference or if it can be changed in some way? Removing the carriage returns after paste is a simple search/replace, but it is a bit annoying.

[eteran]

Very interesting! I imagine this is a pretty easy fix. I'm kinda suprised that legacy nedit doesn't just take what you pasted and literally insert it, but I guess it must be normalizing chariage returns to the file format. We can do the same.

[unixwork]

I'm not aware of nedit removing \r from the clipboard. I tried the following:

Copy some text with \r\n to the clipboard:

printf "a\r\nb" | xclip -selection clipboard

Pasting to nedit-ng and nedit both results in a carriage return in the text.

[eteran]

@unixwork thanks for confirming. I was looking through classic nedit and xnedit sources and didn't see any "normalization" in there.

@marilmanen can you please confirm that classic nedit acts as you describe? That being said, I wouldn't be against a toggleable feature where it would normalize return characters upon pasting or something like that.

[marilmanen]

I tested

printf "a\r\nb" | xclip -selection clipboard

and I get the carriage return characters to both nedit windows.

But when I copy/paste from terminal window the result is different. Any idea what could be causing the difference and how to automatically get rid of the carriage return characters?

I think that changing carriage return new lines to plain new lines when pasting to a UNIX file could be worth considering at least an an optional feature.

[unixwork]

I was able to reproduce the problem with xfce4-terminal and I think I found the problem. When I copy text, there are multiple clipboard targets available, in my case:

TIMESTAMP TARGETS MULTIPLE SAVE_TARGETS UTF8_STRING COMPOUND_TEXT TEXT STRING text/plain;charset=utf-8 text/plain

Nedit uses the STRING target, in xnedit, I'm using UTF8_STRING and STRING as fallback. Qt seems to prefer the text/plain targets, and for some reason, the terminal uses \r\n as line ending for these targets.

[eteran]

Very interesting!

[eteran]

Myabe there's a way to make Qt favor the UTF-8 related targets. That being said, if the terminal has \r\n in the line endings... that's kinda wierd for a linux terminal to do and I wonder if it's the right thing to do to remove data that was actually in the paste buffer.

It gets questionable if you're editing a windows file on a linux system. I can definitely detect that copy buffer contains different style newlines from the file being edited and ask what to do... but I think that might ALSO be annoying, LOL

I'll need to investigate.

Thanks for looking into it @unixwork

[eteran]

@marilmanen @unixwork So it looks like the QMimeData (which is what I use to access clipboard data) supports fetching byte-arrays for specified mime-types.

I'll have to review the steps for replicating the problem and see if there are ways to use the information @unixwork provided above to see if I can try a few options and see what works best.