Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pasting clipboard duplicates newlines #5528

Closed
kgraefe opened this issue Sep 23, 2022 · 9 comments
Closed

Pasting clipboard duplicates newlines #5528

kgraefe opened this issue Sep 23, 2022 · 9 comments
Labels

Comments

@kgraefe
Copy link
Contributor

kgraefe commented Sep 23, 2022

Describe the bug
Since 0.26.3 pasting from the clipboard duplicates newlines in some shells and vim. It does not happen on 0.26.2.

To Reproduce
Steps to reproduce the behavior:

  1. copy this into the clipboard:
    echo hello \
    multiline world
    
  2. Paste into the terminal (Ctrl-Shift-V or paste_from_clipboard): the newline is duplicated in zsh and vim, not in sh

Screenshots
If applicable, add screenshots to help explain your problem.

image

Environment details

kitty 0.26.3 created by Kovid Goyal
Linux tethys 5.15.0-48-generic #54-Ubuntu SMP Fri Aug 26 13:26:29 UTC 2022 x86_64
Ubuntu 22.04.1 LTS tethys /dev/tty

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS"
Running under: X11
Frozen: True
Paths:
  kitty: /home/kgraefe/.local/kitty.app/bin/kitty
  base dir: /home/kgraefe/.local/kitty.app/lib/kitty
  extensions dir: /home/kgraefe/.local/kitty.app/lib/kitty-extensions
  system shell: /usr/bin/zsh

Config options different from defaults:

Important environment variables seen by the kitty process:
        PATH                                /home/kgraefe/bin:/home/kgraefe/.local/kitty.app/bin:/home/kgraefe/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin
        LANG                                de_DE.UTF-8
        EDITOR                              vim
        SHELL                               /usr/bin/zsh
        DISPLAY                             :0
        USER                                kgraefe
        LC_TIME                             de_DE.UTF-8
        XDG_SESSION_TYPE                    x11
        LC_MONETARY                         de_DE.UTF-8
        XDG_SESSION_CLASS                   user
        LC_ADDRESS                          de_DE.UTF-8
        XDG_MENU_PREFIX                     gnome-
        XDG_RUNTIME_DIR                     /run/user/1000
        LC_TELEPHONE                        de_DE.UTF-8
        XDG_CURRENT_DESKTOP                 ubuntu:GNOME
        XDG_SESSION_DESKTOP                 ubuntu-xorg
        LC_NAME                             de_DE.UTF-8
        LC_MEASUREMENT                      de_DE.UTF-8
        LC_IDENTIFICATION                   de_DE.UTF-8
        XDG_CONFIG_DIRS                     /etc/xdg/xdg-ubuntu-xorg:/etc/xdg
        XDG_DATA_DIRS                       /usr/share/ubuntu-xorg:/usr/share/gnome:/home/kgraefe/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop
        LC_NUMERIC                          de_DE.UTF-8
        LC_PAPER                            de_DE.UTF-8

This debug output has been copied to the clipboard

Additional context
I can reproduce the problem with kitty --config NONE and with plain zsh (zsh -f -i).

@kgraefe kgraefe added the bug label Sep 23, 2022
@kovidgoyal
Copy link
Owner

Does not repro for me with the following steps:

  1. echo -n "a\nb\nc" | kitty +kitten clipboard
  2. kitty --config NONE zsh -f -i
  3. Press ctrl+shift+v
  4. zsh shows
hostname% a
b
c<cursor>

as expected. How are you getting your multiline string into the clipboard?

@kgraefe
Copy link
Contributor Author

kgraefe commented Sep 23, 2022

Your example does not reproduce it for me.

However it does, if I copy my string from the browser (Firefox on X11) either by select and Ctrl+C or by clicking the nearby copy icon:

tethys% echo hello \

multiline world

Apparently it than comes with a Windows style newline:

tethys% kitty +kitten clipboard --get-clipboard |hexdump -C
00000000  65 63 68 6f 20 68 65 6c  6c 6f 20 5c 0d 0a 6d 75  |echo hello \..mu|
00000010  6c 74 69 6c 69 6e 65 20  77 6f 72 6c 64           |ltiline world|
0000001d

