Revert "Fix EOL handling in web editor"

[lng2020]

Reverts #27141
close #28097

[silverwind]

I can't accept a full revert, the editorconfig detection has to stay, that is valuable in any case.

Also the linked issue seems odd, unless monaco uses browser OS, in which case we should override it to LF for cases with no .editorconfig and add a ini setting for it.

[wxiaoguang]

This behavior already effects end users.

If there is no quick fix (eg: in 1 or 2 days), let's revert it to old behavior. Then you have enough time to propose a new fix.

[silverwind]

It's a trivial fix, I will provide soon. That's assuming the current behaviour can even be considered "broken", I think monaco is doing the sensible thing by defaulting to user's platform, thought I guess in terms of git content, more users prefer LF.

[silverwind]

#28119

[wxiaoguang]

#28119 is not right. Will merge this reverting PR in 1 day.

[silverwind]

I'm strongly against this because it removes editorconfig support.

[wxiaoguang]

I'm strongly against this because it removes editorconfig support.

No, it doesn't "remove editorconfig support" because #27141 is not right either. Actually:

• Before #27141: all edited files are stored as \n, few users complain.
• After #27141: all edited files are stored as \r\n, many users complain.

I have explained above: if there is no quick fix, reverting is the best choice.

[wxiaoguang]

@silverwind the last call for the merge in 12h, if you still have objection, please show a real case to help understanding the "problem" you are worrying about.

[lunny]

I'm strongly against this because it removes editorconfig support.

But it broke many users' online editors. I was surprised when I edit a readme and only add one new line then all lines were changed with no warning until I take a look at diff.

[silverwind]

The only "necessary" revert is this line which previously did the replacement on the server:

https://github.com/go-gitea/gitea/pull/27141/files#diff-898533f7342f43a8390c353ae398fa85578aaa93667b3ff99a5dd889c048e1c7L290

Ideally we should just convert line endings based on the new server pref.

[silverwind]

In #28119, I added server-side convertion in e58dcc0, this will always be correct, no matter what format the client side delivers.

[silverwind]

Revert if you want a quick fix. I guess I will then make another PR the cherry-picks #27141 and #28119 in that sequence which can then land only on 1.22.