Kitty: Newlines not pasted correctly in Nano

[serebit]

With the latest version of kitty and nano 2.9.8, 3.0, and 3.1, the following text:

name       : nano
version    : 2.9.8
release    : 102
source     :
    - https://www.nano-editor.org/dist/v2.9/nano-2.9.8.tar.xz :
c2deac31ba4d3fd27a42fafcc47ccf499296cc69a422bbecab63f2933ea85488
license    : GPL-3.0-or-later

is interpreted as the following when pasting into nano within kitty:

name : nano version : 2.9.8 release : 102 source : - https://www.nano-editor.org/dist/v2.9/nano-2.9.8.tar.xz :
c2deac31ba4d3fd27a42fafcc47ccf499296cc69a422bbecab63f2933ea85488
license    : GPL-3.0-or-later

gnome-terminal pastes this text correctly, newlines and all. When pasting into kitty outside of nano, the newlines are parsed correctly.

[kovidgoyal]

As far as I can tell, this is really a bug in nano http://savannah.gnu.org/bugs/?49176

It cannot distinguish between pasted and typed text. And when typing it binds the newline character to justify instead of newline, for some absurd reason. The correct fix is for nano to implement bracketed paste mode, which is both more secure and a better design. It's 2018 even most shells implement bracketed paste, let alone editors. You can work around it by following the advice in that bug report to unbind Ctrl-J (which is the newline character) or use a better editor.

I am guessing that other terminal emulators work around this brokenness by preprocessing the pasted text, replacing \n by \r. I suppose kitty could do the same, although this kind of hackery breaks my heart.

A simple patch for kitty to do that would be:

diff --git a/kitty/window.py b/kitty/window.py
index 92d2181d..6c202c6f 100644
--- a/kitty/window.py
+++ b/kitty/window.py
@@ -478,6 +478,10 @@ class Window:
                     if len(text) == len(new_text):
                         break
                     text = new_text
+            else:
+                # Workaround for broken editors like nano,
+                # see https://github.com/kovidgoyal/kitty/issues/994
+                text = b'\r'.join(text.splitlines())
             self.screen.paste(text)

     def copy_to_clipboard(self):

[serebit]

That's not the only weird behavior from Nano, actually. 3.0 introduced a regression (again, only in kitty) where the backspace key would delete the preceding word, rather than the preceding char. It was fixed in 3.1, though it didn't show up in the changelog. Weird stuff.

[serebit]

On another note, I installed micro to test it out, and (again, only in kitty) I get this error when attempting to run it:

terminal entry not found
Fatal: Micro could not initialize a screen.

Should I create a new issue for that?

[kovidgoyal]

https://sw.kovidgoyal.net/kitty/faq.html#i-get-errors-about-the-terminal-being-unknown-or-opening-the-terminal-failing-when-sshing-into-a-different-computer

[serebit]

Helpful for a different reason, but not what I'm talking about. I'm using micro locally.

[kovidgoyal]

I just tried micro 1.4.1 and it works fine in kitty. The link I posted is pretty much the only reason for that error. The only other reason would be if the software generating it ignores the TERMINFO environment var, which you can work around by copying the kitty terminfo files to ~/.terminfo or /usr/share/terminfo

[serebit]

I'll figure it out. Main issue is the nano thing. I'd figure out another editor to use, but my main use is to c&p into an ssh session on a remote server that I can't add editors to.

On Wed, Sep 19, 2018 at 10:01 PM, Kovid Goyal [e-mail] wrote:

https://sw.kovidgoyal.net/kitty/faq.html#i-get-errors-about-the-terminal-being-unknown-or-opening-the-terminal-failing-when-sshing-into-a-different-computer

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[kovidgoyal]

Well try the patch I posted above, it should do the trick.

[serebit]

In regards to the patch, works like a charm. I'll keep this issue open, though (unless you want to close it), since it is still an issue that exists in the release version of kitty.

In regards to micro, the distro I use has a slightly out-of-date version of kitty (0.11.3). I installed the newest version, and it worked without a hitch.

[serebit]

For the record, I know it sucks to add these kinds of workarounds. If I were in your place, being the contrarian that I am, I'd likely refuse to patch it. But I appreciate you doing so, and within the day no less. Keep up the good work!

On Wed, Sep 19, 2018 at 11:38 PM, Kovid Goyal [e-mail] wrote:

Closed #994 via 3f0b52b.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[serebit]

So I updated to the newest version of Kitty, which includes the fix for this. Despite my window.py file having the patched code (verified by viewing the file itself), newlines still aren't correctly pasted in nano 3.1. I'm at a loss.

[kovidgoyal]

You sure you are running the updated kitty?

[serebit]

