Gitea file view showing wrong amount of lines for both Unix and Windows/DOS line breaks but differently

[ell1e]

Description

(I was occasionally abrasive in some comments, I apologize. 🌸 )

Gitea shows a wrong amount of lines for both Unix and Windows/DOS line breaks in the web UI in both edit and code view, and in a very different and inconsistently wrong manner.

• https://try.gitea.io/blablablablab/BlaTest/src/branch/main/unix.c This file has one line. A unix \n semantically terminates the previous line, so if a file ends in \n then that means no line is coming after. Code view shows 1 line 🆗 correctly, but the "Edit" button shows 2 lines 🚫 wrongly.

  The Unix line break file authoritatively shown by Unix file editor vim, clearly just one line:
  

• https://try.gitea.io/blablablablab/BlaTest/src/branch/main/windows.c This file has three lines. A Windows/DOS \r\n semantically separates two lines, so if a file ends in \r\n then that means a blank line is coming after. Code view shows 2 lines 🚫 wrongly, but the "Edit" button shows 3 lines 🆗 correctly.

  The Windows/DOS line break file authoritatively shown by Windows file editor notepad.exe, clearly three lines:
  

⚠️ Please note most Unix code editors get Windows/DOS line breaks wrong, including vim and the wc -l command, which counts line breaks characters and not lines, so it doesn't give correct line counts for Windows/DOX files. Get the correct lines displayed reliably: always check Windows/DOS \r\n line break files with notepad.exe on Windows, and always check Unix \n line break files with vim on Linux to show the correct amount of lines there. Or check with a hex editor what's really going on per file.

Gitea Version

1.22.0+dev-74-g4ab597f47

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

whatever is used on try.gitea.io

Operating System

whatever is used on try.gitea.io

How are you running Gitea?

it's on try.gitea.io

Database

None

[wxiaoguang]

The behavior has been documented in code:

And see:

• Rework file highlight rendering and fix yaml copy-paste #19967 (comment)

[ell1e]

Well all I can say is that it's wrong on 1.22.0+dev-74-g4ab597f47, at the exact locations and with the exact files I described and also linked above. I suggest to click the links and see for yourself, that should show it very well.

(Note added later: I was occasionally abrasive in some comments, I apologize. 🌸 )

[wxiaoguang]

~$ curl -s https://try.gitea.io/blablablablab/BlaTest/raw/branch/main/unix.c | xxd
00000000: 6165 6a69 6165 6c69 7261 2074 6869 7320  aejiaelira this
00000010: 6669 6c65 2069 7320 6120 7369 6e67 6c65  file is a single
00000020: 206c 696e 650a                            line.

According to the definition, it has two lines, the second line is an empty line.

~$ curl -s https://try.gitea.io/blablablablab/BlaTest/raw/branch/main/windows.c | xxd
00000000: 0d0a 6162 6320 7468 6973 2066 696c 6520  ..abc this file
00000010: 6973 2033 206c 696e 6573 0d0a            is 3 lines..

According to the definition, it has three lines, the first line is empty, the third line is empty.

---

Everything is as expectation.

[wxiaoguang]

The reason for using 2 lines but not 1 line for a\n:

• This is the only way to distinguish content a (1 line) and a\n (2 lines) at the moment.
• Otherwise, if you see 1 line for a\n, you won't be able to know whether there is a trailing \n

[ell1e]

According to the definition, it has two lines, the second line is an empty line.

The hex dump you gave for the first file ends in 0x65 0x0A as you can see yourself, which is equivalent to an ending of "e\n". There is no other line break in that hex dump. Therefore no, it's one line, ending in a Unix line terminator which is how Unix line terminators work. (I didn't make the rules.) So this file is 1 line. Edit: sorry, had the wrong number here at first.

In your second hex dump, you can see two instances of 0x0d 0xDA, which is equivalent to "\r\n". Two line separators, which splits the file into three lines, according to how Windows line separators work. So this file is 3 lines.

It's how these files natively work on the respective systems. Therefore, either the code view, or the edit view, is wrong on both of these files in some circumstances, and the line count you posted for the first file is wrong as well. Also in your own screenshot, the third file shows as "3 lines", yet only 2 are shown in the listing below, which seems incorrect.

[wxiaoguang]

\n in POSIX is equivalent to \r\n in Windows, they are all EOL.

So if you can accept that the windows.c has 3 lines, I think you could also accept that the unix.c has 2 lines.

The rules are open. You could propose your rules and PRs to improve the behavior, if most people like, and the content a/a\n could be distinguished clearly.

[ell1e]

This is the only way to distinguish content a (1 line) and a\n (2 lines) at the moment.

According to Unix file semantics, I'm pretty sure these are both considered 1 line. The first one would be an incorrectly unterminated single line, but nevertheless, these are both just 1 line. I think GitHub shows some sort of icon to the side if the terminator for Unix files is incorrectly missing.

(Note added later: I was occasionally abrasive in some comments, I apologize. 🌸 )

[wxiaoguang]

. I think GitHub shows some sort of icon to the side if the terminator for Unix files is incorrectly missing.

That's also what I have proposed in #19967 (comment) .

[ell1e]

So if you can accept that the windows.c has 3 lines, I think you could also accept that the unix.c has 2 lines.

I showed the screenshot. \n on Linux is considered a line terminator, so no new line is considered to start after it, you can see this in vim.

On Windows, \r\n is considered a line separator, see in notepad.exe.

It's just what some people making these systems decided on, so it's really not my fault.

[ell1e]

Maybe this helps, in GNOME's gedit text editor on Linux it's easier to see that it also considers this file just 1 line. (The file ending in \n as a Unix line terminator.) This is for unix.c.

And Notepad.exe should be considered authoritative and hopefully easy to see on Windows as well that it has 3 lines for the windows.c file, here it is again:

[wxiaoguang]

I do not understand how "vim" / "gedit" / "notepad" could be considered as "standard". They just have their quirks.

Have you tried VSCode? As a developer, I like VSCode's behavior more:

[ell1e]

VS Code is incorrect, which is why I showed the native, established editors for each respective platform. Most cross-platform editors (like VS Code) handle one of the two platforms incorrectly.