unable to scroll to end of document when the terminal width is less than ~76 columns #23

New Issue

asdf · 2019-05-28T06:35:31Z

asdf commented

2019-05-28 06:35:31 +00:00

When a terminal is configured to be of a certain width or smaller, it is not possible to scroll to the end of the document. The document is displayed to a certain point, and it's not possible to scroll down beyond that point. The more narrow the terminal is set, the more the document is truncated.

I tried this on two different systems, using gnome-terminal and stterm. In each case, the application was being run on a remote computer via ssh.

To reproduce, resize your terminal window to 70 columns. You can confirm this by running the command tput cols. Then, run bombadillo and scroll to the end of the document using d, G or j.

When a terminal is configured to be of a certain width or smaller, it is not possible to scroll to the end of the document. The document is displayed to a certain point, and it's not possible to scroll down beyond that point. The more narrow the terminal is set, the more the document is truncated. I tried this on two different systems, using `gnome-terminal` and `stterm`. In each case, the application was being run on a remote computer via ssh. To reproduce, resize your terminal window to 70 columns. You can confirm this by running the command `tput cols`. Then, run `bombadillo` and scroll to the end of the document using `d`, `G` or `j`.

sloum added the

bug

help wanted

labels 2019-05-28 14:53:03 +00:00

sloum commented

2019-05-28 14:53:08 +00:00

I am unable to replicate. I am using gnome-terminal. I resized to 69 cols (as well as a few other sizes) and was able to correctly move to the end of the document. Do you have a specific document you were using? I'd be happy to test on the same doc.

This did bring up the issue of text wrapping, which really donks up the look of my ascii art on the colorfield.space gopher hole once you get below 80 cols. I wonder if having a toggle setting (in the config) to turn off line wrap would be a good idea. I'm not sure how useful it would be in practice, but that is a separate issue. Any further documentation you can provide on the above issue would be really helpful!

I am unable to replicate. I am using `gnome-terminal`. I resized to 69 cols (as well as a few other sizes) and was able to correctly move to the end of the document. Do you have a specific document you were using? I'd be happy to test on the same doc. This did bring up the issue of text wrapping, which really donks up the look of my ascii art on the colorfield.space gopher hole once you get below 80 cols. I wonder if having a toggle setting (in the config) to turn off line wrap would be a good idea. I'm not sure how useful it would be in practice, but that is a separate issue. Any further documentation you can provide on the above issue would be really helpful!

sloum commented

2019-05-28 17:04:04 +00:00

Ok. I managed to replicate it on my Mac at work, connected to an ssh server, on a regular text document. I suspect that my line wrapping method is making the client think that there are only a certain number of lines (and when it hits the bottom of those lines it will not go further), when the way the wrapping is working it actually makes the document longer.

Part of the issue is that gopher phlog writers, myself included, use newlines to keep content to a certain width instead of letting it flow to the available terminal size. As a result when I wrap lines to the available display size, there are a lot of newlines in weird palces (since I dont presume to re-edit a user's content by removing newlines). That said, the way I have it written, it should recalc the length of the document on any resize, rewrap the content, and allow for getting to the bottom of the page. That isn't happening. :-/

I suspect that this is going to be a tricky one to solve in a way that makes good sense. I'm absolutely open to community input on the best way to go here (as well as research into the issue). I'll start researching options and see what I can get to work :)

Ok. I managed to replicate it on my Mac at work, connected to an ssh server, on a regular text document. I suspect that my line wrapping method is making the client think that there are only a certain number of lines (and when it hits the bottom of those lines it will not go further), when the way the wrapping is working it actually makes the document longer. Part of the issue is that gopher phlog writers, myself included, use newlines to keep content to a certain width instead of letting it flow to the available terminal size. As a result when I wrap lines to the available display size, there are a lot of newlines in weird palces (since I dont presume to re-edit a user's content by removing newlines). That said, the way I have it written, it should recalc the length of the document on any resize, rewrap the content, and allow for getting to the bottom of the page. That isn't happening. :-/ I suspect that this is going to be a tricky one to solve in a way that makes good sense. I'm absolutely open to community input on the best way to go here (as well as research into the issue). I'll start researching options and see what I can get to work :)

sloum commented

2019-06-01 05:38:15 +00:00

Closed by #25

Got it working well. There was an error in how the actual displayed screen line count was done. It was using the underlying/original data line count instead of the actual printed line count (after rewrapping). Fixing this necessitated moving the handling of resize events out of screen and into main. I think this makes more sense anyway and will be more flexible moving forward. It has already helped lead toward more simplification and better draw routines in an upcoming pr.

Closed by https://tildegit.org/sloum/bombadillo/pulls/25 Got it working well. There was an error in how the actual displayed screen line count was done. It was using the underlying/original data line count instead of the actual printed line count (after rewrapping). Fixing this necessitated moving the handling of resize events out of screen and into main. I think this makes more sense anyway and will be more flexible moving forward. It has already helped lead toward more simplification and better draw routines in an upcoming pr.

sloum closed this issue

2019-06-01 05:38:16 +00:00

Sign in to join this conversation.