`end_of_line = lf` prevents the entire `.editorconfig` from loading

[nonk123]

Sample file:

root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true
indent_style = space

Running editorconfig-apply and checking editorconfig-display-current-properties produces a buffer with just this comment:

# EditorConfig for c:/Users/Administrator/AppData/Roaming/.emacs.d/.editorconfig

The following config (without end_of_line) applies properly though:

root = true

[*]
charset = utf-8
insert_final_newline = true
trim_trailing_whitespace = true
indent_style = space

# EditorConfig for c:/Users/Administrator/AppData/Roaming/.emacs.d/.editorconfig
charset = utf-8
insert_final_newline = true
trim_trailing_whitespace = true
indent_style = space

Any ideas? end_of_line = lf is in the first codeblock on the editorconfig website, so I would assume it's a correct example.

[monnier]

I cannot reproduce it here with Emacs-30:

emacs -Q -f editorconfig-mode ~/tmp/ec/foo.txt
M-x editorconfig-apply RET
M-x editorconfig-dis RET

shows me:

# EditorConfig for .../tmp/ec/foo.txt
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true
indent_style = space

[nonk123]

Whoops, was in a bit of a hurry to post this. Will provide more info once back from work.

…

On Wed, Nov 19, 2025, 17:21 monnier ***@***.***> wrote: *monnier* left a comment (editorconfig/editorconfig-emacs#380) <#380 (comment)> I cannot reproduce it here with Emacs-30: emacs -Q -f editorconfig-mode ~/tmp/ec/foo.txt M-x editorconfig-apply RET M-x editorconfig-dis RET shows me: # EditorConfig for .../tmp/ec/foo.txt charset = utf-8 end_of_line = lf insert_final_newline = true trim_trailing_whitespace = true indent_style = space — Reply to this email directly, view it on GitHub <#380 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKOPXIZLQHADJKUCTTJZ64T35R4INAVCNFSM6AAAAACMRCMNV6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNJSHE3DSOBTHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[nonk123]

GNU/Emacs 30.2 on Windows 10. Full M-x version output:

GNU Emacs 30.2 (build 2, x86_64-w64-mingw32)
 of 2025-08-14

Same .editorconfig as in the original post. Running emacs -Q -f editorconfig-mode foo.txt, then M-x editorconfig-apply (it didn't apply automatically for some reason?) and M-x editorconfig-display-current-properties produces:

# EditorConfig for c:/Users/Administrator/tmp/foo.txt

In the same session, removing the end_of_line = lf line from the original .editorconfig and re-applying, M-x editorconfig-display-current-properties produces:

# EditorConfig for c:/Users/Administrator/tmp/foo.txt
charset = utf-8
insert_final_newline = true
trim_trailing_whitespace = true
indent_style = space

Exactly the same result with both the built-in editorconfig package and this repo's master branch.

What could possibly be going on here?

[nonk123]

Even weirder is that end_of_line = crlf works fine. Same config as above sans end_of_line, running M-x editorconfig-display-current-properties in my current Emacs setup produces:

# EditorConfig for c:/Users/Administrator/AppData/Roaming/.emacs.d/.editorconfig
charset = utf-8
end_of_line = crlf
insert_final_newline = true
trim_trailing_whitespace = true
indent_style = space

[nonk123]

Some digging around in the code later, I found out it's a line-ending issue in the .editorconfig file itself. Using \r\n in the file with end_of_line set to lf breaks its parsing somehow. At the same time, using \n parses correctly for both end_of_line set to crlf or lf.

[monnier]

Aha! Yes, now I can reproduce it here.
I think it's acceptable for editorconfig to "misbehave" in such an inconsistent configuration, but it should at least emit some warning about the fact that it's not able to parse the file.

[nonk123]

Thanks for taking your time to look at this!

Just to add more to this discussion: the Editorconfig extension for VSCode parsed the original .editorconfig (with \r\n line endings) just fine. Not really sure what it does differently from this one.