Remove left whitespace from all wrapped, non-preformatted lines #169

New Issue

makeworld · 2020-05-26T23:06:31Z

makeworld commented

2020-05-26 23:06:31 +00:00

Here's an example from gemini://tilde.black:1965/users/fox/vintagetv/superman-01.gmi, where you can see that the 3rd and 4th line start with extra spaces.

In the episode "The Mind Machine" a gangster is on trial. He has kidnapped a scientist working on a m                                                                                         
achine to help modify the behavior of mentally troubled patients. The gangster has other plans for it,                                                                                        
 though. He pressures and threatens the doctor until he uses the machine to overwhelm the willpower of                                                                                        
 those witnesses testifying against him. This long-range mind-control has a terrible side effect, thou                                                                                        
gh. It drives the target completely insane, eventually killing them.

This is obviously non-urgent, but I thought I might look into adding it myself, and wanted to file an issue to keep track of it. If I shouldn't file issues like this (and just keep track of it personally), please let me know.

Here's an example from `gemini://tilde.black:1965/users/fox/vintagetv/superman-01.gmi`, where you can see that the 3rd and 4th line start with extra spaces. ```text In the episode "The Mind Machine" a gangster is on trial. He has kidnapped a scientist working on a m achine to help modify the behavior of mentally troubled patients. The gangster has other plans for it, though. He pressures and threatens the doctor until he uses the machine to overwhelm the willpower of those witnesses testifying against him. This long-range mind-control has a terrible side effect, thou gh. It drives the target completely insane, eventually killing them. ``` This is obviously non-urgent, but I thought I might look into adding it myself, and wanted to file an issue to keep track of it. If I shouldn't file issues like this (and just keep track of it personally), please let me know.

sloum commented

2020-05-27 05:16:09 +00:00

I'm not sure how I feel about this. In that, it isn't extra whitespace... it just happens to have ended up at the beginning of a line. But it is definitely whitespace that was included by the content author.

I can definitely see why someone might want this whitespace removed. I have actually been wanting Bombadillo to remove consecutive whitespace for non-preformatted text for gemini as well (as is optionally acceptable by the spec). I have shelved that particular desire for the time, given the following:

I do not think it will be possible with the current rendering engine. Wrapping is handled the same way for every protocol and gemini is not treated differently or individually. I'm not sure how I feel about having a fix to this affecting non-gemini protocols (given their current state of being handled together, if interests were separated that might be less of a worry). Add to that the fact that the line wrapping module has no knowledge whatsoever what a preformatted text block is (that is handled at the parser level), nor what gemini is (vs gopher or finger).

This would be a major rebuild of many core elements of Bombadillo:

the wrapping method on the page struct would need to change drastically
every scheme that bombadillo supports would likely need to change how they parse, or at least the page module would need to be scheme aware and provide separate wrapping (to some degree) for each scheme
gemini would definitely need to be parsed differently, and the page struct's structure would have to change to accomodate this need (which may or may not effect other protocols)
it is possible that some of the rendering in the client struct might need to be modified and become protocol aware as well.
currently, once data is retreieved from the server and parsed it is just text to bombadillo from that point forward and is not seen as any kind of formatted document really, so we would potentially need to make all kinds of areas of the application aware of protocols that are not currently aware of them and just deal with "text".

Definitely no worries opening the issue! I get where this is coming from. My instinct is to say this will likely find its way into 3.0.0+, but you are more than welcome to try and tackle it as a part of the 2.x.x series if you want to go for it. Definitely feel free to keep notes here or ask questions/check in. Feel free to e-mail as well if you get in deep and need some guidance.

So that you do not do a lot of work for nothing, I want to be up front about the following:

No code will be accepted that compromises any other protocol's rendering or featureset (ie. if gopher rendering suffered for the advance in gemini funcitonality). I dont think this outcome is likely, just wanted to mention it so that it was on the radar of you or whoever takes on this project
No code will be accepted that requires anything outside of the Go standard library
The final result must compile with the Go 1.11 compiler

Outside of those things (I believe two of the three are mentioned in our DEVELOPING.md file), have at it!

