nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bracketed pasting nano 4.8


From: Benno Schulenberg
Subject: Re: Bracketed pasting nano 4.8
Date: Thu, 19 Mar 2020 09:29:06 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

Hello Tim,

Op 17-03-2020 om 11:14 schreef Benno Schulenberg:
> Op 17-03-2020 om 00:42 schreef Tim Tannert:
>> When I'm using the latest arch linux version and the latest nano version with
>> the alacritty terminal, I can't paste new lines into the nano editor. 
>> When I do it the editor removes the new lines.
> 
> Please try applying the attached patch to nano-4.8.
> 
> Also, please report your issue on Savannah:
> 
>   https://savannah.gnu.org/bugs/?group=nano.

Since you haven't posted the issue on Savannah, I have done it for you:

  https://savannah.gnu.org/bugs/?58010

"""
It seems that some terminal emulators, when pasting, will feed the exact 
contents
of the clipboard to whatever program is running in the terminal.  That is, if 
the
clipboard contains multiple lines (each terminated with a LF character), it will
feed these linefeeds unchanged to the running program.  This is strange.  When
the user *types* multiple lines, they don't type ^J at the end of each line, 
they
type <Enter>.  And <Enter> is ^M.  So if a terminal emulator wants to paste
something into a running program, it should simulate the *typing* of the pasted
text: it should translate LF to CR (and in case the clipboard contains CR+LF, it
should swallow the trailing LF).

So, I don't think this is a bug in nano, but a bug in the terminal emulator.
Pasting works fine in xterm and Xfce Terminal and Gnome Terminal and urxvt --
they translate LF to CR.  Are all those emulators wrong?  No, they do the
right thing.
"""

Benno

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]