Community

Posted: **Thu May 13, 2021 3:53 pm**

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!

Posted: **Sun May 23, 2021 2:31 pm**

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

Posted: **Mon May 24, 2021 8:03 am**

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.

Posted: **Mon May 24, 2021 12:37 pm**

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:

/app/lib/source/main.cpp
app/lib/source/main.cpp
lib/source/main.cpp
source/main.cpp
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?

Posted: **Tue May 25, 2021 6:54 pm**

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.

Posted: **Wed May 26, 2021 11:27 am**

That makes sense, thanks!

Posted: **Tue Jun 01, 2021 7:49 pm**

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

Posted: **Wed Jun 02, 2021 12:52 pm**

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.

Posted: **Wed Jun 02, 2021 3:37 pm**

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.

Posted: **Thu Jul 08, 2021 6:18 pm**

abushne wrote: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.

Posted: **Thu Jul 08, 2021 6:25 pm**

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.

Community

Support for editorconfig

Support for editorconfig

Netrwork error with .editorconfig