Support for editorconfig

[abushne]

Our organization makes use of editorconfig (https://editorconfig.org/) to help with making source setup consistent etc.. I was not sure if Textpad supports this in anyway?

Thanks!

[bbadmin]

This will be implemented in the next release, but there's one issue which you may be able to help with. The specification differentiates between pattern matching with "*" and "**", implying that the match should be against the complete pathname. However, sample .editorconfig files I've seen just have entries like "[*.html]", which implies that the match will just be against the simple filename. Any advice on which convention to use would be appreciated.

Thanks,

Keith MacDonald
Helios Software Solutions

[AmigoJack]

Code: Select all

# Matches multiple files with brace expansion notation
# Set default charset
[*.{js,py}]
charset = utf-8

The asterisk should match only filenames, no backslashes. Which means: this rule applies to any file.

Code: Select all

# Indentation override for all JS under lib directory
[lib/**.js]
indent_style = space
indent_size = 2

Two asterisks may also match paths, not only filenames. Which means: this rule applies to files under lib/ or any folder below (i.e. lib/more/here/). Would it be only one asterisk then this rule should only match files in a folder named lib/ (neither any folder below, nor folders with other names).

That's how I understand it.

[bbadmin]

That certainly seems to be the consequence of the way the specification is defined, but implies that every glob pattern must be compared with every component of a file's path.

Consider file "C:/app/lib/source/main.cpp" and an editorconfig file with these entries:

Code: Select all

[*.cpp]
tab_width=4

[lib/**.cpp]
tab_width=2

It would have to try matching these components against each of those entries:

1. /app/lib/source/main.cpp
2. app/lib/source/main.cpp
3. lib/source/main.cpp
4. source/main.cpp
5. main.cpp

Matches 3 and 5 would succeed, in that order, so tab_width would end up as 4.

This seems horribly inefficient, especially as there could be additional editorconfig files at each level of that directory tree. Is that the way we have to implement it?

[abushne]

In reading the specification for editorconfig, it states:

Code: Select all

EditorConfig files are read top to bottom and the most recent rules found take precedence.

So given a .editorconfig file of:

Code: Select all

[*.cpp]
tab_width=4

[lib/**.cpp]
tab_width=2

and a file named:

Code: Select all

c:/app/lib/source/main.cpp

I would expect the tab_width to be 2 for that file. The spec says the last specification seen takes precendence from the file.. So I suspect the "rules" becomes a list of expressions and once you match an expression, you stop and that is your rule.

Maybe I am mis-understanding something, but that is how I read it.

[bbadmin]

That makes sense, thanks!

[bbadmin]

This feature is implemented in TextPad 8.8 which is now available for downloading.

[abushne]

I downloaded 8.8 and ran into an issue with the .editorconfig implementation..

I tried to open a txt file we have out on our network that is accessible via UNC and upon opening the file I received the following error popup:

Code: Select all

Textpad

Filesystem error reading .editorconfig exists: The network name cannot be found:  \networkname.editorconfig
Continuing without it.

I can press Ok and the file opens etc.. but why am I getting that prompt? If .editorconfig is not present, just silently ignore, which I think you do for local non-unc paths.

[bbadmin]

The specification of std::filesystem::exists(std::filesystem::path) caught me out. Not sure why it returns a bool when it throws on failure for "//networkname/.editorconfig", but that's why you're seeing that error.

The workaround is to insert "root=true" at the head of your topmost .editorconfig file. It will be fixed in the next release.

Thanks for reporting it.

[sosimple]

In reading the specification for editorconfig, it states:

Code: Select all

EditorConfig files are read top to bottom and the most recent rules found take precedence.

So given a .editorconfig file of:

Code: Select all

[*.cpp]
tab_width=4

[lib/**.cpp]
tab_width=2

and a file named:

Code: Select all

c:/app/lib/source/main.cpp

I would expect the tab_width to be 2 for that file. The spec says the last specification seen takes precendence from the file.. So I suspect the "rules" becomes a list of expressions and once you match an expression, you stop and that is your rule.

Maybe I am mis-understanding something, but that is how I read it.

(--- something's up... the above -Quote- isn't rendering correctly ---)

Something about that is confusing me...

First you said: "EditorConfig files are read top to bottom and the most recent rules found take precedence".

Then: I would expect the tab_width to be 2 for that file.

This makes sense to me in the example given since:

• 1: Both rules in the example ".editorconfig" file match the target file: "c:/app/lib/source/main.cpp"
  2: When the ".editorconfig" file is read from top to bottom, the second rule is the most recent matching rule found. It is the last matching specification seen so it takes precedence.

But then you said: "... once you match an expression, you stop and that is your rule". Which seems to say that the "First" matching rule seen takes precedence, rather than the last matching rule seen takes precedence. So your last statement seems to be the opposite of your other statements.

[abushne]

I suspect you are probably right.. The rules are treated like a stack and pushed onto the stack as encountered in the config. then when applying a match, popped until a match found.