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
|
Fri 05 May 2017 09:27:59 AM UTC, comment #8:
See also bug #50879.
|
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.
|
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.
|
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 ;-)
|
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.)
|
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.
|
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.)
|
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.
|
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.
|