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 <jwa...@gmail.com> Sent: Wednesday, April 21, 2021 11:46 AM To: dev@daffodil.apache.org <dev@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.interra...@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 <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. > > >> > > >> > > >> > > > > > > > >
