text flow issues on gophermap/menu pages when console is at 80 characters wide #31

New Issue

asdf · 2019-09-02T01:06:46Z

asdf commented

2019-09-02 01:06:46 +00:00

With a console at 80 characters wide, text flow on gophermap/menu pages acts in an odd way.

Using the default home page as an example, where the text paragraphs wrap at just less than 80 characters, and the console at 80x24:

The first paragraph is displayed correctly, with the exception of the last line. It is indented.
the second paragraph is indented completely.

Here's a copy of what is in the console - the bottom of the first paragraph and the second paragraph:

to vim (as detailed below). source code can be downloaded from the link         
and is written in golang. linux and osx are fully supported for both arm        
           and x86_64.                                                          
                                                                                
           in bombadillo, scroll down with 'j' and up with 'k'. this is being   
           listed here to facilitate easier viewing of the rest of this doc     
           for first time users.

By gradually increasing the size of the console and pressing a key to redraw the screen, you can see that lines become indented once they fit on the screen.

Looking at the code, it seems that any lines that are affected by wrapLines() have the indentation removed. I'm not sure where the indentation is being added though.

From what I can tell so far, there are a few ways to address this:

Remove line wrapping
Ensure wrapped lines still draw the default indent
Ensure indent is uniform across the document, but can resize to fit the window.

Let me know what you think, and if you can point to the function that draws the indent that would help too!

Some final points of clarification:

I'm testing this on rawtext.club, running the latest version from git as well as the version that is installed. Both display the same symptoms.
Using a few different terminals - gnome-terminal and rxvt-unicode - shows no difference.

With a console at 80 characters wide, text flow on gophermap/menu pages acts in an odd way. Using the default home page as an example, where the text paragraphs wrap at just less than 80 characters, and the console at 80x24: - The first paragraph is displayed correctly, with the exception of the last line. It is indented. - the second paragraph is indented completely. Here's a copy of what is in the console - the bottom of the first paragraph and the second paragraph: <pre>to vim (as detailed below). source code can be downloaded from the link and is written in golang. linux and osx are fully supported for both arm and x86_64. in bombadillo, scroll down with 'j' and up with 'k'. this is being listed here to facilitate easier viewing of the rest of this doc for first time users.</pre> By gradually increasing the size of the console and pressing a key to redraw the screen, you can see that lines become indented once they fit on the screen. Looking at the code, it seems that any lines that are affected by `wrapLines()` have the indentation removed. I'm not sure where the indentation is being added though. From what I can tell so far, there are a few ways to address this: - Remove line wrapping - Ensure wrapped lines still draw the default indent - Ensure indent is uniform across the document, but can resize to fit the window. Let me know what you think, and if you can point to the function that draws the indent that would help too! Some final points of clarification: - I'm testing this on rawtext.club, running the latest version from git as well as the version that is installed. Both display the same symptoms. - Using a few different terminals - `gnome-terminal` and `rxvt-unicode` - shows no difference.

sloum commented

2019-09-02 03:14:58 +00:00

My guess is that it happens in parseGophermap (Im not looking at the code, it could be called parseMap). It adds spacing to the beginning of item type i lines so that they line up with the content start of link lines (where the actual text starts, rather then where the gophertype starts).

Let me do some testing and get back to you but I def see this as an issue that should get resolved sooner rather than later. I dont like the idea of removing line wrapping only in that I would then have to build out the ability to do horizontal scrolling which seems like a bigger task at this point than fixing the wrapping.

My guess is that when a line is wrapped it is not being indented like the lines above it. So, this brings up the question... should item type i be indented at all? If we did not indent it then things would end up looking like this:

in bombadillo, scroll down with 'j' and up with 'k'. this is being                                                                                                                                        
listed here to facilitate easier viewing of the rest of this doc                                                                                                                                          
for first time users.                                                                                                                                                                                     
                                                                                                                                                                                                                     
                                                                                                                                                                                                                     
source code is available here:                                                                                                                                                                            
(HTM)  1   http://tildegit.org/sloum/bombadillo

rather than this (which is what is supposed to be happening):

           in bombadillo, scroll down with 'j' and up with 'k'. this is being                                                                                                                                        
           listed here to facilitate easier viewing of the rest of this doc                                                                                                                                          
           for first time users.                                                                                                                                                                                     
                                                                                                                                                                                                                     
                                                                                                                                                                                                                     
           source code is available here:                                                                                                                                                                            