I'm not sure how I feel about this. In that, it isn't _extra_ whitespace... it just happens to have ended up at the beginning of a line. But it is definitely whitespace that was included by the content author. I can definitely see why someone might want this whitespace removed. I have actually been wanting Bombadillo to remove consecutive whitespace for non-preformatted text for gemini as well (as is optionally acceptable by the spec). I have shelved that particular desire for the time, given the following: I do not think it will be possible with the current rendering engine. Wrapping is handled the same way for every protocol and gemini is not treated differently or individually. I'm not sure how I feel about having a fix to this affecting non-gemini protocols (given their current state of being handled together, if interests were separated that might be less of a worry). Add to that the fact that the line wrapping module has no knowledge whatsoever what a preformatted text block is (that is handled at the parser level), nor what gemini is (vs gopher or finger). This would be a major rebuild of many core elements of Bombadillo: - the wrapping method on the page struct would need to change drastically - every scheme that bombadillo supports would likely need to change how they parse, or at least the page module would need to be scheme aware and provide separate wrapping (to some degree) for each scheme - gemini would definitely need to be parsed differently, and the page struct's structure would have to change to accomodate this need (which may or may not effect other protocols) - it is possible that some of the rendering in the client struct might need to be modified and become protocol aware as well. - currently, once data is retreieved from the server and parsed it is just text to bombadillo from that point forward and is not seen as any kind of formatted document really, so we would potentially need to make all kinds of areas of the application aware of protocols that are not currently aware of them and just deal with "text". Definitely no worries opening the issue! I get where this is coming from. My instinct is to say this will likely find its way into 3.0.0+, but you are more than welcome to try and tackle it as a part of the 2.x.x series if you want to go for it. Definitely feel free to keep notes here or ask questions/check in. Feel free to e-mail as well if you get in deep and need some guidance. So that you do not do a lot of work for nothing, I want to be up front about the following: - No code will be accepted that compromises any other protocol's rendering or featureset (ie. if gopher rendering suffered for the advance in gemini funcitonality). I dont think this outcome is likely, just wanted to mention it so that it was on the radar of you or whoever takes on this project - No code will be accepted that requires anything outside of the Go standard library - The final result must compile with the Go 1.11 compiler Outside of those things (I believe two of the three are mentioned in our `DEVELOPING.md` file), have at it!

sloum added the

labels 2020-05-27 05:17:14 +00:00

sloum added this to the 3.0.0 milestone 2020-05-27 05:17:26 +00:00

sloum commented

2020-05-27 05:19:10 +00:00

I have marked this with a 3.0.0 milestone, but dont let that stop anyone from trying to handle it as a part of 2.x.x. 3.0.0 will be a major rewrite of the application, likely from the ground up, so marking this as 3.0.0 can inform or goals and planning for that eventuality.

I have marked this with a `3.0.0` milestone, but dont let that stop anyone from trying to handle it as a part of `2.x.x`. `3.0.0` will be a major rewrite of the application, likely from the ground up, so marking this as `3.0.0` can inform or goals and planning for that eventuality.

makeworld commented

2020-05-27 12:15:32 +00:00

Woah, seems a lot bigger than I thought. Thanks for explaining how one might go about it though, it's helpful.

One nitpick:

I have actually been wanting Bombadillo to remove consecutive whitespace for non-preformatted text for gemini as well (as is optionally acceptable by the spec).

As far as I can tell, this isn't true. Section 5.3.1 of the spec says "Consecutive blank lines should NOT be collapsed into a fewer blank lines."

Woah, seems a lot bigger than I thought. Thanks for explaining how one might go about it though, it's helpful. One nitpick: > I have actually been wanting Bombadillo to remove consecutive whitespace for non-preformatted text for gemini as well (as is optionally acceptable by the spec). As far as I can tell, this isn't true. Section 5.3.1 of the spec says "Consecutive blank lines should NOT be collapsed into a fewer blank lines."

sloum commented

2020-05-27 14:32:28 +00:00

No worries. Yeah, it would be a big project.

By whitespace I meant actual space characters, not newlines.

From the spec:

lines may be presented to the user in a visually pleasing manner
for general reading, the precise meaning of which is at the
client's discretion.  For example, variable width fonts may be used,
spacing may be normalised, with spaces between sentences being made
wider than spacing between words, and other such typographical
niceties may be applied.

Drilling down to the specific point:

spacing may be normalized

It does go on to give a specific example that is not what I mention, but the spec seems to allow for it between the above and the following:

authors should not expect to exercise any
control over the precise rendering of their text lines, only of their
actual textual content.

No worries. Yeah, it would be a big project. By whitespace I meant actual space characters, not newlines. From the spec: ``` lines may be presented to the user in a visually pleasing manner for general reading, the precise meaning of which is at the client's discretion. For example, variable width fonts may be used, spacing may be normalised, with spaces between sentences being made wider than spacing between words, and other such typographical niceties may be applied. ``` Drilling down to the specific point: ``` spacing may be normalized ``` It does go on to give a specific example that is not what I mention, but the spec seems to allow for it between the above and the following: ``` authors should not expect to exercise any control over the precise rendering of their text lines, only of their actual textual content. ```

makeworld commented

2020-05-27 14:35:45 +00:00

Ah okay, I see what you mean.

👍 1

raidancampbell referenced this issue

2022-02-10 05:53:23 +00:00

Better word wrapping #214

Sign in to join this conversation.