Make the rendered text on the terminal copyable

[chgxtony]

Problem

The text rendered to the screen by Ratatui cannot be copied now

Solution

https://github.com/altsem/gitu/tree/master/src/screen this project still references Ratatui, which enables text to be copied。 Can these functions be integrated into Ratatui's widgets

[joshka]

Can you provide some more details please (OS, terminal, backend, example code or a link to your code). Also, given all of the above, there's lots of different ways to interpret "copying" (programmatic, mouse, cursor selection, automatic highlight vs ctrl/cmd+C etc). Can you be more specific?

[chgxtony]

Sorry, I posted the wrong link, I have corrected it. it is this link https://github.com/altsem/gitu/tree/master/src/screen Gitu has implemented text that can be copied

[joshka]

I still need more info on what the problem is here

[matusbielik]

I am not the OP, but I'd also like to learn more about what is possible when it comes to copying. I am using Alacritty on Linux, and outside of Ratatui apps, I can automatically put text into clipboard just by selecting it. Then I can paste it by clicking the middle mouse button into the terminal prompt or using CTRL+V anywhere else in the system. In ratatui apps (e.g. example app 'table'), I can't select any text, so it is not very useful as a lightweight admin interface where texts need to be copy-able easily.

When using Debian's default Gnome Terminal (Version 3.51.90 for GNOME 46), putting selected text into clipboard is not automatic, but the user still can select the text, then put it into clipboard with CTRL+SHIFT+C (or selecting 'Copy' from the context menu after clicking right mouse button). I am also not able to select the text in ratatui apps and neither bring up context menu with right mouse button.

I understand it is not trivial to make it possible for every terminal emulator and OS, but I suppose copying text is very important "feature" that shouldn't be lost with Ratatui.

EDIT: Interestingly enough, copying work well on both terminals for me when running the example "flex". What is different between table and flex examples (I am new to ratatui). Thx

[EdJoPaTo]

At least gnome console and alacritty support Shift + Click when the terminal is in alt mode. Then Ctrl + Shift + C can be used to copy the content into the system clipboard.

[joshka]

What is different between table and flex examples (I am new to ratatui). Thx

Table has mouse capture turned on (as do a lot of the examples unnecessarily). This prevents the mouse clicks that would generally make it possible to perform copy/paste actions (noting that there's usually workarounds as @EdJoPaTo mentions). https://github.com/ratatui-org/ratatui/blob/326a461f9a345ba853d57afefc8d77ba0b0b5a14/examples/table.rs#L185

Fixing this means:

• [ ] Remove the enable/disable mouse capture from all the examples where mouse clicks are not handled

@chgxtony would it be safe to reframe this issue as "Many of the examples don't allow selecting text using the mouse"?

[EdJoPaTo]

This is not specific to only the examples. Also with scrollable widgets and mouse interaction mouse capture is of interest.

[joshka]

This is not specific to only the examples. Also with scrollable widgets and mouse interaction mouse capture is of interest.

Got it - perhaps it would be worth adding some info about this sort of problem in the website somewhere. Maybe a FAQ about how mouse capture interacts with selection.

[joshka]

The fixes for this are:

• [ ] document this in the docs about mouse capture
• [ ] document this on the website
• [x] remove mouse capture from examples where it's not used (there's a few PRs out right now that modify examples, so might be worth holding off on this for a minute)

[tareqimbasher]

When using the component template from https://github.com/ratatui/templates, the UI is rendered every X frame, so even when disabling mouse capture, as soon as you start highlighting some text, the UI is redrawn and the selection is gone. I was able to get the selection to work reasonably well when I bring down the frame rate to 10 or 20 fps. But at 60 its not usable. Is this just an inherit problem to an async render loop that isn't fixable or is there some way to accomplish this?

[EdJoPaTo]

I assume that this depends heavily on the terminal you are using. For example with gnome terminal and alacritty I can mark and copy on a redraw (as long as the selected section doesn’t change). ratatui uses a diff to only update parts of the TUI that changed so it’s not directly related to the redraw when nothing changes on each redraw.

[tareqimbasher]

I didn't know that ratatui uses a diff, good to know. I am using Gnome terminal, and also tried it with Guake and I get that experience with both. The section I'm trying to highlight/select from does not change; its static content. Is there someway I can check if that part of the TUI is being redrawn?

[EdJoPaTo]

alacritty has a debug mode to highlight redrawn sections but that's not something I enable other than to try the feature :D

[joshka]

I didn't know that ratatui uses a diff, good to know. I am using Gnome terminal, and also tried it with Guake and I get that experience with both. The section I'm trying to highlight/select from does not change; its static content. Is there someway I can check if that part of the TUI is being redrawn?

You could write a custom backend that exposes this info and wrap your current one. I'm not sure this would necessarily help or be useful though.