(HTM)  1   http://tildegit.org/sloum/bombadillo

I had always felt that things should be lined up as content... but it might make fine sense to have them just left align. It would certainly lead to less wrapping being needed in the first place since all that spacing is just dead space that could have text in it. What do you think?

The indentation does have the benefit of making links easily visually grepable from info lines... but maybe that isnt such a huge benefit that it is worth the loss of screen real estate (particularly on smaller screens with fewer columns). I could do link lines with ansi color codes or some such (though I worry about clashing with settings in peoples terminal emulators and making text difficult to read).

My guess is that it happens in `parseGophermap` (Im not looking at the code, it could be called `parseMap`). It adds spacing to the beginning of item type `i` lines so that they line up with the content start of link lines (where the actual text starts, rather then where the gophertype starts). Let me do some testing and get back to you but I def see this as an issue that should get resolved sooner rather than later. I dont like the idea of removing line wrapping only in that I would then have to build out the ability to do horizontal scrolling which seems like a bigger task at this point than fixing the wrapping. My guess is that when a line is wrapped it is not being indented like the lines above it. So, this brings up the question... should item type `i` be indented at all? If we did not indent it then things would end up looking like this: ``` in bombadillo, scroll down with 'j' and up with 'k'. this is being listed here to facilitate easier viewing of the rest of this doc for first time users. source code is available here: (HTM) 1 http://tildegit.org/sloum/bombadillo ``` rather than this (which is what is supposed to be happening): ``` in bombadillo, scroll down with 'j' and up with 'k'. this is being listed here to facilitate easier viewing of the rest of this doc for first time users. source code is available here: (HTM) 1 http://tildegit.org/sloum/bombadillo ``` I had always felt that things should be lined up as content... but it might make fine sense to have them just left align. It would certainly lead to less wrapping being needed in the first place since all that spacing is just dead space that could have text in it. What do you think? The indentation does have the benefit of making links easily visually grepable from info lines... but maybe that isnt such a huge benefit that it is worth the loss of screen real estate (particularly on smaller screens with fewer columns). I could do link lines with ansi color codes or some such (though I worry about clashing with settings in peoples terminal emulators and making text difficult to read).

sloum commented

2019-09-02 03:31:28 +00:00

Ok. I removed the additional spaces being concatenated before i type lines. It is at first VERY weird. In some ways it makes things nicer... but it definitely takes getting used to. I could see it potentially breaking with visual layout for people (if they had lines that were supposed to line up with the text in links, for example). I am not sure if this is a good way to go or not. It may be better to look into wrapLines and fix it there by adding the necessary spacing where applicable. I'll try that out when I get a chance (likely not tonight) and report back.

Ok. I removed the additional spaces being concatenated before `i` type lines. It is at first VERY weird. In some ways it makes things nicer... but it definitely takes getting used to. I could see it potentially breaking with visual layout for people (if they had lines that were supposed to line up with the text in links, for example). I am not sure if this is a good way to go or not. It may be better to look into wrapLines and fix it there by adding the necessary spacing where applicable. I'll try that out when I get a chance (likely not tonight) and report back.

asdf commented

2019-09-02 23:49:04 +00:00

OK so it's just the indentation for type i items, and I guess the wrapping function is mangling the indent (maybe because it splits on " ").

I think the indentation is good when it can fit. It would be good if we keep it as is if you have a lot of space, like running the terminal fullscreen.

When space is limited, it would be good to have the indenting reduce as necessary. So for text that is 80 characters wide, in an 80x25 terminal, maybe there is no indentation. In a 90x25 terminal, maybe it's 10 characters. Lower than 80, text starts to wrap. Responsive design?

OK so it's just the indentation for type `i` items, and I guess the wrapping function is mangling the indent (maybe because it splits on " "). I think the indentation is good when it can fit. It would be good if we keep it as is if you have a lot of space, like running the terminal fullscreen. When space is limited, it would be good to have the indenting reduce as necessary. So for text that is 80 characters wide, in an 80x25 terminal, maybe there is no indentation. In a 90x25 terminal, maybe it's 10 characters. Lower than 80, text starts to wrap. Responsive design?

sloum commented

2019-09-03 15:47:46 +00:00

