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

@wxiaoguang commented on GitHub (Oct 1, 2023):

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

@wxiaoguang commented on GitHub (Oct 1, 2023): 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`

GiteaMirror commented

@ell1e commented on GitHub (Oct 1, 2023):

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.

@ell1e commented on GitHub (Oct 1, 2023): > 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.

GiteaMirror commented

@wxiaoguang commented on GitHub (Oct 1, 2023):

\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.

@wxiaoguang commented on GitHub (Oct 1, 2023): `\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.

GiteaMirror commented

2025-11-02 09:46:53 -06:00

@ell1e commented on GitHub (Oct 1, 2023):

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. 🌸 )

@ell1e commented on GitHub (Oct 1, 2023): > 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. :cherry_blossom: )*

GiteaMirror commented

@wxiaoguang commented on GitHub (Oct 1, 2023):

. 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 https://github.com/go-gitea/gitea/pull/19967#issuecomment-1184115968 .

@wxiaoguang commented on GitHub (Oct 1, 2023): > . 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 https://github.com/go-gitea/gitea/pull/19967#issuecomment-1184115968 .

GiteaMirror commented

2025-11-02 09:46:53 -06:00

@ell1e commented on GitHub (Oct 1, 2023):

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 commented on GitHub (Oct 1, 2023): > 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.

GiteaMirror commented

2025-11-02 09:46:53 -06:00

@ell1e commented on GitHub (Oct 1, 2023):

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:

