You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@daffodil.apache.org by "Beckerle, Mike" <mb...@owlcyberdefense.com> on 2021/04/19 13:55:48 UTC
editconfig
https://editorconfig.org/
This is interesting and we should consider adding these files to the root of daffodil both as a declaration of the code-style, and a way that auto-configures many IDEs and tools (like github).
This does not appear to be sophisticated enough to really cover code-style issues at all, but at least basic whitespace stuff like spaces not tabs, 2-space indenting, etc. would be covered.
Re: editconfig
Posted by "Beckerle, Mike" <mb...@owlcyberdefense.com>.
Also, did we decide on the autocrlf or force just LF thing?
I think I am in the force LF-only camp now. I got prompted the other day by IntellJ that I was commiting files that contained CRLFs.
Developers on windows just must configure tools to always use just LF line endings for the Daffodil project.
________________________________
From: John Wass <jw...@gmail.com>
Sent: Wednesday, April 21, 2021 11:46 AM
To: dev@daffodil.apache.org <de...@daffodil.apache.org>
Subject: Re: editconfig
> As a Scala project, however, how about using Scalafmt?
I'm in favor of scalafmt also.
> But I assume scalafmt won't cover other files like XML/schema/tdml/text
files.
Take a look at https://github.com/diffplug/spotless
Spotless says it could support all of those, and a quick search says the
SBT plugin is backed by scalafmt.
(I haven't used Spotless, just saw it today and thought of this thread)
On Mon, Apr 19, 2021 at 3:17 PM Interrante, John A (GE Research, US) <
John.Interrante@ge.com> wrote:
> I concur with Steve; we're going to need both a scalafmt configuration
> file and an .editorconfig file to cover all source code files unless the
> day comes when scalafmt understands .editorconfig and we're happy with
> scalafmt's default formatting options.
>
> Daffodil's existing code style is supposed to be very close to
> scalariform's default formatting options. Does anyone know how different
> scalafmt's default formatting options are from scalariform's? If they're
> not that different, eventually we might end up with just .editorconfig.
>
> -----Original Message-----
> From: Adam Rosien <ad...@rosien.net>
> Sent: Monday, April 19, 2021 12:16 PM
> To: dev@daffodil.apache.org
> Subject: EXT: Re: editconfig
>
> Ah, thanks for the extra context. I'll check out the JIRA issue.
>
> FYI there's an editorconfig integration issue open for scalafmt:
> https://github.com/scalameta/scalafmt/issues/1458.
>
> .. Adam
>
> On Mon, Apr 19, 2021 at 8:51 AM Steve Lawrence <sl...@apache.org>
> wrote:
>
> > As long as scalafmt covers everything editconfig supports and the
> > popular IDE's support it, we'd probably get better results for our
> > scala files. But I assume scalafmt won't cover other files like
> > XML/schema/tdml/text files. We might need a combination of the two to
> > cover all files?
> >
> > See https://issues.apache.org/jira/browse/DAFFODIL-2133 for related
> issue.
> >
> > - Steve
> >
> > On 4/19/21 11:37 AM, Adam Rosien wrote:
> > > As a Scala project, however, how about using Scalafmt? [1] It's
> > > become standard in all the projects I've been involved with; it's
> > > supported by
> > the
> > > language creators and matches the previously mentioned features.
> > >
> > > .. Adam
> > >
> > > [1] https://scalameta.org/scalafmt/
> > >
> > > On Mon, Apr 19, 2021 at 8:20 AM Interrante, John A (GE Research, US)
> > > < John.Interrante@ge.com> wrote:
> > >
> > >> I agree, an .editorconfig file at the root of daffodil coupled with
> > >> IDE plugins (some IDEs such as IDEA already support .editorconfig
> > >> without
> > any
> > >> plugin needed) could autoconfigure the following IDE settings
> > automatically
> > >> (if we felt we needed to specify all of these settings):
> > >>
> > >> root = true
> > >> # All files (risky - could change bin/dat files inadvertently) [*]
> > >> end_of_line = lf charset = utf-8 trim_trailing_whitespace = true
> > >> insert_final_newline = true indent_style = space indent_size = 2 #
> > >> Can narrow scope to only source code files [*.{java,scala,xml}]
> > >> indent_style = space indent_size = 2
> > >>
> > >> EditorConfig plugins format only newly typed lines with these
> > >> settings; they do not reformat existing files, meaning only files
> > >> actually
> > changed by
> > >> one's commit will be affected by these settings. There are
> > >> separate command-line tools that can check, infer, or fix
> > >> EditorConfig rules
> > across
> > >> one or more directories/files in a repository manually. I think
> > >> using
> > one
> > >> of these tools such as eclint would be essential for writing a
> > >> proper .editorconfig that narrows its scope as much as possible
> > >> (e.g., we don't want to change existing bin or dat or tdml files
> > >> inadvertently when
> > editing
> > >> a single character within them in Emacs or IDEA because many of
> > >> them use other charsets and are not source code).
> > >>
> > >> There's a nice long list of projects already using EditorConfig
> > >> with
> > links
> > >> to their .editorconfig files. We also can look for similar
> > >> projects to Daffodil to see how they scope their .editorconfig
> > >> rules for their own files, but again, using "eclint infer" and
> > >> "eclint check" seems the
> > safest
> > >> way to me.
> > >>
> > >> John
> > >>
> > >> -----Original Message-----
> > >> From: Beckerle, Mike <mb...@owlcyberdefense.com>
> > >> Sent: Monday, April 19, 2021 9:56 AM
> > >> To: dev@daffodil.apache.org
> > >> Subject: EXT: editconfig
> > >>
> > >> https://editorconfig.org/
> > >>
> > >> This is interesting and we should consider adding these files to
> > >> the
> > root
> > >> of daffodil both as a declaration of the code-style, and a way that
> > >> auto-configures many IDEs and tools (like github).
> > >>
> > >> This does not appear to be sophisticated enough to really cover
> > code-style
> > >> issues at all, but at least basic whitespace stuff like spaces not
> > >> tabs, 2-space indenting, etc. would be covered.
> > >>
> > >>
> > >>
> > >
> >
> >
>
Re: editconfig
Posted by John Wass <jw...@gmail.com>.
> As a Scala project, however, how about using Scalafmt?
I'm in favor of scalafmt also.
> But I assume scalafmt won't cover other files like XML/schema/tdml/text
files.
Take a look at https://github.com/diffplug/spotless
Spotless says it could support all of those, and a quick search says the
SBT plugin is backed by scalafmt.
(I haven't used Spotless, just saw it today and thought of this thread)
On Mon, Apr 19, 2021 at 3:17 PM Interrante, John A (GE Research, US) <
John.Interrante@ge.com> wrote:
> I concur with Steve; we're going to need both a scalafmt configuration
> file and an .editorconfig file to cover all source code files unless the
> day comes when scalafmt understands .editorconfig and we're happy with
> scalafmt's default formatting options.
>
> Daffodil's existing code style is supposed to be very close to
> scalariform's default formatting options. Does anyone know how different
> scalafmt's default formatting options are from scalariform's? If they're
> not that different, eventually we might end up with just .editorconfig.
>
> -----Original Message-----
> From: Adam Rosien <ad...@rosien.net>
> Sent: Monday, April 19, 2021 12:16 PM
> To: dev@daffodil.apache.org
> Subject: EXT: Re: editconfig
>
> Ah, thanks for the extra context. I'll check out the JIRA issue.
>
> FYI there's an editorconfig integration issue open for scalafmt:
> https://github.com/scalameta/scalafmt/issues/1458.
>
> .. Adam
>
> On Mon, Apr 19, 2021 at 8:51 AM Steve Lawrence <sl...@apache.org>
> wrote:
>
> > As long as scalafmt covers everything editconfig supports and the
> > popular IDE's support it, we'd probably get better results for our
> > scala files. But I assume scalafmt won't cover other files like
> > XML/schema/tdml/text files. We might need a combination of the two to
> > cover all files?
> >
> > See https://issues.apache.org/jira/browse/DAFFODIL-2133 for related
> issue.
> >
> > - Steve
> >
> > On 4/19/21 11:37 AM, Adam Rosien wrote:
> > > As a Scala project, however, how about using Scalafmt? [1] It's
> > > become standard in all the projects I've been involved with; it's
> > > supported by
> > the
> > > language creators and matches the previously mentioned features.
> > >
> > > .. Adam
> > >
> > > [1] https://scalameta.org/scalafmt/
> > >
> > > On Mon, Apr 19, 2021 at 8:20 AM Interrante, John A (GE Research, US)
> > > < John.Interrante@ge.com> wrote:
> > >
> > >> I agree, an .editorconfig file at the root of daffodil coupled with
> > >> IDE plugins (some IDEs such as IDEA already support .editorconfig
> > >> without
> > any
> > >> plugin needed) could autoconfigure the following IDE settings
> > automatically
> > >> (if we felt we needed to specify all of these settings):
> > >>
> > >> root = true
> > >> # All files (risky - could change bin/dat files inadvertently) [*]
> > >> end_of_line = lf charset = utf-8 trim_trailing_whitespace = true
> > >> insert_final_newline = true indent_style = space indent_size = 2 #
> > >> Can narrow scope to only source code files [*.{java,scala,xml}]
> > >> indent_style = space indent_size = 2
> > >>
> > >> EditorConfig plugins format only newly typed lines with these
> > >> settings; they do not reformat existing files, meaning only files
> > >> actually
> > changed by
> > >> one's commit will be affected by these settings. There are
> > >> separate command-line tools that can check, infer, or fix
> > >> EditorConfig rules
> > across
> > >> one or more directories/files in a repository manually. I think
> > >> using
> > one
> > >> of these tools such as eclint would be essential for writing a
> > >> proper .editorconfig that narrows its scope as much as possible
> > >> (e.g., we don't want to change existing bin or dat or tdml files
> > >> inadvertently when
> > editing
> > >> a single character within them in Emacs or IDEA because many of
> > >> them use other charsets and are not source code).
> > >>
> > >> There's a nice long list of projects already using EditorConfig
> > >> with
> > links
> > >> to their .editorconfig files. We also can look for similar
> > >> projects to Daffodil to see how they scope their .editorconfig
> > >> rules for their own files, but again, using "eclint infer" and
> > >> "eclint check" seems the
> > safest
> > >> way to me.
> > >>
> > >> John
> > >>
> > >> -----Original Message-----
> > >> From: Beckerle, Mike <mb...@owlcyberdefense.com>
> > >> Sent: Monday, April 19, 2021 9:56 AM
> > >> To: dev@daffodil.apache.org
> > >> Subject: EXT: editconfig
> > >>
> > >> https://editorconfig.org/
> > >>
> > >> This is interesting and we should consider adding these files to
> > >> the
> > root
> > >> of daffodil both as a declaration of the code-style, and a way that
> > >> auto-configures many IDEs and tools (like github).
> > >>
> > >> This does not appear to be sophisticated enough to really cover
> > code-style
> > >> issues at all, but at least basic whitespace stuff like spaces not
> > >> tabs, 2-space indenting, etc. would be covered.
> > >>
> > >>
> > >>
> > >
> >
> >
>
editconfig
Posted by "Interrante, John A (GE Research, US)" <Jo...@ge.com>.
I concur with Steve; we're going to need both a scalafmt configuration file and an .editorconfig file to cover all source code files unless the day comes when scalafmt understands .editorconfig and we're happy with scalafmt's default formatting options.
Daffodil's existing code style is supposed to be very close to scalariform's default formatting options. Does anyone know how different scalafmt's default formatting options are from scalariform's? If they're not that different, eventually we might end up with just .editorconfig.
-----Original Message-----
From: Adam Rosien <ad...@rosien.net>
Sent: Monday, April 19, 2021 12:16 PM
To: dev@daffodil.apache.org
Subject: EXT: Re: editconfig
Ah, thanks for the extra context. I'll check out the JIRA issue.
FYI there's an editorconfig integration issue open for scalafmt:
https://github.com/scalameta/scalafmt/issues/1458.
.. Adam
On Mon, Apr 19, 2021 at 8:51 AM Steve Lawrence <sl...@apache.org> wrote:
> As long as scalafmt covers everything editconfig supports and the
> popular IDE's support it, we'd probably get better results for our
> scala files. But I assume scalafmt won't cover other files like
> XML/schema/tdml/text files. We might need a combination of the two to
> cover all files?
>
> See https://issues.apache.org/jira/browse/DAFFODIL-2133 for related issue.
>
> - Steve
>
> On 4/19/21 11:37 AM, Adam Rosien wrote:
> > As a Scala project, however, how about using Scalafmt? [1] It's
> > become standard in all the projects I've been involved with; it's
> > supported by
> the
> > language creators and matches the previously mentioned features.
> >
> > .. Adam
> >
> > [1] https://scalameta.org/scalafmt/
> >
> > On Mon, Apr 19, 2021 at 8:20 AM Interrante, John A (GE Research, US)
> > < John.Interrante@ge.com> wrote:
> >
> >> I agree, an .editorconfig file at the root of daffodil coupled with
> >> IDE plugins (some IDEs such as IDEA already support .editorconfig
> >> without
> any
> >> plugin needed) could autoconfigure the following IDE settings
> automatically
> >> (if we felt we needed to specify all of these settings):
> >>
> >> root = true
> >> # All files (risky - could change bin/dat files inadvertently) [*]
> >> end_of_line = lf charset = utf-8 trim_trailing_whitespace = true
> >> insert_final_newline = true indent_style = space indent_size = 2 #
> >> Can narrow scope to only source code files [*.{java,scala,xml}]
> >> indent_style = space indent_size = 2
> >>
> >> EditorConfig plugins format only newly typed lines with these
> >> settings; they do not reformat existing files, meaning only files
> >> actually
> changed by
> >> one's commit will be affected by these settings. There are
> >> separate command-line tools that can check, infer, or fix
> >> EditorConfig rules
> across
> >> one or more directories/files in a repository manually. I think
> >> using
> one
> >> of these tools such as eclint would be essential for writing a
> >> proper .editorconfig that narrows its scope as much as possible
> >> (e.g., we don't want to change existing bin or dat or tdml files
> >> inadvertently when
> editing
> >> a single character within them in Emacs or IDEA because many of
> >> them use other charsets and are not source code).
> >>
> >> There's a nice long list of projects already using EditorConfig
> >> with
> links
> >> to their .editorconfig files. We also can look for similar
> >> projects to Daffodil to see how they scope their .editorconfig
> >> rules for their own files, but again, using "eclint infer" and
> >> "eclint check" seems the
> safest
> >> way to me.
> >>
> >> John
> >>
> >> -----Original Message-----
> >> From: Beckerle, Mike <mb...@owlcyberdefense.com>
> >> Sent: Monday, April 19, 2021 9:56 AM
> >> To: dev@daffodil.apache.org
> >> Subject: EXT: editconfig
> >>
> >> https://editorconfig.org/
> >>
> >> This is interesting and we should consider adding these files to
> >> the
> root
> >> of daffodil both as a declaration of the code-style, and a way that
> >> auto-configures many IDEs and tools (like github).
> >>
> >> This does not appear to be sophisticated enough to really cover
> code-style
> >> issues at all, but at least basic whitespace stuff like spaces not
> >> tabs, 2-space indenting, etc. would be covered.
> >>
> >>
> >>
> >
>
>
Re: editconfig
Posted by Adam Rosien <ad...@rosien.net>.
Ah, thanks for the extra context. I'll check out the JIRA issue.
FYI there's an editorconfig integration issue open for scalafmt:
https://github.com/scalameta/scalafmt/issues/1458.
.. Adam
On Mon, Apr 19, 2021 at 8:51 AM Steve Lawrence <sl...@apache.org> wrote:
> As long as scalafmt covers everything editconfig supports and the
> popular IDE's support it, we'd probably get better results for our scala
> files. But I assume scalafmt won't cover other files like
> XML/schema/tdml/text files. We might need a combination of the two to
> cover all files?
>
> See https://issues.apache.org/jira/browse/DAFFODIL-2133 for related issue.
>
> - Steve
>
> On 4/19/21 11:37 AM, Adam Rosien wrote:
> > As a Scala project, however, how about using Scalafmt? [1] It's become
> > standard in all the projects I've been involved with; it's supported by
> the
> > language creators and matches the previously mentioned features.
> >
> > .. Adam
> >
> > [1] https://scalameta.org/scalafmt/
> >
> > On Mon, Apr 19, 2021 at 8:20 AM Interrante, John A (GE Research, US) <
> > John.Interrante@ge.com> wrote:
> >
> >> I agree, an .editorconfig file at the root of daffodil coupled with IDE
> >> plugins (some IDEs such as IDEA already support .editorconfig without
> any
> >> plugin needed) could autoconfigure the following IDE settings
> automatically
> >> (if we felt we needed to specify all of these settings):
> >>
> >> root = true
> >> # All files (risky - could change bin/dat files inadvertently)
> >> [*]
> >> end_of_line = lf
> >> charset = utf-8
> >> trim_trailing_whitespace = true
> >> insert_final_newline = true
> >> indent_style = space
> >> indent_size = 2
> >> # Can narrow scope to only source code files
> >> [*.{java,scala,xml}]
> >> indent_style = space
> >> indent_size = 2
> >>
> >> EditorConfig plugins format only newly typed lines with these settings;
> >> they do not reformat existing files, meaning only files actually
> changed by
> >> one's commit will be affected by these settings. There are separate
> >> command-line tools that can check, infer, or fix EditorConfig rules
> across
> >> one or more directories/files in a repository manually. I think using
> one
> >> of these tools such as eclint would be essential for writing a proper
> >> .editorconfig that narrows its scope as much as possible (e.g., we don't
> >> want to change existing bin or dat or tdml files inadvertently when
> editing
> >> a single character within them in Emacs or IDEA because many of them use
> >> other charsets and are not source code).
> >>
> >> There's a nice long list of projects already using EditorConfig with
> links
> >> to their .editorconfig files. We also can look for similar projects to
> >> Daffodil to see how they scope their .editorconfig rules for their own
> >> files, but again, using "eclint infer" and "eclint check" seems the
> safest
> >> way to me.
> >>
> >> John
> >>
> >> -----Original Message-----
> >> From: Beckerle, Mike <mb...@owlcyberdefense.com>
> >> Sent: Monday, April 19, 2021 9:56 AM
> >> To: dev@daffodil.apache.org
> >> Subject: EXT: editconfig
> >>
> >> https://editorconfig.org/
> >>
> >> This is interesting and we should consider adding these files to the
> root
> >> of daffodil both as a declaration of the code-style, and a way that
> >> auto-configures many IDEs and tools (like github).
> >>
> >> This does not appear to be sophisticated enough to really cover
> code-style
> >> issues at all, but at least basic whitespace stuff like spaces not tabs,
> >> 2-space indenting, etc. would be covered.
> >>
> >>
> >>
> >
>
>
Re: editconfig
Posted by Steve Lawrence <sl...@apache.org>.
As long as scalafmt covers everything editconfig supports and the
popular IDE's support it, we'd probably get better results for our scala
files. But I assume scalafmt won't cover other files like
XML/schema/tdml/text files. We might need a combination of the two to
cover all files?
See https://issues.apache.org/jira/browse/DAFFODIL-2133 for related issue.
- Steve
On 4/19/21 11:37 AM, Adam Rosien wrote:
> As a Scala project, however, how about using Scalafmt? [1] It's become
> standard in all the projects I've been involved with; it's supported by the
> language creators and matches the previously mentioned features.
>
> .. Adam
>
> [1] https://scalameta.org/scalafmt/
>
> On Mon, Apr 19, 2021 at 8:20 AM Interrante, John A (GE Research, US) <
> John.Interrante@ge.com> wrote:
>
>> I agree, an .editorconfig file at the root of daffodil coupled with IDE
>> plugins (some IDEs such as IDEA already support .editorconfig without any
>> plugin needed) could autoconfigure the following IDE settings automatically
>> (if we felt we needed to specify all of these settings):
>>
>> root = true
>> # All files (risky - could change bin/dat files inadvertently)
>> [*]
>> end_of_line = lf
>> charset = utf-8
>> trim_trailing_whitespace = true
>> insert_final_newline = true
>> indent_style = space
>> indent_size = 2
>> # Can narrow scope to only source code files
>> [*.{java,scala,xml}]
>> indent_style = space
>> indent_size = 2
>>
>> EditorConfig plugins format only newly typed lines with these settings;
>> they do not reformat existing files, meaning only files actually changed by
>> one's commit will be affected by these settings. There are separate
>> command-line tools that can check, infer, or fix EditorConfig rules across
>> one or more directories/files in a repository manually. I think using one
>> of these tools such as eclint would be essential for writing a proper
>> .editorconfig that narrows its scope as much as possible (e.g., we don't
>> want to change existing bin or dat or tdml files inadvertently when editing
>> a single character within them in Emacs or IDEA because many of them use
>> other charsets and are not source code).
>>
>> There's a nice long list of projects already using EditorConfig with links
>> to their .editorconfig files. We also can look for similar projects to
>> Daffodil to see how they scope their .editorconfig rules for their own
>> files, but again, using "eclint infer" and "eclint check" seems the safest
>> way to me.
>>
>> John
>>
>> -----Original Message-----
>> From: Beckerle, Mike <mb...@owlcyberdefense.com>
>> Sent: Monday, April 19, 2021 9:56 AM
>> To: dev@daffodil.apache.org
>> Subject: EXT: editconfig
>>
>> https://editorconfig.org/
>>
>> This is interesting and we should consider adding these files to the root
>> of daffodil both as a declaration of the code-style, and a way that
>> auto-configures many IDEs and tools (like github).
>>
>> This does not appear to be sophisticated enough to really cover code-style
>> issues at all, but at least basic whitespace stuff like spaces not tabs,
>> 2-space indenting, etc. would be covered.
>>
>>
>>
>
Re: editconfig
Posted by Adam Rosien <ad...@rosien.net>.
As a Scala project, however, how about using Scalafmt? [1] It's become
standard in all the projects I've been involved with; it's supported by the
language creators and matches the previously mentioned features.
.. Adam
[1] https://scalameta.org/scalafmt/
On Mon, Apr 19, 2021 at 8:20 AM Interrante, John A (GE Research, US) <
John.Interrante@ge.com> wrote:
> I agree, an .editorconfig file at the root of daffodil coupled with IDE
> plugins (some IDEs such as IDEA already support .editorconfig without any
> plugin needed) could autoconfigure the following IDE settings automatically
> (if we felt we needed to specify all of these settings):
>
> root = true
> # All files (risky - could change bin/dat files inadvertently)
> [*]
> end_of_line = lf
> charset = utf-8
> trim_trailing_whitespace = true
> insert_final_newline = true
> indent_style = space
> indent_size = 2
> # Can narrow scope to only source code files
> [*.{java,scala,xml}]
> indent_style = space
> indent_size = 2
>
> EditorConfig plugins format only newly typed lines with these settings;
> they do not reformat existing files, meaning only files actually changed by
> one's commit will be affected by these settings. There are separate
> command-line tools that can check, infer, or fix EditorConfig rules across
> one or more directories/files in a repository manually. I think using one
> of these tools such as eclint would be essential for writing a proper
> .editorconfig that narrows its scope as much as possible (e.g., we don't
> want to change existing bin or dat or tdml files inadvertently when editing
> a single character within them in Emacs or IDEA because many of them use
> other charsets and are not source code).
>
> There's a nice long list of projects already using EditorConfig with links
> to their .editorconfig files. We also can look for similar projects to
> Daffodil to see how they scope their .editorconfig rules for their own
> files, but again, using "eclint infer" and "eclint check" seems the safest
> way to me.
>
> John
>
> -----Original Message-----
> From: Beckerle, Mike <mb...@owlcyberdefense.com>
> Sent: Monday, April 19, 2021 9:56 AM
> To: dev@daffodil.apache.org
> Subject: EXT: editconfig
>
> https://editorconfig.org/
>
> This is interesting and we should consider adding these files to the root
> of daffodil both as a declaration of the code-style, and a way that
> auto-configures many IDEs and tools (like github).
>
> This does not appear to be sophisticated enough to really cover code-style
> issues at all, but at least basic whitespace stuff like spaces not tabs,
> 2-space indenting, etc. would be covered.
>
>
>
RE: editconfig
Posted by "Interrante, John A (GE Research, US)" <Jo...@ge.com>.
I agree, an .editorconfig file at the root of daffodil coupled with IDE plugins (some IDEs such as IDEA already support .editorconfig without any plugin needed) could autoconfigure the following IDE settings automatically (if we felt we needed to specify all of these settings):
root = true
# All files (risky - could change bin/dat files inadvertently)
[*]
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
indent_style = space
indent_size = 2
# Can narrow scope to only source code files
[*.{java,scala,xml}]
indent_style = space
indent_size = 2
EditorConfig plugins format only newly typed lines with these settings; they do not reformat existing files, meaning only files actually changed by one's commit will be affected by these settings. There are separate command-line tools that can check, infer, or fix EditorConfig rules across one or more directories/files in a repository manually. I think using one of these tools such as eclint would be essential for writing a proper .editorconfig that narrows its scope as much as possible (e.g., we don't want to change existing bin or dat or tdml files inadvertently when editing a single character within them in Emacs or IDEA because many of them use other charsets and are not source code).
There's a nice long list of projects already using EditorConfig with links to their .editorconfig files. We also can look for similar projects to Daffodil to see how they scope their .editorconfig rules for their own files, but again, using "eclint infer" and "eclint check" seems the safest way to me.
John
-----Original Message-----
From: Beckerle, Mike <mb...@owlcyberdefense.com>
Sent: Monday, April 19, 2021 9:56 AM
To: dev@daffodil.apache.org
Subject: EXT: editconfig
https://editorconfig.org/
This is interesting and we should consider adding these files to the root of daffodil both as a declaration of the code-style, and a way that auto-configures many IDEs and tools (like github).
This does not appear to be sophisticated enough to really cover code-style issues at all, but at least basic whitespace stuff like spaces not tabs, 2-space indenting, etc. would be covered.