Support EditorConfig

[wooorm]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Problem

EditorConfig defines certain code-style preferences.
Some of those can be done by the engine (charset, insert_final_newline).
Others by the processor (syntax-tree/mdast-util-to-markdown#51, syntax-tree/mdast-util-to-markdown#50; what about HTML though where the whitespace is part of the AST?).
Some are ambiguous (end_of_line).

Solution

Can we load (as an option), editorconfig files, and pass their keys, camelcased, to settings?
That passes them to *-parse and *-stringify.
We could pass a nested object if there’s fear that it would conflict, but I don’t think it does?

Alternatives

• Custom adapter functions (e.g., passed by remark-cli to the engine) that transform an EditorConfig into certain settings? Could be modules, e.g., called editorconfig-to-remark-settings or so?

[ChristianMurphy]

👍 on having a way to pull outside settings to inform how to generate output.
👍 on editorconfig as one of them.

I'd be cautious on hard coding it to be editorconfig exclusive.

Custom adapter functions (e.g., passed by remark-cli to the engine) that transform an EditorConfig into certain settings? Could be modules, e.g., called editorconfig-to-remark-settings or so?

I'd lean towards this.
It would be good to leave an opportunity to read the same values from vscode settings, prettier config, dprint config, etc.

[wooorm]

I see remark/rehype as formatters on the same level as prettier or dprint.
EditorConfig is a tool under them. VS Code is a tool that uses them.
So my idea of the settings flow is editorconfig -> remark/rehype/prettier/dprint -> vscode?

[ChristianMurphy]

EditorConfig is a tool which tries to standardize settings across editors, but like many post-facto standards, not everybody uses it

EditorConfig may be a good default, but it is not the only configuration option out there, with each editor having their own settings file which the information could be pulled from.

I see remark/rehype as formatters on the same level as prettier or dprint

It somewhat is, that said, remark/rehype could be configured to automatically generate content more similar (not identical) to how dprint or prettier would.

[wooorm]

I don’t understand, so perhaps these questions can help me understand:

• How would remark-stringify support prettier or any other tool’s config?
• Should remark-stringify read the .vscode settings which vscode already passes to it and which take precedence?
• How many tools should be supported in unified-engine/*-stringify?
• What’s to decide whether or not an arbitrary tool is supported in unified-engine/*-stringify?
• Would it not be easier to use standards (i.e., EditorConfig)

[wooorm]

I especially don’t understand the meme here. There is but one standard for sharing settings across editors and tools: EditorConfig.

[ChristianMurphy]

Each editor has its own standard, which it and maybe a few others follow.
EditorConfig created yet another, it started independent of other editors, it needs a plugin installed, which not many developers do.
Especially not since the rise of having formatting as an external tool (like prettier).

That's not to say editor config is bad, just that it isn't universal, and potentially growing more niche (currently).

[wooorm]

I don’t think that tools should be called standards. Prettier is not a standard. Chrome is not a standard. EditorConfig is a standard.

Prettier, VS Code, and other tools support EditorConfig. I’d like to support it too.
Prettier does not support VS Code. dprint does not support prettier. I don’t think we need to support VS Code or prettier.

Can we focus on the other parts of the issue too? Perhaps by looking at the questions I asked in my last comments, and seeing how EditorConfig/prettier/VS Code/dprint can solve them?

[ChristianMurphy]

Can we focus on the other parts of the issue too? Perhaps by looking at the questions I asked in my last comments, and seeing how EditorConfig/prettier/VS Code/dprint can solve them?

Did you read my previous answers? They addressed most of your questions before you asked them, to re-iterate for your convenience.

How would remark-stringify support prettier or any other tool’s config?

Through a settings plugin, which reads a configuration file from another tool, and translates it to remark settings.

Should remark-stringify read the .vscode settings

A settings transform would

which vscode already passes to it and which take precedence?

settings plugin would likely be lowest precedence

How many tools should be supported in unified-engine/*-stringify?

As many as the community wants to create plugins for, starting with one, editorconfig.

What’s to decide whether or not an arbitrary tool is supported in unified-engine/*-stringify?

Whether someone feels like creating a settings plugin

Would it not be easier to use standards (i.e., EditorConfig)

Maybe, again standardized is not the same widely-adopted.
If your target audience is the JS community, and specifically Sindre, go for it.
If the target audience is the broader developer community, more flexibility may be needed.
(for example peruse through https://github.com/apache and you'll find more intellij configurations than editor configs)

[wooorm]

Did you read my previous answers? They addressed most of your questions before you asked them, to re-iterate for your convenience.

No need to be (passive) aggressive.

How would remark-stringify support prettier or any other tool’s config?

Through a settings plugin, which reads a configuration file from another tool, and translates it to remark settings.

This answers how custom config can be loaded. I am interested in how you would see such a plugin, sure, but I am particularly interested in what benefit remark-stringify has of being given prettier settings or VS code settings.

In the original post, I describe that remark-stringify (and rehype-stringify, and others) can benefit from charset, insert_final_newline, end-of-line, indent-style, indent-size, tab-size, which are found in EditorConfig files.
Are there any particular fields that are found in Prettier or VS Code, that are not found in EditorConfig, which you want to pass to all *-stringify packages?

Here you propose a unified plugin, which could exist in userland, that is connected to a certain tool or editor, and to remark. This proposed plugin does not work with the engine, so it seems out of place of the discussion here in this issue tracker?

If your target audience is the JS community, […], go for it.

I do indeed see the target audience of unified as the JavaScript community, yes.

[ChristianMurphy]

Did you read my previous answers? They addressed most of your questions before you asked them, to re-iterate for your convenience.

No need to be (passive) aggressive

I'm responding to you stonewalling concerns with a wall of tangential question, any of which go unanswered you'll ignore the over arching concern.

Here you propose a unified plugin, which could exist in userland, that is connected to a certain tool or editor, and to remark. This proposed plugin does not work with the engine, so it seems out of place of the discussion here in this issue tracker?

To repeat and make it very clear, I'm currently 👎 on this being a part of unified engine, this should be in userland, for the variety of reasons stated before.

Are there any particular fields that are found in Prettier or VS Code, that are not found in EditorConfig, which you want to pass to all *-stringify packages?

Potentially yes, I don't have any specific fields in mind.
This misses the broader points though:

• editorconfig should not be made a requirement for a project that doesn't use editorconfig.
• having an editor configuration implicitly change the default behavior of an unrelated build tool is highly unexpected.

I do indeed see the target audience of unified as the JavaScript community, yes.

It is also adopted in the Python community (often via pre-commit) and at times in the Java community via gradle/maven plugins.
I'd also consider these part of the target audience.

[wooorm]

I'm responding to you stonewalling concerns with a wall of tangential question, any of which go unanswered you'll ignore the over arching concern.

This last phrase is ungrammatical, I don’t understand what you mean. Can you rephrase it and explain what you see as the “over arching concern”?

Stonewalling is, apparently, the act of avoiding conversation. I have questions. You don’t answer them.

To repeat and make it very clear, I'm currently 👎 on this being a part of unified engine, this should be in userland, for the variety of reasons stated before.

On the point made in this paragraph: this point is new. You are changing the goal posts. Previously you advocated for other things than editorconfig. Now you advocate against configuration files.

On your vote: the unified collective uses a consensus-seeking approach, you are supposed to build consensus and to work on an acceptable solution (https://github.com/unifiedjs/collective/blob/main/decisions.md#initiatives).

This misses the broader points though:

• editorconfig should not be made a requirement for a project that doesn't use editorconfig.
• having an editor configuration implicitly change the default behavior of an unrelated build tool is highly unexpe

These points are new. They are solvable. We could have a dialogue on how they can be solved.
I am not arguing to require editorconfig. Like prettier, editorconfig could also be optional instead of required. I don’t buy the gut feeling that config files are unexpected though.

[ChristianMurphy]

“over arching concern”?

That editorconfig should not be the single editor language supported nor should it be enabled by default.

Stonewalling is, apparently, the act of avoiding conversation. I have questions. You don’t answer them.

I have answered each of them.
Often quoted to ensure clarity that it has been answered.
Gaslighting is not appreciated either.

Stonewalling in a deflecting sense, you go on tangents about your definition of standards, re-ask questions which have already been answered previously (or by the issue itself even), seemly to avoid the conversation of why this is needed as a core feature, and not in userland/a plugin.

Previously you advocated for other things than editorconfig. Now you advocate against configuration files.

I'm advocating for both supporting more configuration languages, and not enabling this by default/in unified engine.

On your vote: the unified collective uses a consensus-seeking approach, you are supposed to build consensus and to work on an acceptable solution (https://github.com/unifiedjs/collective/blob/main/decisions.md#initiatives).

Thanks for linking to the guide.
It's a good reminder.
Since this significantly impacts multiple projects and multiple organizations, it should, according to the decision process be an RFC.

These points are new. They are solvable. We could have a dialogue on how they can be solved.

Great, share the intended solution.

I am not arguing to require editorconfig. Like prettier, editorconfig could also be optional instead of required.

As a part of unified engine?
The engine currently provides a way to manage plugins and reporters, but it doesn't really have user facing settings.
How would it be optional to enable?
How would it be optional to download (or not download)?

I don’t buy the gut feeling that config files are unexpected though.

A potential scenario.
Unified engine enables editor config by default.
Locally I have configuration files for developing (.editorconfig for example).
But when that goes to CI, only files to be used in build/test are sent to the CI server, not development files like .editorconfig, prettier config, vscode settings, etc.
Tests on CI leaning on unified engine would produce different results, and fail tests.
And even more confusing, if editor config is on by default in unified engine, there would be no clear indication that it was used to change results.

[wooorm]

to avoid the conversation of why this is needed as a core feature, and not in userland/a plugin.

The issue body contains: “Some of those can be done by the engine (charset, insert_final_newline). […] Some are ambiguous (end_of_line).”
Plugins can’t perform some of these settings, aren’t good places to solve them, or it’s copy/paste to solve them in each compiler.
Of course, much of the engine could be done in plugins indeed. Such as config and ignore files. But it’s useful to have them done in the engine. I believe this extends to the engine helping users by loading explicit project configuration such as the frequently used .editorconfig file.

I'm advocating for both supporting more configuration languages, and not enabling this by default/in unified engine.

• What is the benefit of remark-stringify/rehype-stringify/retext-stringify etc each handling say character encoding of output buffers?
• What is the benefit of, when a project is explicitly configured to use hard tabs, end of lines, final newlines, indent size, etc in an .editorconfig file, it is a good idea for remark/rehype to ignore that and use something else, assuming there is an opt-out/in?
• What is the benefit of using prettier config, dprint config, vscode settings, etc, for the current remark-stringify / rehype-stringify options and the proposed new options Figure out a way to support tab-size / aligning columns syntax-tree/mdast-util-to-markdown#51, Figure out a way to support tabs syntax-tree/mdast-util-to-markdown#50, and line wrapping which is close with syntax-tree/mdast-util-to-markdown@52c18b4?

Great, share the intended solution.

1. The issue body above proposes to treat the settings, as optionally found in editorconfig, the same as settings found in config files, and as settings passed to the engine / as flags to the CLI. In other words, I want normal settings, preferably matching editorconfig fields, and loading editorconfig files, but giving more precedence to named config files and settings.
2. Given that editorconfig affects many tools, as can be seen on their website and speaking from experience, often without user involvement (GH, prettier, jet brains), and often with (vim, vs code), I do think it is expected that editor configs affect editors and tools.
   I do not agree with calling remark and rehype “unrelated build tools” (note especially that we’re discussing the engine, so remark-cli / rehype-cli are more apt, not processors: remark / rehype).
   prettier here provides popular precedence and I strongly agree. I see both humans (through editors) and computers (through prettier/remark/rehype) as actors on code that needs to adhere to certain rules. When a project is configured to use hard tabs, then both GUI editors and CLI tools acting for users should use tabs.

I am not arguing to require editorconfig. Like prettier, editorconfig could also be optional instead of required.

Note: earlier I believed prettier defaulted to not using editorconfig and that xo turned it on, this was incorrect: prettier itself uses editorconfig by default. It is on by default and can be turned off with an option. I want the same for unified-engine.

The engine currently provides a way to manage plugins and reporters, but it doesn't really have user facing settings.
How would it be optional to enable?

It has many options. It can have an editorconfig boolean (and a flag on the CLI). Prettier has the option defaulting to true (probably also a --no-editorconfig flag?)

How would it be optional to download (or not download)?

I am not proposing for an external download. Similar to how, say, --inspect can be passed to get a diagram of the AST, without an extra download.

A potential scenario.
[u]nified engine enables editor config by default.
Locally I have configuration files for developing (.editorconfig for example).
But when that goes to CI, only files to be used in build/test are sent to the CI server, not development files like .editorconfig, prettier config, vscode settings, etc.

Say that locally an editorconfig/prettier configuration is used, and remotely no editorconfig/prettier configuration is used, I believe it is expected that prettier produces differing results.
The same is true for xo, ESLint, Babel, and other developer tool that use config files.

Tests on CI leaning on unified engine would produce different results, and fail tests.

unified-engine, which materializes as remark-cli, remark-vscode, linter-remark, and such, is used for developing on the file system to lint and format files. It loads config files.
I see no good reason for using unified-engine in tests that, similarly, would expect .remarkrc to be ignored. And if they do, turning an option off is fine.

And even more confusing, if editor config is on by default in unified engine, there would be no clear indication that it was used to change results.

I don’t think this is confusing. An editorconfig is chosen by a team. It gives a few instructions to humans and tools. Maybe a new contributor hasn’t installed the plugin but then tooling like prettier/remark/rehype makes sure the changed code does follow the style guide.
There is no clear message that .remarkrc / package.json#rehype is used. That is acceptable. It is of course important to document this feature.

[ChristianMurphy]

What is the benefit of remark-stringify/rehype-stringify/retext-stringify etc each handling say character encoding of output buffers?

I don't see one, nor am I advocating for it.
My objection is with implicit use of .editorconfig to implicitly change output.
Not with things, like character encoding, themselves.

What is the benefit of, when a project is explicitly configured to use hard tabs, end of lines, final newlines, indent size, etc in an .editorconfig file, it is a good idea for remark/rehype to ignore that and use something else, assuming there is an opt-out/in?

I don't really understand your question.
I think you are trying to ask why remark shouldn't read .editorconfig if it available?
In short, it shouldn't do this automatically because remark, is not a code editor.

remark should only use non-remarkrc files/properties, only when explicitly told to.
One way to do that, would be using a plugin/preset to configure remark or unified-engine.

What is the benefit of using prettier config, dprint config, vscode settings, etc, for the current remark-stringify / rehype-stringify options and the proposed new options

They don't need to be, you shouldn't need a file other than a remark configuration file to configure remark.
Any and all of these added, would be nice-to-have ways of mapping other ecosystems into remark/unified-engine options (including editorconfig).

The issue body above proposes to treat the settings, as optionally found in editorconfig, the same as settings found in config files, and as settings passed to the engine / as flags to the CLI. In other words, I want normal settings, preferably matching editorconfig fields, and loading editorconfig files, but giving more precedence to named config files and settings.

I'm fine with the order of precedence/operations.
Though it still feels off that a non-editor is reading editor settings not-meant for it, by default.
And it also seems off that we'd force non-.editorconfig project to load an .editorconfig parser.

prettier here provides popular precedence and I strongly agree. I see both humans (through editors) and computers (through prettier/remark/rehype) as actors on code that needs to adhere to certain rules. When a project is configured to use hard tabs, then both GUI editors and CLI tools acting for users should use tabs.

Prettier is explicitly a formatter, it is expected to make stylistic changes to files.
unified-engine is not, it is a transformer, which can be used as a formatter, but often isn't (as can be seen over the years with issues raised asking remark to preserve formatting as much as possible, and frequent requests for CST like features)

An even an explicit formatter, like prettier, I have mixed feelings about it reading editorconfig.

It has many options. It can have an editorconfig boolean (and a flag on the CLI). Prettier has the option defaulting to true (probably also a --no-editorconfig flag?)

Setting aside the default value for a moment.
Having some options routed to unified and others to remark would probably be fine, if a bit convoluted.

I am not proposing for an external download. Similar to how, say, --inspect can be passed to get a diagram of the AST, without an extra download.

Editor config itself needs a parser to be loaded, a miniture runtime, not to mention some potentially complex rules to ensure we match globbed settings correctly. (similar to #56)
It feels like a fair amount of bundle size and complexity to include by default.

Say that locally an editorconfig/prettier configuration is used, and remotely no editorconfig/prettier configuration is used, I believe it is expected that prettier produces differing results.
The same is true for xo, ESLint, Babel, and other developer tool that use config files.

ESLint does not by default eslint/eslint#8941, nor does babel (AFAICT)
prettier and xo do, though that doesn't necessarily make it "expected", some tools could be seen as actors/editors, like CoPilot, transformers and formatters less so.

I don’t think this is confusing. An editorconfig is chosen by a team. It gives a few instructions to humans and tools. Maybe a new contributor hasn’t installed the plugin but then tooling like prettier/remark/rehype makes sure the changed code does follow the style guide.

Any configuration file gives instructions for tools or a team.
The question is more, who is expected to interpret and run the file.
prettier reads .prettierrc, vscode reads the .vscode folder, editors read the .editorconfig.
the actor interpretation where everything that can touch a file is an "editor" is a stretch.
Most people would interpret "editor" as an integrated development environment or a text editor.

[wooorm]

My objection is with implicit use of .editorconfig to implicitly change output.

In short, it shouldn't do this automatically because remark, is not a code editor.

Though it still feels off that a non-editor is reading editor settings not-meant for it, by default.

Why impose such a limit? That only code editors are allowed to look at shared code style configuration?

The engine is frequently used in editors or acts as a user agent for editing.
When a tab width of 4 characters should be used for markdown files according to an .editorconfig file, then CMD+S on a markdown file in VS Code or npm run format on the CLI following that style is not implicit. It’s explicitly requested.

Say I typically like 2 spaces. This project likes 4 spaces. It has an .editorconfig file to define that. And it has remark set up.
This project, through editorconfig, requests that my editor uses 4 spaces to indent. So when I hit CMD+TAB, 4 spaces are inserted by VS Code, where I would normally get 2 spaces.
Now, when I CMD+S with format-on-save enabled, I find it unexpected that vscode-remark uses my personal preferences or its default (whatever that is). Precedence is set by at least prettier-vscode and linter-xo.
The same is true when remark-cli is used in the project, because maybe I don’t have one or both of the editorconfig/remark integrations in my editor, it is also expected to follow the project’s style. There is precedence with prettier and xo.

remark should only use non-remarkrc files/properties, only when explicitly told to.

Why? It is not unheard of for projects to load similar files. Other than .editorconfig, also .gitignores, .mailmaps, package.jsons are loaded.

One way to do that, would be using a plugin/preset to configure remark or unified-engine.

unified-engine also does things that are useful even when they could’ve been plugins. Config files themselves could been a plugin. Or ignore files, reporting.

Any and all of these added, would be nice-to-have ways of mapping other ecosystems into remark/unified-engine options (including editorconfig).

I don’t see reasons for projects like vscode-remark or remark-cli to support prettier config, dprint config, or vscode settings.
Those configs are meant to work in one specific tool instead of shared amongst tools. Similarly, I don’t expect them to support .remarkrc files.
Prettier and dprint are alternatives to remark and rehype.
VS Code settings are not sharable code style of a project, it’s more focussed on user preferences (e.g., how big to display text, that I want to show invisible spaces).

They don't need to be, you shouldn't need a file other than a remark configuration file to configure remark.

And it also seems off that we'd force non-.editorconfig project to load an .editorconfig parser.

Editor config itself needs a parser to be loaded, a miniture runtime, not to mention some potentially complex rules to ensure we match globbed settings correctly.
It feels like a fair amount of bundle size and complexity to include by default.

The code needed to resolve editorconfig files is normal sized and stable: https://github.com/editorconfig/editorconfig-core-js/blob/master/src/index.ts. The quality is good enough for Prettier, Renovate, and many other dependants, it’s in 400k repos already. The packagephobia of editorconfig is reasonable.
If you are very worried about the added code size, we can reuse the code that’s already used to find files on the file system (lib/find-up.js and lib/finder.js).

(I don’t understand the term “miniture runtime” in this context?)

Prettier is explicitly a formatter, it is expected to make stylistic changes to files.
unified-engine is not, it is a transformer, which can be used as a formatter, but often isn't (as can be seen over the years with issues raised asking remark to preserve formatting as much as possible, and frequent requests for CST like features)

some tools could be seen as actors/editors, like CoPilot, transformers and formatters less so.

I am not sure what the term “transformer” means in this context. Or why unified-engine is not a “formatter”. Why is there a distinction, what does it mean, and why is unified-engine not allowed to format files?

The historic issues about CSTs cannot be solved with an AST. The issues could be ignored. Or unified could become better at formatting. Which is what I am working on (see the problem space of the issue body). As linked, I am adding the features that are configured in editorconfig files.

Having some options routed to unified and others to remark would probably be fine, if a bit convoluted.

I agree that it is convoluted. It could also be a small package, used in and shared between *-stringifys, which takes care of line endings or so, which can then be implemented once rather than copy/pasted in each *-stringify plugin. This has the added benefit that endOfLine: '\r' could be passed to the remark API.

The same is true for xo, ESLint, Babel, and other developer tool that use config files.

ESLint does not by default, nor does babel (AFAICT)

The point I attempted to make here was about config files in general, and that whether you ship them to a CI or not, affects how that tool runs on a CI.

the actor interpretation where everything that can touch a file is an "editor" is a stretch.
Most people would interpret "editor" as an integrated development environment or a text editor.

I don’t get this point. That only editors are allowed to use .editorconfigs because that’s in the name. It’s a very literal interpretation. What about Java and JavaScript? 🤷‍♂️
What’s interesting is what the file is for: “EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs.” We can help reach that goal, for the people that want it as well and have these files, by loading editorconfigs and applying their preferences.
What’s interesting is what’s inside the file: code style guidelines, which we can use as configuration.

[ChristianMurphy]

Why impose such a limit? That only code editors are allowed to look at shared code style configuration?

I don’t get this point. That only editors are allowed to use .editorconfigs because that’s in the name. It’s a very literal interpretation.

It is named editorconfig for a reason, it is literally intended to be information for code editors.
Adopters would and should expect it do act that way.
Using options outside their intended context is something that can be done, but it makes editorconfig no different from vscode or intellij in that sense (being a "standard" doesn't magically make the context problem go away)

The engine is frequently used in editors or acts as a user agent for editing.

As far as I'm aware, engine was first used in editors with the additional of the language server.
And while it is growing and will continue to grow, it is not frequently used yet.

Engine is still primarily used in the context of CLIs and build tools, which are not code editors.

When a tab width of 4 characters should be used for markdown files according to an .editorconfig file, then CMD+S on a markdown file in VS Code or npm run format on the CLI following that style is not implicit. It’s explicitly requested.

No it is not.
It is only intended if and only if remark is being used as a formatting tool.
Often it is used as a build tool or transformer/compiler, where formatting is considered unexpected.

why is unified-engine not allowed to format files?

To repeat a point you make frequently Titus.
Unified can be used to inspect/lint files, unified can be used to format files, or unified can be used to transform files to another language.

Your arguments seem to center around unified only being a formatter, but it isn't.
It can be a formatter, but there are also contexts where it is not, and it seems off to say we'll now act as formatter in those contexts too.

which takes care of line endings or so, which can then be implemented once rather than copy/pasted in each *-stringify plugin. This has the added benefit that endOfLine: '\r' could be passed to the remark API.

Yeah, having this live in the stringifiers themselves would make that clearer.

The point I attempted to make here was about config files in general, and that whether you ship them to a CI or not, affects how that tool runs on a CI.

I agree, and my point is that folks generally won't expect dev tools options to be needed for CI, unless it is explicitly stated.

[wooorm]

Using options outside their intended context is something that can be done, but it makes editorconfig no different from vscode or intellij in that sense (being a "standard" doesn't magically make the context problem go away)

I see .editorconfig config files as quite different from VS Code and IntelliJ configuration in 2 ways:

• by who they are used, because VS Code config files are intended to be used by VS Code, .editorconfig files are intended to be used by several projects
• by what they contain: VS Code config files contain personal preferences, such as how big to display a font or how big to display tabs, whereas .editorconfig does not include preferences on how files display, but on how files are modified consistently by a team

That they are different can be observed by how they are used: IntelliJ supports .editorconfig, VS Code can support .editorconfig with a plugin. But prettier does not support IntelliJ configuration. IntelliJ does not support VS Code configuration, etc.

As far as I'm aware, engine was first used in editors with the additional of the language server.

The engine is in use in editors through several projects already. I know of several Atom, VS Code, and SublimeText projects, that I either made myself, or by others.

It is only intended if and only if remark is being used as a formatting tool.
Often it is used as a build tool or transformer/compiler, where formatting is considered unexpected.

.stringify and --output are integral parts of the unified process. It is intended that remark and rehype format since the start. They’re just getting better at it.

[u]nified can be used to inspect/lint files, unified can be used to format files, or unified can be used to transform files to another language.
Your arguments seem to center around unified only being a formatter, but it isn't.
It can be a formatter, but there are also contexts where it is not, and it seems off to say we'll now act as formatter in those contexts too.

Formatting is also expected when transforming from markdown to HTML or vice versa.
I believe formatting is inherent to ASTs, as it is lossy, which is then made consistent following a particular code style.
The context where it is not a formatter, is when --output is not set or .parse or .run are used: when not outputting at all.

The point I attempted to make here was about config files in general, and that whether you ship them to a CI or not, affects how that tool runs on a CI.

I agree, and my point is that folks generally won't expect dev tools options to be needed for CI, unless it is explicitly stated.

I don’t understand the point you are trying to make. Attempting to make it more concrete with an example, I get: “my point is that folks generally won't expect {Jest,ESLint,prettier,remark} options to be needed for CI, unless it is explicitly stated.”? It seems normal to expect that when tools are used somewhere, they are configured?

[ChristianMurphy]

by who they are used, because VS Code config files are intended to be used by VS Code, .editorconfig files are intended to be used by several projects

This is neither here nor there.
Again:

Using options outside their intended context is something that can be done, but it makes editorconfig no different from vscode or intellij in that sense

editorconfig can be intended for multiple editor projects, that doesn't make it intended for non-editor projects.

by what they contain: VS Code config files contain personal preferences, such as how big to display a font or how big to display tabs, whereas .editorconfig does not include preferences on how files display, but on how files are modified consistently by a team

There are two kinds of vscode config files, the personal config file in a developers home folder, and a workspace config in a project folder.
What you are describing is the personal config file.
However the workspace config serves the same purpose as editorconfig, also going a step further being able to define tasks and debugger integrations https://code.visualstudio.com/docs/editor/workspaces

.stringify and --output are integral parts of the unified process. It is intended that remark and rehype format since the start. They’re just getting better at it.

They are a part of the process.
But it is not the only, nor the most common way remark is used.
Case an point, your next comment

The engine is in use in editors through several projects already. I know of several Atom, VS Code, and SublimeText projects, that I either made myself, or by others.

All of the projects you reference are, linters, not compilers/formatters

• https://github.com/wooorm/linter-remark
• https://packagecontrol.io/packages/SublimeLinter-contrib-remark-lint
• https://github.com/drewbourne/vscode-remark-lint

The only one that gets into formatting is the more recent https://github.com/remarkjs/vscode-remark

Which again, I could see a preset reading editorconfig for remark-lint or for remark-stringify.
I think it would be unexpected for it to change settings by default.

I don’t understand the point you are trying to make. Attempting to make it more concrete with an example, I get: “my point is that folks generally won't expect {Jest,ESLint,prettier,remark} options to be needed for CI, unless it is explicitly stated.”? It seems normal to expect that when tools are used somewhere, they are configured?

To give another concrete example of why this would be unexpected.
A team running a large project, CI/CD tasks load only the files needed to make the process expediant.
I would expect a remark linting/formatting process to need: all the markdown files and the remark config file, no more.
This change would make it so .editorconfig, needs to be uploaded as well or the linter/formatting processes will produce different results.

I would only expect a config file for another project to affect remark if a setting useEditorconfig: true or plugins: ["remark-preset-editorconfig"] were enabled.
But that would no longer be the case.

[wooorm]

This is neither here nor there.

It’s an important aspect that editorconfig is nothing on its own except for the different tools that implemented it, and that VS Code config is config for that particular tool and not meant for other tools.

editorconfig can be intended for multiple editor projects, that doesn't make it intended for non-editor projects.

Your interpretation of .editorconfig is quite literal, misses what the files contain (code style), and does not align with how it’s used by certain tools that are similar to unified (Prettier, xo, …).

Users edit files through tools. Users configure tools through config files. Some of those files are shared between tools. unified-engine should read those shared files.

However the workspace config serves the same purpose as editorconfig, also going a step further being able to define tasks and debugger integrations code.visualstudio.com/docs/editor/workspaces

I’ve looked at some examples and you are right that workspace config is indeed shared.
That “step further” (in combination with the other point: that they’re VS Code-specific) remains an important difference in what the files contain in my opinion: everything can be defined in VS Code workspace settings. Not just code style, but also whether to use formatOnSave, to use extensions and when to run them.

nor the most common way remark is used.

I believe this to be incorrect. Why do you believe this?
Looking at examples: all of unified is using unified to format. Folks want to format: unifiedjs/unified-language-server#31 (comment). My guess is that remark/unified is most used through prettier (27m dl/m) to format?
But also looking at intent: unified exists to input content, check and change it, and output content. If people don’t want that they shouldn’t use unified. There are other tools better at only linting. There are other tools that only format. There are tools that just expose an AST. It’s okay to use one part of unified but it’s meant to do all.

When the statement is correct, that folks would only lint, then they wouldn’t be affected by .editorconfig? There currently is no connection between lint settings and format settings, although there are open issues about changing that.

Case an point, your next comment
All of the projects you reference are, linters, not compilers/formatters

Your mixing things: how unified / unified-engine is used (which is not only through editors) and which editor integrations currently exist.
It’s incorrect: remarkjs/vscode-remark is from 2016 (I also looked at actions and found a few).
You are right that it’s not a lot. I believe that the Sublime and Atom editor integration only lint because Sublime and Atom ecosystems are/were built around linter abstractions.

Looking at existing tooling within a certain space does not mean that tooling can’t be improved or expanded upon. If formatting gets better, linting doesn’t get worse.

I think it would be unexpected for it to change settings by default.

At this point it seems like you: a) don’t use unified to format things, b) don’t use editorconfig at all?

I would expect a remark linting/formatting process to need: all the markdown files and the remark config file, no more.

If a CI/CD process deals with code style, and these folks have an .editorconfig, then it’s expected that the files defining the code style are included in processes that check or format code. To me this includes a .remarkrc that includes some plugins or settings and an .editorconfig that documents what to use for tabs.

This change would make it so .editorconfig, needs to be uploaded as well or the linter/formatting processes will produce different results.

Yes. Just like a .remarkrc.
The folks in this use case will have noticed that .editorconfig is used by tools (including remark) on their computers already. In the case where they don’t have integrations set up in their editor and use a non-conforming style when editing markdown, they’d notice that remark-in-a-script would fix it up.
They may have noticed that .editorconfig is used by different tools in similar processes too: prettier, xo. Perhaps more in the future.
Even when not, it would be immediately noticed because things like indent size, indent style, line endings, character encoding, etc are ubiquitous and would show up in the first attempt of setting up such a complex task.

This change improves how unified is used for folks that do use editorconfig and do format. It allows for folks to run it with less config files. Or at least to not have to duplicate configuration.

[ChristianMurphy]

Your interpretation of .editorconfig is quite literal

Yes, its intent to work with editors/IDEs is literally in the name and in the description.
I find your acrobatics to try to change what is it quite strange.

and does not align with how it’s used by certain tools that are similar to unified (Prettier, xo, …).

Again, unified is different from either of those.
And even in those cases, it is debatable whether that is an appropriate use of editorconfig.

Users edit files through tools. Users configure tools through config files. Some of those files are shared between tools. unified-engine should read those shared files.

non sequitur.
There are many ways users configure tools, and many ways that configuration can be shared.
That doesn't mean it should be baked into unified-engine.

It is also a straw-man.
I have said before, and will say again, I think there would be a lot of value in having a plugin for unified/remark/rehype to support editor config.
Taking the same approach that atom, vscode, and eslint have taken.

important difference in what the files contain in my opinion: everything can be defined in VS Code workspace settings. Not just code style, but also whether to use formatOnSave, to use extensions and when to run them.

editorconfig has settings unified won't leverage, vscode workspace settings has settings unified won't leverage. 🤷‍♂️
This seems a bit moot.

At this point it seems like you: a) don’t use unified to format things, b) don’t use editorconfig at all?

I do use unified to format things at times, and do sometimes use editorconfig.
I also have projects that don't use unified to format or don't use editorconfig.
I don't see a reason why unified should have a preference for one over the other, baking this into unified-engine shows a strong preference for the former over the later and, reading between the lines of your previous comments, it sounds like the intent is to exclude the possibility of supporting other formats (not-editorconfig) entirely.

Looking at existing tooling within a certain space does not mean that tooling can’t be improved or expanded upon. If formatting gets better, linting doesn’t get worse.

Agreed