but it somehow depends on what is running in the terminal. When pasting into running hexdump -C with Ctrl+Shift+V (and following Enter and Ctrl+D) the CR (0x0D) does not show up:

tethys% hexdump -C
echo hello \
multiline world
00000000  65 63 68 6f 20 68 65 6c  6c 6f 20 5c 0a 6d 75 6c  |echo hello \.mul|
00000010  74 69 6c 69 6e 65 20 77  6f 72 6c 64 0a           |tiline world.|
0000001d

@page-down
Copy link
Contributor

Since 0.26.3 pasting from the clipboard duplicates newlines ...

I cannot reproduce this, there is no difference compared to 0.25.2.

... if I copy my string from the browser (Firefox on X11) ... by clicking the nearby copy icon ...
... Windows style newline ...

Then the problem you are experiencing is obviously related to how some software copies text to the clipboard.
I tried clicking the copy to clipboard button on Firefox (Linux X11) / Chrome (macOS) and got LF instead of CR LF.
So I still can't reproduce your issue under UNIX-like systems.

but it somehow depends on what is running in the terminal ...

When you paste in a modern shell, bracketed paste mode will be used and the data will be passed to the program by the escape sequence as is.

When bracketed paste mode is not enabled, kitty will convert CR LF to LF, then convert LF to CR.

From my understanding, you want to run zsh in kitty, then paste and execute the command from GitHub or elsewhere, and don't want extra new lines.
Try writing custom paste action filter (replace CRLF with LF) if you are sure you don't care about CR in your usage scenario.
https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.paste_actions

@kovidgoyal
Copy link
Owner

It was because GTK converts line endings to DOS line ending for text/plain but not for text/plain;charset=utf-8. Because of the clipboard handling re-organisation to support arbitrary mime types in the the last release, kitty started requesting text/plain instead of UTF8_STRING under X11 which caused this issue. Have special cased text/plain to now request text/plain;charset=utf-8 first.

@kgraefe
Copy link
Contributor Author

kgraefe commented Sep 26, 2022

Thank you! What a stupid reason...

@Exagone313
Copy link

Hi, I still have this issue on Kitty 0.26.5, when using X11 (i3). I don't replicate this on Wayland (sway/wlroots).

To reproduce, I'm copying a string with two lines from leafpad (a GTK+2 application) and it adds a blank line in the middle.

I'm running Arch Linux, it is up-to-date (I can give some specific dependency versions if required).

@kovidgoyal
Copy link
Owner

That is because leafpad is using DOS line endings even for
text/plain;charset=utf-8

Esily verified by running

xclip -o -t text/plain;charset=utf-8 -selection clipboard | python -c "import sys; print(sys.stdin.buffer.read())"

That's a bug in leafpad (or more likely the version of GTK it is using).
I'm afraid there are limits to how many GTK bugs I am willing to
workaround, sorry. I could prioritize UTF8_STRING over
text/plain;charset=utf-8 but that might break something else. There is
absolutely no good reason for Linux applications to be using DOS line
endings when copying text to the clipboard. GTK 3 does it for text/plain
but not text/plain;charset=utf-8 which is boderline acceptable, it makes
sense to prefer the more specific mime type when available, so I have
kitty doing that. Preferring UTF8_STRING makes no sense whatsoever.
This needs to be fixed in leafpad or GTK 2 or leafpad needs to move off
GTK2.

@Exagone313
Copy link

Leafpad development is pretty much dead (last version from 2020), so I don't think anything will come from it. I use it for temporary notes on my screen, because I consider it stable (I know nothing will change).

I now hesitate between:

  • quickly patch leafpad
  • check if it can be ported to GTK+ 4 and fork it
  • downgrade Kitty
  • patch kitty

Thanks for your answer anyway.

@kovidgoyal
Copy link
Owner

@Exagone313 here you go: 5849716

There was another use case that benefits from trying UTF8_STRING first, so I made the change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants