Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove final newline from rendered code #18076

Closed
wants to merge 3 commits into from

Conversation

silverwind
Copy link
Member

@silverwind silverwind commented Dec 22, 2021

#16678 introduced rendering of the final newline in files but I feel this rendering is not useful and just distracting. Omit rendering this empty line which matches GH behaviour in both rendering and copied content (no final newline copied, tested in Chrome and Firefox).

Before:
image

After:
image

@silverwind silverwind added this to the 1.16.0 milestone Dec 22, 2021
@silverwind silverwind added the type/enhancement An improvement of existing functionality label Dec 22, 2021
@zeripath
Copy link
Contributor

If you do not want to render the final line you need to add a character to mark when there is not a terminal newline.

The lack of the terminal newline when copying from github is a bug on their behalf IMO.

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Dec 22, 2021
@silverwind
Copy link
Member Author

silverwind commented Dec 22, 2021

If you do not want to render the final line you need to add a character to mark when there is not a terminal newline.

Such marking is only present on diffs on GH, and I agree we should probably replicate but I don't see it related here.

The lack of the terminal newline when copying from github is a bug on their behalf IMO.

It feels awkward to me to copy something that isn't visible. What we could do instead is have a button in the file header to copy the file contents, which then would accurately copy with or without final newline. Personally, I prefer to copy without final newlines in any case.

@silverwind
Copy link
Member Author

silverwind commented Dec 22, 2021

Oh I just noticed it depends on how the text selection is started on whether the final newline (which is still present on the last line) is copied in Chrome:

On line-triple-click it is selected (notice area on the right of the text):

image

On multi-line-select it won't be selected:

image

Behaviour again matches GH, I think it's sufficient. Later on we can add a full-file copy button to work around such browser issues.

@zeripath
Copy link
Contributor

Github's non rendering of the final line is inconsistent and confusing.

View

Screenshot from 2021-12-23 01-31-14

Edit

Screenshot from 2021-12-23 01-31-35

Local editor

Screenshot from 2021-12-23 01-34-00

@zeripath
Copy link
Contributor

What's the purpose of the View screen? It's supposed to look like the editor. Therefore the terminal new line should be there.

@silverwind
Copy link
Member Author

While editing, I think it's important to have a faithful representation but while viewing I think the final newline is not important. While copying, I also don't like having it there because I usually have to delete it after pasting.

wxiaoguang
wxiaoguang previously approved these changes Jan 4, 2022
Copy link
Contributor

@wxiaoguang wxiaoguang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think what this PR does is fine, just keep things as it is.

@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Jan 4, 2022
@lunny
Copy link
Member

lunny commented Jan 4, 2022

Assume two files with almost same content, but one end with newline, and another with no newline at the end. This PR will make the the same result in the UI. But in fact, they have difference.

@6543
Copy link
Member

6543 commented Jan 4, 2022

vote for #18076 (comment)

@6543 6543 modified the milestones: 1.16.0, 1.17.0 Jan 4, 2022
@6543
Copy link
Member

6543 commented Jan 4, 2022

indicate it in a different way is also fine - but this pull is not ready for v1.16.0 ... - moved

@Gusted
Copy link
Contributor

Gusted commented Jan 4, 2022

This PR will make the the same result in the UI. But in fact, they have difference.

Doesn't gitea show a error symbol when there is no new line at the end of the file? That should be the difference.

@silverwind
Copy link
Member Author

Doesn't gitea show a error symbol when there is no new line at the end of the file? That should be the difference.

We don't have such a feature yet. GH has it on diffs only.

For example a PR that removes the newline: https://try.gitea.io/silverwind/symlink-test/pulls/2/files

I guess it might be possible to add a subtle indicator to the final line if there is now newline in the file view, but I'm not sure many people really care about such meaningless whitespace to warrant even having it.

@Gusted
Copy link
Contributor

Gusted commented Jan 7, 2022

We don't have such a feature yet. GH has it on diffs only.

I meant that such symbol should be the difference for diffs, as I've personally worked with certain files that required new lines and for code-review it's nice to have such feature. But for normal file viewing, the final newline is useless.

So from my understanding now, the diff already don't show if the newline? In that case you can disregard my comment as that's my only concern.

@singuliere
Copy link
Contributor

my vote is for not trimming the final newline from display