I was sure, I even ran kitty --version and checked that the window.py file was patched. Even so, as I woke up my laptop to check again, it suddenly works. I changed nothing, I did not restart the laptop, and yet it suddenly works. Strange.

[jiaxincao]

@kovidgoyal, the workaround actually caused another issue. Let's say I'm copying a cli command (with newline) in emacs, and then want to paste it into the terminal. What I'm expecting is that the command will be executed immediately. However, the workaround striped the newline in my paste, which means I'll have to type an enter in the terminal.

[kovidgoyal]

You should never copy paste into a shell and have in interpret newlines. That is a huge security risk. See bracketed paste mode, which kitty and most modern shells support.

[jiaxincao]

Why would there be a security concern? Are you suggesting that copying "ls\n" is not encouraged?

[jiaxincao]

Sometimes I might need to copy multiple commands in a single paste, e.g., "cd\nls\n". For this case, kitty would only copy "cd\nls", instead of "cd\nls\n". Is your point that we should not include \n in any paste?

[kovidgoyal]

Google bracketed paste

[kovidgoyal]

My point is that you should never paste commands that auto-execute into
a shell. Doing so is extremely dangerous. Therefore, the issue is moot.

[Luflosi]

Here is a demonstration of a possible attack: https://thejh.net/misc/website-terminal-copy-paste

[jiaxincao]

I appreciate that you guys pointed out the security risk, and I agree with you guys on it. I think maybe I provided a bad example. What we are discussing are two complete different issues:

1. Copying commands to shell via terminal is dangerous. Agreed.
2. Kitty silently changes the user paste content without telling users if bracketed paste is not enabled. I feel this is super weird, because I had to look into the code of pitty to understand why. Kitty is indeed the only terminal that does this.

[kovidgoyal]

How is it supposed to tell the user bracketed paste is not enabled? And
I'm pretty sure most terminals do this, since otherwise pasting into
nano would not work in any of them.

[jiaxincao]

It does not matter whether the terminal enables the bracketed paste mode. The point is that a good terminal should never change users intent silently (in this case, the content users try to paste), no matter bracketed paste mode is enabled or not.

Btw, I don't believe iterm2 and mintty enables this bracketed paste mode by default.

[kovidgoyal]

bracketed paste mode is not enabled by default in kitty either.
bracketed paste mode is something that is enabled by the program running
in the terminal. I suggest you spend some time actually understanding
the issues involved before implying kitty is not a "good" terminal.

[zapling]

I am having this same problem on nano 4.8 locally. When I ssh into my server that is running nano 2.7.4 there is no problem. Might there be something that I'm missing or has nano changed something in their newer releases? Pic for reference https://i.imgur.com/WNQCwjf.png

[Tockra]

I am having this same problem on nano 4.8 locally. When I ssh into my server that is running nano 2.7.4 there is no problem. Might there be something that I'm missing or has nano changed something in their newer releases? Pic for reference https://i.imgur.com/WNQCwjf.png

I have the same problem.
Client with alacritty terminal and nano 4.8 has this issue.
Server with TERM=xterm-256color and nano 2.7.4 don't has this issue

After downgrading to version 4.7 I fixed this problem...

[zapling]

Seems like nano 4.8 has added support for bracketed paste http://savannah.gnu.org/bugs/?40060, this combined with the previous fix might be the cause, but I don't know.

[Kwaadpepper]

I am having this same problem on nano 4.8 locally. When I ssh into my server that is running nano 2.7.4 there is no problem. Might there be something that I'm missing or has nano changed something in their newer releases? Pic for reference https://i.imgur.com/WNQCwjf.png

I have the same problem.
Client with alacritty terminal and nano 4.8 has this issue.
Server with TERM=xterm-256color and nano 2.7.4 don't has this issue

After downgrading to version 4.7 I fixed this problem...

Thank you @tockra , you saved my life. I'm a vim unaware idiot maybe. But this bug with nano almost made me giving up on kitty. I downgrade nano (4.3, eoan package on ubuntu) and it works.

Before this i tried to compile the last kitty version, i also tried to remove the patch :
https://github.com/kovidgoyal/kitty/issues/994#issuecomment-423013445 that is still present in last version of the repo (https://github.com/kovidgoyal/kitty/commit/759a15ccbbc1decfaec47b7968dd78f40f1ab66d)
I does not solve the issue. So I confirm downgrade nano version is the fix for now (bellow 4.8 ?).:

EDIT:
Just installed the last nano version from debian, and the issue is solved

 GNU nano, version 4.9.1
 (C) 1999-2011, 2013-2020 Free Software Foundation, Inc.
 (C) 2014-2020 les contributeurs de nano
 Adr. él. : [email protected]    Site : http://nano-editor.org/
 Compilé avec les options : --disable-libmagic --enable-utf8