It is currently limited to a subset of the code - reformatted the code that's already formatted, so a no-ip. See exclusions in spotless.gradle. You need to add the module there and then perhaps limit to a single package so that the diff is not too overwhelming.
On Tue, Dec 22, 2020 at 11:58 PM David Smiley <[email protected]> wrote: > > I tried to use this on master for a particular module lucene/spatial-extras > to see what happens. I ran "gw tidy" and it ran the tasks but did nothing > discernable. Any clues what to do? > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Tue, Dec 22, 2020 at 1:58 PM Dawid Weiss <[email protected]> wrote: >> >> Yeah - those single-line comments that were broken are mostly because >> they were just too long to fit in a single line. Other blocks (with >> shorter single-line >> comments) were just fine. >> >> I've seen a couple other oddities resulting from //-type comments >> inside statements >> or right after variable declarations. These are wrapped in an >> unintuitive way too. >> I moved a few (so that they appeared before the variable) but >> otherwise didn't want >> to change too much. Like I said - these things can be corrected/ moved >> later on (and reformatted). >> >> > it's not always easy to coordinate sweeping changes while others continue >> > to mess around! >> >> True. That's why I wanted to have it done fairly quickly so that we >> can just move on. I'll finish >> one or two modules myself to get the corner cases right and then I'll >> probably ask for help. >> Viewing the diff a package-at-a-time takes fairly little effort (5-10 >> minutes) and it'd help enormously >> if we could somehow parallelise this effort over multiple people. I'll >> let you all know when I think >> it's ready; a day or two should be enough for me. >> >> Dawid >> >> On Tue, Dec 22, 2020 at 7:12 PM Michael Sokolov <[email protected]> wrote: >> > >> > Yes, that is what I saw; line breaking choices that are different than >> > what I would manually have chosen. I don't mean to sound negative - >> > this is a nice improvement that gets us away from having to fuss about >> > indentation and other formatting. Even regarding these line breaks, it >> > is sensible to have the control to insist that single-line comments >> > are not merged where block comments are merged and reflowed, so we'll >> > learn to adapt to its rules and get things looking the way we want. >> > Thanks, Dawid for pushing ahead with this, it's not always easy to >> > coordinate sweeping changes while others continue to mess around! >> > >> > -Mike >> > >> > On Tue, Dec 22, 2020 at 12:49 PM Dawid Weiss <[email protected]> wrote: >> > > >> > > > I see it there - yes, it makes some occasional widows, and sometimes >> > > > fails to join up consecutive single-line comments (I think you >> > > > mentioned this elsewhere) but I can live with it :) >> > > >> > > I review those diffs manually (for now at least). Some things are indeed >> > > more verbose but I think they can be lived with (or corrected manually >> > > at a later time). >> > > >> > > Single-line comments leave (typographical) widows when a long >> > > single-line comment is broken because it exceeds line length. >> > > To me the formatter intentionally doesn't treat consecutive >> > > single-line comments as a block; it breaks long single-lines but >> > > doesn't reflow them. So: >> > > >> > > // really really long comment on a single line >> > > // that looks like this >> > > >> > > could be broken into: >> > > >> > > // really really long comment on a single >> > > // line >> > > // that looks like this >> > > >> > > I've seen examples when a reflow would actually corrupt the content of >> > > the message so I guess no solution is ideal. If it's a block comment >> > > then it should be a /* */ - then (again, I think) the content >> > > undergoes a reflow. >> > > >> > > All this said, I think overall it's doing a great job, especially with >> > > inconsistencies around operators, indents, javadoc etc. Sometimes it >> > > tends to be verbose with method calls that have an insane number of >> > > parameters (lining up over multiple lines). I've grown used to it - >> > > it's really something you just live with after a while. And when it's >> > > particularly bothersome, I just reformat the code somehow to have >> > > fewer arguments, break long arithmetics into smaller local variables, >> > > etc. This can be done gradually at a later time. >> > > >> > > So far I am pretty happy with what I've seen in those diffs though. >> > > >> > > Dawid >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
