[GH-ISSUE #707] Long line in TreeView is simply cut

kerem commented

2026-03-04 01:05:39 +03:00

Owner

Originally created by @LukasRauth on GitHub (Mar 11, 2022).
Original GitHub issue: https://github.com/rivo/tview/issues/707

Hi!
Great tool you are providing here!
We use the TreeView feature to show hierarchical data from the command line. It works well but if a line is too long to fit into the given width it is simply cut and there is no way to get the information from that line after the cut, except for zooming out quite a lot.

Using the left/right key just jumps one line up or down.

It would be nice to just wrap the text around or make the view left/right scrollable.

Thank you a lot!

Originally created by @LukasRauth on GitHub (Mar 11, 2022). Original GitHub issue: https://github.com/rivo/tview/issues/707 Hi! Great tool you are providing here! We use the TreeView feature to show hierarchical data from the command line. It works well but if a line is too long to fit into the given width it is simply cut and there is no way to get the information from that line after the cut, except for zooming out quite a lot. Using the left/right key just jumps one line up or down. It would be nice to just wrap the text around or make the view left/right scrollable. Thank you a lot! ![image](https://user-images.githubusercontent.com/15182695/157843627-7ffc2985-dd2a-4792-a15b-143db5aae54d.png)

kerem commented

2026-03-04 01:05:40 +03:00

Author

Owner

@rivo commented on GitHub (Apr 14, 2022):

I will most likely not introduce wrapping around and it would add tremendous complexity to this component. But I'm open to add horizontal scrolling.

A possibility is to scroll when the text doesn't fit and the user hits the right arrow key. If the text fits, the right key would move the selection down as before (mostly for backwards compatibility reasons).
Do we want to scroll in steps of one or jump by, say, 5 characters at a time?
Should all lines scroll or just the selected one?
- I would have said "just the selected one" but there might be a case where you need to read a long line although it is not selected (especially since not all lines may be selectable).
- But if it's "all lines that are too long no matter what's selected", then the idea of using the right/left arrow might break existing systems.
- We can also scroll the entire tree view instead of just individual lines.
We can also bind other keys for scrolling.

I'm open for ideas.

On a side note, I think it might be better to put longer JSON strings into a separate window than to fit them into a tree view line.

@rivo commented on GitHub (Apr 14, 2022): I will most likely not introduce wrapping around and it would add tremendous complexity to this component. But I'm open to add horizontal scrolling. - A possibility is to scroll when the text doesn't fit and the user hits the right arrow key. If the text fits, the right key would move the selection down as before (mostly for backwards compatibility reasons). - Do we want to scroll in steps of one or jump by, say, 5 characters at a time? - Should all lines scroll or just the selected one? * I would have said "just the selected one" but there might be a case where you need to read a long line although it is not selected (especially since not all lines may be selectable). * But if it's "all lines that are too long no matter what's selected", then the idea of using the right/left arrow might break existing systems. * We can also scroll the entire tree view instead of just individual lines. - We can also bind other keys for scrolling. I'm open for ideas. On a side note, I think it might be better to put longer JSON strings into a separate window than to fit them into a tree view line.

kerem commented

2026-03-04 01:05:40 +03:00

Author

Owner

@darkdragon-001 commented on GitHub (Apr 17, 2022):

I suggest scrolling the entire tree view by about 90 characters when pressing right arrow key and scrolling back when pressing left arrow key similar to the less terminal utility. Using up and down arrow keys to scroll/navigate up/down.

@darkdragon-001 commented on GitHub (Apr 17, 2022): I suggest scrolling the entire tree view by about 90 characters when pressing right arrow key and scrolling back when pressing left arrow key similar to the `less` terminal utility. Using up and down arrow keys to scroll/navigate up/down.

kerem commented

2026-03-04 01:05:40 +03:00

Author

Owner

@rivo commented on GitHub (Apr 17, 2022):

Yeah, I was hoping for a suggestion that would preserve the current behaviour for trees that fit the screen.

@rivo commented on GitHub (Apr 17, 2022): Yeah, I was hoping for a suggestion that would preserve the current behaviour for trees that fit the screen.

kerem commented

2026-03-04 01:05:40 +03:00

Author

Owner

@rivo commented on GitHub (Dec 17, 2022):

Let me phrase this differently: We need a solution that is backwards compatible. The left/right arrow keys are already used. The other questions I listed above also need to be answered before I can start.

If there's no or little interest, I will close this issue.

@rivo commented on GitHub (Dec 17, 2022): Let me phrase this differently: We **need** a solution that is backwards compatible. The left/right arrow keys are already used. The other questions I listed above also need to be answered before I can start. If there's no or little interest, I will close this issue.

kerem commented

2026-03-04 01:05:40 +03:00

Author

Owner

@kampanosg commented on GitHub (Mar 12, 2024):

Hey @rivo!

Resurrecting this, instead of raising a new issue 😅 I have the same problem/need. Some sort of horizontal scrolling in TreeView would be awesome. Let me know if I can help or contribute to this 😄

P.S: Thank you for tview. I love it 🤟

@kampanosg commented on GitHub (Mar 12, 2024): Hey @rivo! Resurrecting this, instead of raising a new issue 😅 I have the same problem/need. Some sort of horizontal scrolling in `TreeView` would be awesome. Let me know if I can help or contribute to this 😄 P.S: Thank you for `tview`. I love it 🤟

kerem commented

2026-03-04 01:05:40 +03:00

Author

Owner

@rivo commented on GitHub (Apr 3, 2024):

@kampanosg I posted a list of questions above which need to be addressed first. Maybe you can provide some insight based on your specific application, which could help us figure out a good solution.

@rivo commented on GitHub (Apr 3, 2024): @kampanosg I posted a list of questions above which need to be addressed first. Maybe you can provide some insight based on your specific application, which could help us figure out a good solution.

kerem commented

2026-03-04 01:05:40 +03:00

Author

Owner

@Macmod commented on GitHub (Jun 18, 2024):

I will most likely not introduce wrapping around and it would add tremendous complexity to this component. But I'm open to add horizontal scrolling.

A possibility is to scroll when the text doesn't fit and the user hits the right arrow key. If the text fits, the right key would move the selection down as before (mostly for backwards compatibility reasons).

Do we want to scroll in steps of one or jump by, say, 5 characters at a time?

Should all lines scroll or just the selected one?

I would have said "just the selected one" but there might be a case where you need to read a long line although it is not selected (especially since not all lines may be selectable).

But if it's "all lines that are too long no matter what's selected", then the idea of using the right/left arrow might break existing systems.

We can also scroll the entire tree view instead of just individual lines.

We can also bind other keys for scrolling.

I'm open for ideas.

On a side note, I think it might be better to put longer JSON strings into a separate window than to fit them into a tree view line.

I agree with others that this is an important feature. In my app I try to arrange all information using Flex because the data that is going to be loaded does not have predictable dimensions, thus giving the user more flexibility to increase or decrease the size of things he wants to read by resizing the window. So I have a couple Flexes and inside them other components that hold data. Tables are fine, but TreeViews simply put a hard limit on what the user can see, which is ultimately limited by his maximum window size (of course the user can be "sneaky" and figure out he can also get more space by changing the font size, but that's not ideal).

In my opinion:

The horizontal scroll should be disabled by default, and there should be something like a SetHorizontalScroll(bool) method to explicitly enable it;
The step could be configurable through a separate SetHorizontalScrollStep(uint)
Scrolling just the selected line does not feel natural, neither scrolling all individual lines. I feel the most natural way to do it would be to scroll the entire TreeView instead of moving to the previous/next line whenever the user presses the arrow keys, if SetHorizontalScroll was explicitly set to true. This behavior can be detailed in the docs so that people won't be too annoyed by it.

In my app for example I even override the right/arrow keys to expand/collapse nodes, because I don't like having horizontal keys moving vertically, so in my case I wouldn't mind much if this was implemented. If someone does mind and wants both behaviors to work "somehow", I believe (but please correct me if wrong) they could define their own handler that just selects the previous/next node using other keys.

I don't have a solution, but I wanted to share these thoughts to the discussion :-)

@Macmod commented on GitHub (Jun 18, 2024): > I will most likely not introduce wrapping around and it would add tremendous complexity to this component. But I'm open to add horizontal scrolling. > > * A possibility is to scroll when the text doesn't fit and the user hits the right arrow key. If the text fits, the right key would move the selection down as before (mostly for backwards compatibility reasons). > * Do we want to scroll in steps of one or jump by, say, 5 characters at a time? > * Should all lines scroll or just the selected one? > > * I would have said "just the selected one" but there might be a case where you need to read a long line although it is not selected (especially since not all lines may be selectable). > * But if it's "all lines that are too long no matter what's selected", then the idea of using the right/left arrow might break existing systems. > * We can also scroll the entire tree view instead of just individual lines. > * We can also bind other keys for scrolling. > > I'm open for ideas. > > On a side note, I think it might be better to put longer JSON strings into a separate window than to fit them into a tree view line. I agree with others that this is an important feature. In my app I try to arrange all information using Flex because the data that is going to be loaded does not have predictable dimensions, thus giving the user more flexibility to increase or decrease the size of things he wants to read by resizing the window. So I have a couple Flexes and inside them other components that hold data. Tables are fine, but TreeViews simply put a hard limit on what the user can see, which is ultimately limited by his maximum window size (of course the user can be "sneaky" and figure out he can also get more space by changing the font size, but that's not ideal). In my *opinion*: * The horizontal scroll should be disabled by default, and there should be something like a `SetHorizontalScroll(bool)` method to explicitly enable it; * The step could be configurable through a separate `SetHorizontalScrollStep(uint)` * Scrolling just the selected line does not feel natural, neither scrolling all individual lines. I feel the most natural way to do it would be to scroll the entire TreeView instead of moving to the previous/next line whenever the user presses the arrow keys, *if SetHorizontalScroll* was explicitly set to true. This behavior can be detailed in the docs so that people won't be too annoyed by it. In my app for example I even override the right/arrow keys to expand/collapse nodes, because I don't like having horizontal keys moving vertically, so *in my case* I wouldn't mind much if this was implemented. If someone does mind and wants both behaviors to work "somehow", I believe (but please correct me if wrong) they could define their own handler that just selects the previous/next node using other keys. I don't have a solution, but I wanted to share these thoughts to the discussion :-)

Rows
Columns

[GH-ISSUE #707] Long line in TreeView is simply cut #515