As discussed in that issue, I don't think this is going to be enough #3542 (comment)

Can you test it in both the linked files and include a screenshot and URLs you tested like requested by the PR template?

Here are the screen shots from the two links on the comment above, with manual changes to the style:

Here, no style is added by ghr, hence single line:

Here, no style is added by ghr, but gh adds its own, hence soft-line wrap controlled by gh:

(sorry for the terseness...)

I checked too and it appears to match GitHub’s native wrapping in both cases.

Screenshots in order: master, this PR, native GitHub

Screenshots in order: master, this PR, native GitHub (here the wrapping is slightly different because tabs are 8 chars instead of 4)

(this kind of comparative screenshot is what's needed to visualize and verify the change)

some times forced soft-line-wrap is a desirable feature

We used to have this feature, but it was rather complicated #1989 and we had to drop it #2729. Is that what you had in mind?

Screenshots in order: master, this PR, native GitHub

This screenshot in the middle looks kinda off, if the spaces at the end stay on the same line, we get a scrollbar (intended when there is no .soft-wrap class added by GH), but the | is also supposed to be on the same line at the very end.

If we do not see any scrollbar here in this screenshot then the whitespaces at the end are either getting clipped or collapsed, which I see from screenshots is the same happening with native GH styles (because HTML collapses consecutive spaces by default).

Then the question here would be should spaces at the end be collapsed, as per HTML spec, or have spaces preserved and wrapped considering the content as computer code, similar to what VSCode does (see screenshot below)?

If we do take stuff around this specific piece of code as context, then the first line here has spaces collapsed, but the second line has it's hypens (-) preserved and wrapped to a new line (as they are considered a "word"), pushing the pipe (|) at the end to the center of the wrapped line.

Whereas the first line has its pipe character at the start of the wrapped line. Which brings us back to the same question above if we have to consider spaces as "words" and not collapse them.

@gcbw in any case, was #3542 (comment) considered, was anything missing from that?

This feature is show-whitespace, it should not affect wrapping in any case, as #3542 suggested. Wrapping would be a separate feature, maybe #2729

If this PR restores the wrapping behavior to exactly how it is without Refined GitHub, then it's correct. In my few tests, it looks like it does.

It'd be great to test more views: commits, PRs, unified diffs, split diffs, embedded code links, PR code suggestions, etc.

was #3542 (comment) considered, was anything missing from that?

No it was not, as I did not want to delve too much into fixing GH problems. I focused on removing side-effect from GHR instead.

The cases i had in mind was regular code, where you actually do scroll left-right as needed, but keep the line flow as intended.

Seeing the images that fregant kindly provided, I actually like the "bug" from GH. ...the ... | pattern is really odd and i hope to never find it in real life :), but it is actually nice to see the content soft-wraped into a new line to differentiate cases where you are just seeing a bunch of tailing spaces vs something hidden that could have been missed if you don't scroll right.

So I guess it's a win-win to not fix GH bug on this. (still would like to have the option to toggle soft line break as an option for people with small screens though, just do not think whitespace should depend on it as it is now)

If this PR restores the wrapping behavior to exactly how it is without Refined GitHub, then it's correct. In my few tests, it looks like it does.

Makes sense.

Seeing the images that fregant kindly provided, I actually like the "bug" from GH. ...the ... | pattern is really odd and i hope to never find it in real life :), but it is actually nice to see the content soft-wraped into a new line to differentiate cases where you are just seeing a bunch of tailing spaces vs something hidden that could have been missed if you don't scroll right.

As the spaces getting collapsed is a "bug" from GH, this PR would be fine.

It would be up to the person working on #2729 to make sure that styles don't get mixed up between these features (like cases when one feature breaks when the other feature is not enabled).

Thanks @gcbw!