@silverwind
Copy link
Member Author

silverwind commented Jan 12, 2022

From a correctness standpoint, it's better to not trim it. But I would still prefer it because I'm just so used to GitHub's trimming on code view. Maybe it has to be made an user option.

@stale
Copy link

stale bot commented Apr 28, 2022

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 months. Thank you for your contributions.

@stale stale bot added the issue/stale label Apr 28, 2022
@silverwind
Copy link
Member Author

Should probably make this an config option.

@silverwind
Copy link
Member Author

Added a config option, defaulting to final newline being hidden as that's how GitHub, GitLab and raw view in browser display it so I think most users would expect that behaviour.

Comment on lines 195 to 198
finalNewLine := false
if len(code) > 0 {
if !setting.UI.HideFinalNewline && len(code) > 0 {
finalNewLine = code[len(code)-1] == '\n'
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a) these four lines can be shortened to a single line because we are only using booleans here (GitHub doesn't let me make a suggestion for some reason...)
b) I think a comment would be nice, that method is already large enough and could use some structuring so that you don't become confused on what has happened already, and what has yet to happen.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would that single line be? It's not obvious to me

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

finalNewLine := !setting.UI.HideFinalNewline && len(code) > 0 && code[len(code)-1] == '\n'

Comment on lines -56 to -57
`<span class="w">
</span>`,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also add a test where we test for the behavior if there is a newline, and HIDE_FINAL_NEWLINE = false?

Copy link
Member Author

@silverwind silverwind May 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure whether these kind of tests should be extended because the output of go test is a major pain to work with in case of string arrays. It took me like 10 minutes to figure out what to change to get the test to pass.

Maybe if it were to test a single multiline detented string, it would be easier to work with. I can check later what can be done to make these tests easier to work with.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some test improvments in #19798, so I will revisit here after that one is merged.

@6543
Copy link
Member

6543 commented May 24, 2022

From a correctness standpoint, it's better to not trim it. But I would still prefer it because I'm just so used to GitHub's trimming on code view. Maybe it has to be made an user option.

I'm fine with that - but I would by default make it false

@silverwind
Copy link
Member Author

silverwind commented May 24, 2022

From a correctness standpoint, it's better to not trim it. But I would still prefer it because I'm just so used to GitHub's trimming on code view. Maybe it has to be made an user option.

I'm fine with that - but I would by default make it false

Issues like #19766 show users generally expect the GH/GL-style rendering. Trailing newlines are almost never significant, why show them by default?

@silverwind
Copy link
Member Author

Waiting on #19798 to merge before continuing here.

@lunny
Copy link
Member

lunny commented Jun 11, 2022

Please resolve the conflicts

@UnlimitedCookies
Copy link

I would also argue to default to false, for all previously mentioned reasons. Currently, it seems like this is only a server-wide setting. As you might imagine, just like the preferences of the Gitea maintainers in this thread differ, so they might differ among people using the same instance. So I would suggest adding a toggle in the personal preferences (maybe under mygitea.com/user/settings/appearance). Perhaps in the future, Gitea might add more customization options).

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Sep 8, 2022
@wxiaoguang
Copy link
Contributor

ping @silverwind , is this still needed?

@silverwind
Copy link
Member Author

For me, I'm happy with current behaviour of removing final newline, but I guess this PR still has value in adding the option so people like @zeripath can configure to show it again. But I will reject changing the default to show it.

@wxiaoguang
Copy link
Contributor

Current approach is clear for files with or without the last new line.

Just one line without last new line: 1 line:
image

With last new line: 2 lines:
image

In the future, if some people really want to see the "No New Line" difference, the files without last new line could have a non-copyable icon at the ending: 🚫 but no more configurable option again:

image

I would prefer to avoid unnecessary options as much as possible. So if there is no strong requirements (in 1 week), I think we can close this PR.

@wxiaoguang wxiaoguang added issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels Sep 23, 2022
@silverwind
Copy link
Member Author

Yeah, let's close it. 🚫 in diffs would indeed be a nice feature to have.

@silverwind silverwind closed this Sep 25, 2022
@silverwind silverwind deleted the newline branch September 25, 2022 11:34
@lunny lunny removed this from the 1.18.0 milestone Dec 20, 2022
@go-gitea go-gitea locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. type/enhancement An improvement of existing functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants