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 <slawre...@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.interra...@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 <mbecke...@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. > >> > >> > >> > > > >
