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

Feature Request: Copy with ANSI codes #4665

Closed
jaysonlarose opened this issue Feb 9, 2022 · 15 comments
Closed

Feature Request: Copy with ANSI codes #4665

jaysonlarose opened this issue Feb 9, 2022 · 15 comments

Comments

@jaysonlarose
Copy link

Would it be possible to get a version of copy-to-clipboard that also passes along the text's formatting, similar to get-text --ansi? This is one feature that I use all the time from Gnome-Terminal, which is invaluable for creating documentation. (Gnome-Terminal's version uses HTML codes for formatting instead of ANSI, but I can make either work)

I tried to fake this myself, using kitty @ get-text --match=recent:0 --extent=selection --ansi, and that's when I learned of the "Note that when getting the current selection, the result is always plain text." caveat.

@jaysonlarose
Copy link
Author

Woah! I didn't expect a response that quickly!

I just compiled kitty and checked it out... it's almost perfect!

There's just one problem... it doesn't include any newline characters. Or, more specifically, there's nothing that marks the end of one row of output and the start of the next.

@kovidgoyal
Copy link
Owner

that's always the case when copying selections, regardless of ANSI or
not. newlines are inserted when there are actual newlines, not at screen
boundaries.

@jaysonlarose
Copy link
Author

newlines are inserted when there are actual newlines, not at screen
boundaries

I'm okay with that. I prefer it, in fact. But I'm not getting any newlines at all, even at the actual end of lines. For example, if I run this script:

python3 -c "print('\x1b[38;2;255;0;0mred\x1b[39m light, \n\x1b[38;2;0;128;0mgreen\x1b[39m light.\n')"

Which looks like this when run:

lcopy

Then I highlight the command output, issue copy_to_clipboard, and then send the clipboard contents to a hex dumper:

% xsel -o -b | xxd
00000000: 7265 6420 6c69 6768 742c 200a 6772 6565  red light, .gree
00000010: 6e20 6c69 6768 742e 0a                   n light..

It shows newline characters.

If I perform the same procedure with copy_ansi_to_clipboard:

% xsel -o -b | xxd
00000000: 1b5b 3338 3a32 3a32 3535 3a30 3a30 6d72  .[38:2:255:0:0mr
00000010: 6564 1b5b 3339 6d20 6c69 6768 742c 201b  ed.[39m light, .
00000020: 5b33 383a 323a 303a 3132 383a 306d 6772  [38:2:0:128:0mgr
00000030: 6565 6e1b 5b33 396d 206c 6967 6874 2e1b  een.[39m light..
00000040: 5b6d                                     [m

No newline characters.

I can make do if need be by capturing both commands and applying the newlines in copy_to_clipboard to the output of copy_ansi_to_clipboard, but from what you said, it sounds like what I'm currently seeing isn't the intended behavior.

@page-down
Copy link
Contributor

Is this normal? Or am I doing it wrong?

printf 'copy\ntest\n'
┌────────┬─────────────────────────┬─────────────────────────┬────────┬────────┐
│00000000│ 63 6f 70 79 74 65 73 74 ┊ 1b 5b 6d                │copytest┊•[m     │
└────────┴─────────────────────────┴─────────────────────────┴────────┴────────┘

@kovidgoyal
Copy link
Owner

kovidgoyal commented Feb 13, 2022 via email

@kovidgoyal
Copy link
Owner

@page-down not sure what you are asking? If you mean the .[m at the end, yes thats whatever you are using to paste converting the ansi escape code at the end into a text representation.

@page-down
Copy link
Contributor

I just select it with the mouse and use copy_ansi_to_clipboard to copy it.

Thanks, I tried the latest commit and this issue no longer exists.

@kovidgoyal
Copy link
Owner

kovidgoyal commented Feb 13, 2022 via email

@jaysonlarose
Copy link
Author

Awesome! Thank you! I can't tell you how stoked I am about the possibility of kicking Gnome Terminal to the curb!

@kovidgoyal
Copy link
Owner

Enjoy :)

@page-down
Copy link
Contributor

It will still be there if you copy some colored text.

Yes, that's needed.

printf 'copy\ntest\n\n\ndebug\n'
# 63 6f 70 79 0a
# 74 65 73 74 0a
# 64 65 62 75 67

It seems that the newlines are merged into one.

@kovidgoyal
Copy link
Owner

See my latest commit

@jaysonlarose
Copy link
Author

Now I feel like I'm asking for more than I deserve by far, so I'd totally understand if you come back with "no"... but I just learned that there are two ways of doing 24 bit color codes (as in, "colon-delimited" and "semicolon-delimited"), and I found out the hard way that the library I was planning on using to convert ANSI to HTML tags (https://github.com/pycontribs/ansi2html/) only does the semicolon-delimited way.

I've already submitted a bug report to the developers of the library, but I figured I'd ask if you'd consider adding something like a configuration directive for choosing which delimiter style to use. I dug around in the code and it looks like all I needed to do for a workaround was to modify two lines in function color_as_sgr() in kitty/kitty/line.c, but I figured I'd inquire anyways in case you think it might come up again.

@kovidgoyal
Copy link
Owner

colons are the correct way to do it. It's not something I feel deserves
a configoption. You can of course use a locally patched copy for
yourself till your library is fixed.

@jaysonlarose
Copy link
Author

Acknowledged.

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

No branches or pull requests

3 participants