Error while getting .editorconfig file

[somera]

Description

I found this message in /admin/notices

Error while getting .editorconfig file: normalization error: insert_final_newline=off is not an acceptable value. strconv.ParseBool: parsing "off": invalid syntax

Nothing founded in gitea.log.

Gitea Version

1.17.0

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

Git Version

2.25.1

Operating System

Ubuntu 20.04.4

How are you running Gitea?

Downloaded gitea-1.17.0-linux-amd64

Database

PostgreSQL

[silverwind]

It should be true, false or unset. Best course of action is to fix the .editorconfig file. I guess it's good to see such errors somewhere instead of silently ignoring them, so I'd say it's working as intended.

[somera]

Is this an gitea internal error? Error from the update mirror task?

[wxiaoguang]

It's reported by "editorconfig.Parse", which is called by SetEditorconfigIfExists when you browses the repo commits.

The problem is that you have invalid syntax in your .editorconfig

[somera]

It's reported by "editorconfig.Parse", which is called by SetEditorconfigIfExists when you browses the repo commits.

The problem is that you have invalid syntax in you .editorconfig

I found this: https://github.com/go-gitea/gitea/blob/main/.editorconfig

But in my gitea setup I can't find any .editorconfig.

[wxiaoguang]

It's in your repository. It's a user file, committed by some user into your repository.

[somera]

Its in your repository. Its a user file, committed by some user into your repository.

Ach o.k. That must be one of the mirrors. In this case I can't fix it.

[wxiaoguang]

So maybe the proposal could be: "Make Gitea not report user's editorconfig syntax error as repository notice", or only show the syntax error on the proper page clearly.

[silverwind]

We should probably treat values with such errors the same as unset. Maybe also show it in the repo/file view, but I think it's generall unnecessary.

[Gusted]

We should probably treat values with such errors the same as unset. Maybe also show it in the repo/file view, but I think it's generall unnecessary.

Well, we can ignore the error, but you won't receive the editoconfig anymore then. As these are "hard" errors, https://github.com/editorconfig/editorconfig-core-go/blob/560dd96cabfee7b13fc1e3a3cbcb23c2fcf7258b/definition.go#L53 and will just return nil as editorconfig, this library doesn't seem to have any option to change/disable this behavior either :/

[silverwind]

Best course of action would probably be to make editorconfig-core-go treat directive parsing errors the same as when the directive is absent. Could also have a editorconfig.ParseGraceful for that behaviour. Maybe @greut has an opinion.

[greut]

it should be easy to handle either on/off. Are those part of the spec? A graceful parsing is probably much more work...

[silverwind]

No, the spec only indicates true, false and unset as valid values. It does suggest graceful parsing, though:

EditorConfig plugins shall ignore unrecognized keys and invalid/unsupported values for those keys.

So while I think supporting boolean aliases like YAML does (yes, no, true, false, on, off) is probably fine, I think ultimately, invalid values should just be ignored instead of raising errors.

[greut]

@silverwind agreed. Most of them, could be moved to an error as log.

[silverwind]

Hmm, logging these parser "warnings" might be hard to consume. How about adding a warnings slice to a parse result, e.g.?

type Editorconfig struct {
  Root        bool
  Definitions []*Definition
  config      *Config
  warnings    []string
}

Fatal errors should still return err of course.

[lunny]

Is this still a problem?

[silverwind]

Yes, #21257 got stalled. I think it's the right solution to parse graceful and display errors. Ideally the admin page could also show the affected repo, or the admin notice could also be removed entirely.

[somera]

Should this be "fixed" with 1.19.1? Cause

[lunny]

Not yet. It's only for 1.20