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 <a...@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 <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. > >> > >> > >> > > > >