The problem with reducing the indentation is that the indentation exists to provide room for link meta information (link type and number), so then you get content misalignment if you just reduce spacing for i types. The meta information is semi-set in width. The three letter type info I think is about as short as you can get and still be useful to newcomers and link numbers need to have room for at least three characters (I have been on gophermaps with over 100 links), so there is not a lot of reduction possible on those lines.

I do think I can fix the original issue (text reflowing not lining up) though. If after doing so, there are still spacing concerns lets put them into a separate issue :)

The problem with reducing the indentation is that the indentation exists to provide room for link meta information (link type and number), so then you get content misalignment if you just reduce spacing for `i` types. The meta information is semi-set in width. The three letter type info I think is about as short as you can get and still be useful to newcomers and link numbers need to have room for at least three characters (I have been on gophermaps with over 100 links), so there is not a lot of reduction possible on those lines. I do think I can fix the original issue (text reflowing not lining up) though. If after doing so, there are still spacing concerns lets put them into a separate issue :)

sloum commented

2019-09-04 03:21:12 +00:00

So, it seems that maybe I was wrong about this issue. I tried a fix for this, which ended up being weirder than I felt like it should have been... but should have worked... and didnt. I'm not sure I understand the issue well enough yet (the root cause, I mean). It may not be what I thought it was... at least not entirely. Given the limited time I have available I switched over to issue #32 and will return to this soon.

sloum added the

bug

help wanted

labels 2019-09-04 04:05:45 +00:00

asdf commented

2019-09-04 13:06:01 +00:00

I've spent some time on this and have most of a solution, but don't know if it's the best way to deal with this.

The issue I see is that any lines modified by wrapLines lose the indent:

To wrap a line, the line is split in to words using strings.Split(). We split on space, and the indent is 11 spaces. strings.Split() can split on a repeated delimiter, but returns the split item as an empty string. So splitting "aaa" with delimiter "a" gives you ["","","",""]. The indent is therefore lost.
If a new line is created to continue from the previous line, no indent is inserted.

Also, lines that wrapLines() does not need to modify stay how they were, so they will keep whatever indent they might have.

I have some work on this in #34, which I hope can help explain this a bit further.

I've spent some time on this and have most of a solution, but don't know if it's the best way to deal with this. The issue I see is that any lines modified by `wrapLines` lose the indent: 1. To wrap a line, the line is split in to words using `strings.Split()`. We split on space, and the indent is 11 spaces. `strings.Split()` can split on a repeated delimiter, but returns the split item as an empty string. So splitting `"aaa"` with delimiter `"a"` gives you `["","","",""]`. The indent is therefore lost. 2. If a new line is created to continue from the previous line, no indent is inserted. Also, lines that `wrapLines()` does not need to modify stay how they were, so they will keep whatever indent they might have. I have some work on this in #34, which I hope can help explain this a bit further.

sloum commented

2019-09-10 15:21:56 +00:00

This issue is partially fixed, but I am going to leave it open for a bit while we work through the rest:

We now keep proper spaces, including multiple spaces in a row, when wrapping text. This is a big improvement.

TODO in a future PR:

Wrap long lines with no spaces properly
Handle multispace characters (unicode) properly
Handle tabs
Handle extra indent of wrapped link lines on gophermaps

This issue is partially fixed, but I am going to leave it open for a bit while we work through the rest: We now keep proper spaces, including multiple spaces in a row, when wrapping text. This is a big improvement. __TODO in a future PR__: - Wrap long lines with no spaces properly - Handle multispace characters (unicode) properly - Handle tabs - Handle extra indent of wrapped link lines on gophermaps

asdf commented

2019-09-13 11:31:29 +00:00

Also TODO:

Documents n characters in width, displayed in a terminal of n columns, should fit naturally without wrapping

Also TODO: - Documents n characters in width, displayed in a terminal of n columns, should fit naturally without wrapping

sloum commented

2019-10-23 05:36:49 +00:00

This issue has been resolved for v2.0.0 via the new (simpler) line wrapping model. As we are nearing release I am going to close this issue as it will not be updated in the < 2.0.0 release series and is already solved on develop for the new release.

This issue has been resolved for v2.0.0 via the new (simpler) line wrapping model. As we are nearing release I am going to close this issue as it will not be updated in the < 2.0.0 release series and is already solved on `develop` for the new release.

sloum closed this issue

2019-10-23 05:36:49 +00:00

Sign in to join this conversation.