@ell1e commented on GitHub (Oct 1, 2023): ![Screenshot from 2023-10-01 16-56-25](https://github.com/go-gitea/gitea/assets/64124388/e57a2b35-65b7-43f6-b8ad-ee33e20275ae) 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: ![](https://user-images.githubusercontent.com/64124388/271822798-ddb72740-1b6d-4b0a-b654-10156beb0848.png)

GiteaMirror commented

2025-11-02 09:46:54 -06:00

@wxiaoguang commented on GitHub (Oct 1, 2023):

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:

@wxiaoguang commented on GitHub (Oct 1, 2023): 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: ![image](https://github.com/go-gitea/gitea/assets/2114189/eb325d94-afe3-40a7-837b-817a551f7981)

GiteaMirror commented

2025-11-02 09:46:54 -06:00

@ell1e commented on GitHub (Oct 1, 2023):

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.

@ell1e commented on GitHub (Oct 1, 2023): 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.

GiteaMirror commented

2025-11-02 09:46:54 -06:00

@wxiaoguang commented on GitHub (Oct 1, 2023):

Gitea is also designed for cross-platform. And personally I consider VSCode is right, vim is right, notepad is right, no one is incorrect, they just have their quirks.

Anyway, the problem is open, while personally I do think current approach is good enough. Feel free to propose new rules and PRs.

@wxiaoguang commented on GitHub (Oct 1, 2023): Gitea is also designed for cross-platform. And personally I consider VSCode is right, vim is right, notepad is right, no one is incorrect, they just have their quirks. Anyway, the problem is open, while personally I do think current approach is good enough. Feel free to propose new rules and PRs.

GiteaMirror commented

@ell1e commented on GitHub (Oct 1, 2023):

I did some quick mockups to show what I think the correct behavior would look like.

File view unix.c fixed:

Edit view unix.c fixed:

File view windows.c fixed:

Edit view windows.c fixed (was already correct):

@ell1e commented on GitHub (Oct 1, 2023): I did some quick mockups to show what I think the correct behavior would look like. File view `unix.c` fixed: ![Screenshot from 2023-10-01 17-03-18](https://github.com/go-gitea/gitea/assets/64124388/9279ce5d-ec05-43b3-85a7-c4597d9f4923) Edit view `unix.c` fixed: ![Screenshot from 2023-10-01 17-06-05](https://github.com/go-gitea/gitea/assets/64124388/8580ff0f-002b-4ce3-8bf8-528fd2088795) File view `windows.c` fixed: ![Screenshot from 2023-10-01 17-00-46](https://github.com/go-gitea/gitea/assets/64124388/9bc8ac94-cba5-4431-851f-7693aadd2ba4) Edit view `windows.c` fixed (was already correct): ![Screenshot from 2023-10-01 17-05-23](https://github.com/go-gitea/gitea/assets/64124388/080b6523-511f-4bc5-b830-f1c5e6b72f85)

GiteaMirror commented

@ell1e commented on GitHub (Oct 1, 2023):

Well, one last comment but in my opinion it's pretty telling: VS Code was created by Microsoft who primarily deal with windows, and surprise (or rather, not surprise) it shows the \n non-Windows files wrongly. VIM was created on Unix, and shows \r\n files wrong. In my opinion, the only rule that makes sense is to make it display what the native established editors and tools do, as found on the platform native to the line ending type.

There is no other way to make it more consistent. You'll always find some special editors, especially the cross-platform ones that originated on a different platform, that will show some platform's file endings slightly incorrect. Simply because this is a pretty common bug.

I'm just trying to help out getting it fixed, I understand that a lot of programs get this wrong.

@ell1e commented on GitHub (Oct 1, 2023): Well, one last comment but in my opinion it's pretty telling: VS Code was created by Microsoft who primarily deal with windows, and surprise (or rather, not surprise) it shows the `\n` non-Windows files wrongly. VIM was created on Unix, and shows `\r\n` files wrong. In my opinion, the only rule that makes sense is to make it display what the **native** established editors and tools do, as found on the **platform native to the line ending type**. There is no other way to make it more consistent. You'll always find some special editors, especially the cross-platform ones that originated on a different platform, that will show some platform's file endings slightly incorrect. Simply because this is a pretty common bug. I'm just trying to help out getting it fixed, I understand that a lot of programs get this wrong.

GiteaMirror commented

@wxiaoguang commented on GitHub (Oct 1, 2023):

VS Code was created by Microsoft who primarily deal with windows, and surprise (or rather, not surprise) it shows the \n non-Windows files wrongly.

That's not true. All modern editors have consistent behavior: treating "\n" or "\r\n" as EOL. They are the same.

VIM was created on Unix, and shows \r\n files wrong.

VIM just has too many technical debts, it just doesn't want to change its behavior for handling "\r"

the only rule that makes sense is to make it display what the native established editors and tools do, as found on the platform native to the line ending type

Have you considered about a file which contains both \n and \r\n?

There is no other way to make it more consistent. You'll always find some special editors, especially the cross-platform ones that originated on a different platform, that will show some platform's file endings slightly incorrect. Simply because this is a pretty common bug.

It is consistent for modern editors treating "\r\n" and "\n" equivalently.

And have you tried the Linux world famous editor emacs?

@wxiaoguang commented on GitHub (Oct 1, 2023): > VS Code was created by Microsoft who primarily deal with windows, and surprise (or rather, not surprise) it shows the `\n` non-Windows files wrongly. That's not true. All modern editors have consistent behavior: treating "\n" or "\r\n" as EOL. They are the same. > VIM was created on Unix, and shows `\r\n` files wrong. VIM just has too many technical debts, it just doesn't want to change its behavior for handling "\r" > the only rule that makes sense is to make it display what the native established editors and tools do, as found on the platform native to the line ending type Have you considered about a file which contains both `\n` and `\r\n`? > There is no other way to make it more consistent. You'll always find some special editors, especially the cross-platform ones that originated on a different platform, that will show some platform's file endings slightly incorrect. Simply because this is a pretty common bug. It is consistent for modern editors treating "\r\n" and "\n" equivalently. And have you tried the Linux world famous editor emacs? ![image](https://github.com/go-gitea/gitea/assets/2114189/bc95a58b-8f6c-43fc-84dd-469ac2eaeb38)

GiteaMirror commented

2025-11-02 09:46:56 -06:00

@eeyrjmr commented on GitHub (Oct 1, 2023):

That standard behaviour when using git on windows is during the install is to select the option with the most compatibility

"Checkout Windows-Style, Commit Unix-Style line endings"

The moment you have cross-OS users committing to the same repository this is the PRIMARY option that windows users MUST select to keep the repository in a sane consistent state between users.

Can you confirm you have this set ( core.autocrlf = true )

@eeyrjmr commented on GitHub (Oct 1, 2023): That standard behaviour when using git on windows is during the install is to select the option with the most compatibility "Checkout Windows-Style, Commit Unix-Style line endings" The moment you have cross-OS users committing to the same repository this is the PRIMARY option that windows users MUST select to keep the repository in a sane consistent state between users. Can you confirm you have this set ( core.autocrlf = true )

GiteaMirror commented

@ell1e commented on GitHub (Oct 1, 2023):

All modern editors have consistent behavior: treating "\n" or "\r\n" as EOL. They are the same.

You're not saying what EOL means, I suspect you mean line separator, so actually not EOL/end of line?

Beyond vim and GNOME Text editor, it's all the basic command line tools like cat, wc -l, and so on that also all think that \n is a line terminator, not a separator, for Unix/Linux files. I feel like maybe the basic core tools have more weight. Emacs seems to have been based on a cross-platform one as well rather than one written originally for Unix primarily, so I feel like it doesn't count. Otherwise at least make it consistent, gitea file view violates that. Edit: shortened for brevity.

@eeyrjmr this isn't really related, I think. Open the files in a hex editor for the byte contents.

@ell1e commented on GitHub (Oct 1, 2023): > All modern editors have consistent behavior: treating "\n" or "\r\n" as EOL. They are the same. You're not saying what EOL means, I suspect you mean line *separator*, so actually not EOL/end of line? Beyond vim and GNOME Text editor, it's all the basic command line tools like `cat`, `wc -l`, and so on that also all think that `\n` is a line terminator, not a separator, for Unix/Linux files. I feel like maybe the basic core tools have more weight. Emacs seems to have been based on a cross-platform one as well rather than one written originally for Unix primarily, so I feel like it doesn't count. Otherwise at least make it consistent, gitea file view violates that. Edit: shortened for brevity. @eeyrjmr this isn't really related, I think. Open the files in a hex editor for the byte contents.

GiteaMirror commented

2025-11-02 09:46:56 -06:00

@ell1e commented on GitHub (Oct 1, 2023):

After some more thinking, I guess I can see a point for going with a modern same interpretation.

@ell1e commented on GitHub (Oct 1, 2023): After some more thinking, I guess I can see a point for going with a modern same interpretation.

GiteaMirror commented

2025-11-02 09:46:56 -06:00

@wxiaoguang commented on GitHub (Oct 1, 2023):

I feel like maybe the basic core tools have more weight with being correct than all these modern cross-platform editors that may have cared less about getting such details right?

There is no standard in "basic core" either. You see:

$ echo -n a > a.txt
$ wc -l a.txt
0 a.txt
# while "vim a.txt" still shows 1 line

There is no standard, no official rule.

Emacs seems to have been based on a cross-platform one as well rather than one written originally for Unix primarily, so I feel like it doesn't count.

According to various public information, emacs was initially designed for POSIX, the native tool.

gitea violates this on the file view

Since there is no standard, then no violation.

@wxiaoguang commented on GitHub (Oct 1, 2023): > I feel like maybe the basic core tools have more weight with being correct than all these modern cross-platform editors that may have cared less about getting such details right? There is no standard in "basic core" either. You see: ``` $ echo -n a > a.txt $ wc -l a.txt 0 a.txt # while "vim a.txt" still shows 1 line ``` There is no standard, no official rule. > Emacs seems to have been based on a cross-platform one as well rather than one written originally for Unix primarily, so I feel like it doesn't count. According to various public information, emacs was initially designed for POSIX, the native tool. > gitea violates this on the file view Since there is no standard, then no violation.

GiteaMirror commented

@eeyrjmr commented on GitHub (Oct 1, 2023):

@ell1e it is related though as this is the correct mitigation.
The bare git repository (irrespective of the forge) must be consistent and that is why on windows gitforwin recommends (checkout windows, checkin unix) as this way the bare host, linux checkout and windows checkout all appear consistent.

There is no standard except at the OS level and thus it must be mitigated. Sure some editors will fluff this to appear "consistent" but it doesn't change what is at byte level

@eeyrjmr commented on GitHub (Oct 1, 2023): @ell1e it is related though as this is the correct mitigation. The bare git repository (irrespective of the forge) must be consistent and that is why on windows gitforwin recommends (checkout windows, checkin unix) as this way the bare host, linux checkout and windows checkout all appear consistent. There is no standard except at the OS level and thus it must be mitigated. Sure some editors will fluff this to appear "consistent" but it doesn't change what is at byte level

GiteaMirror commented

@ell1e commented on GitHub (Oct 1, 2023):

Why are you using echo -n? That explicitly strips the last \n so that'll give you a wrong result.

emacs was initially designed for POSIX, the native tool.

emacs was apparently based on the TECO editor which wasn't for primarily POSIX or Unix, if i'm not reading it wrong. Maybe it kept the different handling for compatibility, I wouldn't know.

@ell1e commented on GitHub (Oct 1, 2023): Why are you using `echo -n`? That explicitly strips the last `\n` so that'll give you a wrong result. > emacs was initially designed for POSIX, the native tool. emacs was apparently based on the TECO editor which wasn't for primarily POSIX or Unix, if i'm not reading it wrong. Maybe it kept the different handling for compatibility, I wouldn't know.

GiteaMirror commented

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206

@ell1e commented on GitHub (Oct 1, 2023):

After some searching I found that POSIX actually seems to define it, so there even is a standard:

3.206 Line

A sequence of zero or more non- characters plus a terminating character.

That makes "aejiaelira this file is a single line\n" 1 line. Does this help? I hope that windows.c is 3 is undisputed.

@ell1e commented on GitHub (Oct 1, 2023): After some searching I found that POSIX actually seems to define it, so there even is a standard: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206 > 3.206 Line > > A sequence of zero or more non- <newline> characters plus a terminating <newline> character. That makes `"aejiaelira this file is a single line\n"` 1 line. Does this help? I hope that `windows.c` is 3 is undisputed.

GiteaMirror commented