bugGNU nano - Bugs: bug #49176, pasted text loses some...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #49176: pasted text loses some "\n" and "#" on some terminals

Submitter:  None
Submitted:  Sat 24 Sep 2016 05:35:44 PM UTC
   
 
Severity:  3 - Normal Status:  Works For Me
Assigned to:  bens Open/Closed:  Closed

Jump to the original submission

Fri 05 May 2017 09:35:18 AM UTC, comment #9: 

Oh, forgot to add: to work around your problem (the paste containing \n instead of \r), you could put this in your nanorc:

  bind ^J enter main

Benno Schulenberg <bens>
Group administrator
Fri 05 May 2017 09:27:59 AM UTC, comment #8: 

See also bug #50879.

Benno Schulenberg <bens>
Group administrator
Wed 11 Jan 2017 11:15:47 AM UTC, comment #7: 

A solution to the problem would to implement 'bracketed paste mode' (see the request in bug #40060).  When we know something is a paste and does not come from the keyboard, we could interpret a ^J as a newline instead of Justify command.

Benno Schulenberg <bens>
Group administrator
Thu 29 Sep 2016 07:03:53 PM UTC, comment #6: 

Pressing the Enter key sends the byte "\r" (^M) to the editor, not the byte "\n" (^J).  However, it would indeed have been smarter if nano had interpreted a ^J as equivalent to ^M (as vim and others appear to do, to accomodate silly programs that paste a text as if it were a DOS file), but Pico has chosen to use ^J for Justify, and nano follows Pico... so... my hands are tied there.

Benno Schulenberg <bens>
Group administrator
Mon 26 Sep 2016 05:40:12 PM UTC, comment #5: 

Thanks a lot for your answer. With "bind ^J curpos main", it's at least possible to paste text without losing characters.

I did some more research, and nano is not the only editor with this behavior.

In my setup, paste works with:
- vim
- bash / cat
- mg
- mcedit
- sandy

It does not work however with:
- nano
- joe
- diakonos
- dit

They are all eating the newline character.

I cannot image how this is possible tbh. Imho pressing the enter button and pasting "\n" should both result in the byte "\n" being send to the editor, which should interpret it also as newline. Even with UTF-8, most ASCII characters did not change their value.

Anyway, it seems to be not a bug of nano, so I can close this issue. Sorry for that.

Seems I have to introduce my student into VIM at the beginning of the lecture ;-)

Tony meman <nobody123>
Sun 25 Sep 2016 05:19:23 PM UTC, comment #4: 

To disable the annoying ^J behavior, you could add "unbind ^J all" to your .nanorc file.  But that would cause a whole series of "Unbound key" warnings when pasting a piece of text.  A passable way to avoid this is to instead add "bind ^J curpos main" to your .nanorc.  Then each paste that ends with a linebreak will also show the current cursor position on the statusbar.  But that would seem like a small price to pay for regaining correct pastes.

(Adding a bindable function to nano that does absolutely nothing would be an improvement.  Then you could do "bind ^J nothing main" and a ^J would be entirely silent and effectless.)

Benno Schulenberg <bens>
Group administrator
Sun 25 Sep 2016 11:41:18 AM UTC, comment #3: 

"If you make your selection carefully so as to end with a linebreak, you should be able to see the message "Can now Unjustify" on the statusbar after the paste. "
Indeed, it is like this.

If i start with 'nano -Q ""', or compile it with "--disable-justify", the "#" do not disappear, but newlines still get eaten, and it inserts a newline at an awkward position:
---
#include <stdio.h> #include <stdlib.h> #include <crypt.h> #include
<string.h>
---

Is it possible to disable this behavior?

Also, using "--ignore" does not change anything.


Tony meman <nobody123>
Sun 25 Sep 2016 09:03:23 AM UTC, comment #2: 

To make sure I understand correctly: if you paste those four lines, the last "\n#" is preserved?  And if you paste five lines (that is: an additional blank line), also the fourth "\n#" combo is eaten?

But then, if you do this five-line paste in a narrower terminal, then the fourth "\n#" is preserved?  Or does the fourth "\n#" reappear when you make the terminal narrower after the paste?

Is there any way you could make your setup simpler?  Does pasting in a normal xterm work okay?  Try to use 'nano --ignore' during your testing (or rename your nanorc files so they won't be read), to exclude the possiblity of some setting interfering.

What seems to be happening is that when you select text, a linebreak (0x0A) does not get converted to a ^M but stays a ^J -- and the latter means: Justify, which means: rearrange consecutive lines to form a dense paragraph.  It means that # (and other quoting characters) will only occur at the start of lines.  If you make your selection carefully so as to end with a linebreak, you should be able to see the message "Can now Unjustify" on the statusbar after the paste.

(When I select with the mouse only a linebreak, and then in a terminal type ^V and then paste the break with a midclick, I see ^M.  You will see a ^J, I guess -- which is somehow a bug in your selection mechanism.)

Benno Schulenberg <bens>
Group administrator
Sat 24 Sep 2016 06:00:43 PM UTC, comment #1: 

OP here: Someone with smarTTY has the same problem: https://sysprogs.com/w/forums/topic/smartty-paste-problem-linebreaks-deleted/

Nano 2.7.0 has the same issue.

Tony meman <nobody123>
Sat 24 Sep 2016 05:35:44 PM UTC, original submission:  

When I paste C source code into nano, it will sometimes eat "\n#", or "#", or "\n"

source:
---
#include <stdio.h>
#include <stdlib.h>
#include <crypt.h>
#include <string.h>
---

Result when I paste it into nano:
---
#include <stdio.h> include <stdlib.h> include <crypt.h>                                          
#include <string.h>
---

If i paste more lines from the original source, the last "#" also gets eaten:
---
#include <stdio.h> include <stdlib.h> include <crypt.h> include <string.h>
---

If i make the window small (like 80 chars wide), it appears like this:
---

#include <stdio.h> include <stdlib.h> include <crypt.h>                   
#include <string.h> 
---

Note that i have quite a special setup:
I serve a Ubuntu 16.04 LXD container via websockets to xterm.js javascript terminal, see screenshot.

I much appreciate it if someone has some hints why this effect appears. Accounts to reproduce can be provided upon request.

Note that it works correctly with vim.


Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #38593:  nano-err.PNG added by None (32KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by nobody123 (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-05-05 bens Assigned toNone bens
        Open/ClosedOpen Closed
    2017-01-11 bens Summarypasted text sometimes loses &quot;\n&quot; and &quot;#&quot; pasted text loses some "\n" and "#" on some terminals
    2016-09-29 bens StatusNone Works For Me
    2016-09-25 bens SummaryPaste text eats &quot;\n&quot; and &quot;#&quot; pasted text sometimes loses "\n" and "#"
    2016-09-24 None Attached File- Added nano-err.PNG, #38593

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code