Re: Code reformatting
I think the issue should be kept to reformatting, with minimal intrusions where the formatter doesn't handle the code well (because the code was hand-aligned for some purpose - as in javadoc explaining term positions, etc.). Enforcing braces policy is another thing (that would require a separate tool). Perhaps worth considering, but it's a follow-up to me, not part of the issue. It's already complex and large enough to handle. > if (something) >blah These are indeed terrible. I sometimes do correct them manually. D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Code reformatting
I like braces too. For this kind of mass edit though, I’m not about to
start changing anything that isn’t already touched by the formatter,
that’s a never-ending rat-hole and rife with possibilities to screw
up.
What that means in this case is that the formatter changes
if (something)
blah
to
if (something) blah
and it shows up in the diff.
Since the last person to deal with that code intended “blah” to be
on a separate line, I’ll add braces put “blah” back on it’s own line:
if (something) {
blah
}
OTOH, since the formatter doesn’t touch
if (something) blah
I won’t either. I’m sure I’ll miss some, but since it’s functionally equivalent
I don’t care. BTW, I’ve even seen a couple of
for (whatever)
blah;
which I think is horrible. Again, though, if the formatter touches it I’ll
put in braces, otherwise I won’t even see it.
Martin Fowler in his book “refactoring” argues that there’s no
point in rewriting code _unless_ it’s relevant to a problem you’re solving.
In this case that means something that’s being reformatted anyway….
FWIW,
Erick
> On Dec 24, 2020, at 1:40 PM, Gus Heck wrote:
>
> +1 to always braces
>
> On Thu, Dec 24, 2020 at 11:47 AM Michael Sokolov wrote:
> The Google convention you cited says this, I think?
>
> >Braces are used with if, else, for, do and while statements, even when
> > the body is empty or contains only a single statement.
>
> On Thu, Dec 24, 2020 at 8:00 AM Dawid Weiss wrote:
> >
> > > Personally I would ban the non block conditional, but I think it's moot
> > > in this context since spotless just does what it does and is not
> > > configurable, as I understand it. I suppose we could manually "fix" all
> > > the conditionals though?
> >
> > I'm pretty sure you could do it automatically... But in many places
> > there is very little sense in doing that. That google format
> > convention [1] is fairly reasonable to me - strict in certain aspects
> > and relaxed elsewhere. I wouldn't enforce it. If you find a place that
> > could use more clarity with braces, correct it (and re-run the
> > formatting) then commit it back in.
> >
> > Dawid
> >
> > https://google.github.io/styleguide/javaguide.html
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Code reformatting
+1 to always braces On Thu, Dec 24, 2020 at 11:47 AM Michael Sokolov wrote: > The Google convention you cited says this, I think? > > >Braces are used with if, else, for, do and while statements, even > when the body is empty or contains only a single statement. > > On Thu, Dec 24, 2020 at 8:00 AM Dawid Weiss wrote: > > > > > Personally I would ban the non block conditional, but I think it's > moot in this context since spotless just does what it does and is not > configurable, as I understand it. I suppose we could manually "fix" all the > conditionals though? > > > > I'm pretty sure you could do it automatically... But in many places > > there is very little sense in doing that. That google format > > convention [1] is fairly reasonable to me - strict in certain aspects > > and relaxed elsewhere. I wouldn't enforce it. If you find a place that > > could use more clarity with braces, correct it (and re-run the > > formatting) then commit it back in. > > > > Dawid > > > > https://google.github.io/styleguide/javaguide.html > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
Re: Code reformatting
The Google convention you cited says this, I think? >Braces are used with if, else, for, do and while statements, even when the > body is empty or contains only a single statement. On Thu, Dec 24, 2020 at 8:00 AM Dawid Weiss wrote: > > > Personally I would ban the non block conditional, but I think it's moot in > > this context since spotless just does what it does and is not configurable, > > as I understand it. I suppose we could manually "fix" all the conditionals > > though? > > I'm pretty sure you could do it automatically... But in many places > there is very little sense in doing that. That google format > convention [1] is fairly reasonable to me - strict in certain aspects > and relaxed elsewhere. I wouldn't enforce it. If you find a place that > could use more clarity with braces, correct it (and re-run the > formatting) then commit it back in. > > Dawid > > https://google.github.io/styleguide/javaguide.html > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Code reformatting
> Personally I would ban the non block conditional, but I think it's moot in > this context since spotless just does what it does and is not configurable, > as I understand it. I suppose we could manually "fix" all the conditionals > though? I'm pretty sure you could do it automatically... But in many places there is very little sense in doing that. That google format convention [1] is fairly reasonable to me - strict in certain aspects and relaxed elsewhere. I wouldn't enforce it. If you find a place that could use more clarity with braces, correct it (and re-run the formatting) then commit it back in. Dawid https://google.github.io/styleguide/javaguide.html - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Code reformatting
Personally I would ban the non block conditional, but I think it's moot in
this context since spotless just does what it does and is not configurable,
as I understand it. I suppose we could manually "fix" all the conditionals
though?
On Wed, Dec 23, 2020, 9:07 AM Erick Erickson
wrote:
> I took a quick look at lucene/queries just to get my feet wet. Before
> working on it seriously. I did a fast scan through about half of the
> changes and have only one question.
>
> The formatter tightens up non-block comments, i.e.
>
> if (this == obj)
> return true;
>
> becomes
>
> if (this == obj) return true;
>
> Which one is clearer is always a matter of debate, but my take is that
> braces should be added when the _original_ code was on multiple lines,
> respecting the opinion of the author. So the above would get braces added
> manually:
>
> if (this == obj) {
> return true;
> }
>
> However, if the original code were:
>
> if( this == obj ) return true;
>
> and it reformatted to:
>
> if (this == obj) return true;
>
> leave it be.
>
> Does this align with other people’s opinion?
>
> Or is the consensus that any changed non-block should have braces added on
> the theory that braces are always clearer and the code was changed anyway?
> In which case the second example would get braces.
>
> I don’t particularly have any strong opinion, and I don’t think we need to
> be draconian about it, just thought that I’d do whatever others are doing.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
Re: Code reformatting
> The formatter tightens up non-block comments, i.e. > > if (this == obj) > return true; > > becomes > > if (this == obj) return true; Yes, correct. > Which one is clearer is always a matter of debate, but my take is that braces > should be added when the _original_ code was on multiple lines, respecting > the opinion of the author. So the above would get braces added manually: Braces won't get added automatically. I've seen this in a number of places and decided some of them are clear and legible, others maybe less so. Depends on the context. I'm myself in favor of braces. If you manually correct the code to have braces, the formatter will respect this. But it's your decision - it won't add (or strip) things from the code automatically. You need to add those braces, where you think they look better or add to legibility. > I don’t particularly have any strong opinion, and I don’t think we need to be > draconian about it, just thought that I’d do whatever others are doing. I corrected this in a few places where I thought this may be misleading. In many others it's clear what's happening. Like I said - if you see the code (after reformatting) that would benefit from braces, add them and tidy up again. Those braces won't be removed. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Code reformatting
They both look fine to me, I’d likely go with the default so that there is
less for us to maintain.
On Wed, Dec 23, 2020 at 8:08 AM Erick Erickson
wrote:
> I took a quick look at lucene/queries just to get my feet wet. Before
> working on it seriously. I did a fast scan through about half of the
> changes and have only one question.
>
> The formatter tightens up non-block comments, i.e.
>
> if (this == obj)
> return true;
>
> becomes
>
> if (this == obj) return true;
>
> Which one is clearer is always a matter of debate, but my take is that
> braces should be added when the _original_ code was on multiple lines,
> respecting the opinion of the author. So the above would get braces added
> manually:
>
> if (this == obj) {
> return true;
> }
>
> However, if the original code were:
>
> if( this == obj ) return true;
>
> and it reformatted to:
>
> if (this == obj) return true;
>
> leave it be.
>
> Does this align with other people’s opinion?
>
> Or is the consensus that any changed non-block should have braces added on
> the theory that braces are always clearer and the code was changed anyway?
> In which case the second example would get braces.
>
> I don’t particularly have any strong opinion, and I don’t think we need to
> be draconian about it, just thought that I’d do whatever others are doing.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
Re: Code reformatting
I like this one,
> if (this == obj) {
> return true;
> }
Regards, r00t4dm
Cloud-Penetrating Arrow Lab of Meituan Corp Information Security Department
> 2020年12月23日 下午10:07，Erick Erickson 写道：
>
> I took a quick look at lucene/queries just to get my feet wet. Before working
> on it seriously. I did a fast scan through about half of the changes and have
> only one question.
>
> The formatter tightens up non-block comments, i.e.
>
> if (this == obj)
> return true;
>
> becomes
>
> if (this == obj) return true;
>
> Which one is clearer is always a matter of debate, but my take is that braces
> should be added when the _original_ code was on multiple lines, respecting
> the opinion of the author. So the above would get braces added manually:
>
> if (this == obj) {
> return true;
> }
>
> However, if the original code were:
>
> if( this == obj ) return true;
>
> and it reformatted to:
>
> if (this == obj) return true;
>
> leave it be.
>
> Does this align with other people’s opinion?
>
> Or is the consensus that any changed non-block should have braces added on
> the theory that braces are always clearer and the code was changed anyway? In
> which case the second example would get braces.
>
> I don’t particularly have any strong opinion, and I don’t think we need to be
> draconian about it, just thought that I’d do whatever others are doing.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Code reformatting
I took a quick look at lucene/queries just to get my feet wet. Before working
on it seriously. I did a fast scan through about half of the changes and have
only one question.
The formatter tightens up non-block comments, i.e.
if (this == obj)
return true;
becomes
if (this == obj) return true;
Which one is clearer is always a matter of debate, but my take is that braces
should be added when the _original_ code was on multiple lines, respecting the
opinion of the author. So the above would get braces added manually:
if (this == obj) {
return true;
}
However, if the original code were:
if( this == obj ) return true;
and it reformatted to:
if (this == obj) return true;
leave it be.
Does this align with other people’s opinion?
Or is the consensus that any changed non-block should have braces added on the
theory that braces are always clearer and the code was changed anyway? In which
case the second example would get braces.
I don’t particularly have any strong opinion, and I don’t think we need to be
draconian about it, just thought that I’d do whatever others are doing.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Code reformatting
I added some instructions on how to help out here: https://issues.apache.org/jira/browse/LUCENE-9570 spotless.gradle has a long list of projects that need to be reviewed. You can pick a small one and take it from there. Dawid On Wed, Dec 23, 2020 at 8:07 AM Dawid Weiss wrote: > > 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 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 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 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 > >> > 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
Re: Code reformatting
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 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 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 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 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: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Code reformatting
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 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 > 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 > 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: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Code reformatting
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 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 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Code reformatting
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 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Code reformatting
> It is fine, if there are conflicts and will juggle them :) If you try to merge directly, there will be conflicts. But if you do what I describe below, it should require no manual assistance and will ease the pain to literally zero effort. // get the latest changes (I assume origin points at apache or github). git fetch origin // get your branch. I assume it compiles. git checkout my-branch // get the latest spotless scripts from master and apply it locally git checkout master -- gradle // reformat code on my-branch ./gradlew tidy git commit -am "Just applying the formatter" // now diff against the (reformatted) master - you should only see your local // changes; the code is formatted identically on both branches. git diff origin/master // and merge if you like. git merge origin/master D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Code reformatting
> 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Code reformatting
Hi Dawid, It is fine, if there are conflicts and will juggle them :) thanks for this effort, it is very cool! On Tue, Dec 22, 2020 at 5:04 PM Michael Sokolov 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 :) > > On Tue, Dec 22, 2020 at 10:07 AM Dawid Weiss > wrote: > > > > > Looks as if javadoc is likely to be the main challenge? > > > > Not really - it's all handled fairly well (automatically). I merged your > > changes to master branch and reformatted it locally, I'll merge back to > master > > soon. > > > > Dawid > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Code reformatting
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 :) On Tue, Dec 22, 2020 at 10:07 AM Dawid Weiss wrote: > > > Looks as if javadoc is likely to be the main challenge? > > Not really - it's all handled fairly well (automatically). I merged your > changes to master branch and reformatted it locally, I'll merge back to master > soon. > > Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Code reformatting
> Looks as if javadoc is likely to be the main challenge? Not really - it's all handled fairly well (automatically). I merged your changes to master branch and reformatted it locally, I'll merge back to master soon. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Code reformatting
Hmm, I committed my outstanding PR with no conflicts, so I assume you didn't get the reformatting in yet; let me know if *I* can help :) -MIke On Tue, Dec 22, 2020 at 9:06 AM Michael Sokolov wrote: > > Thanks for the heads up. If you commit your changes first, I'll tackle the > reformatting and let you know if I run into issues. Looks as if javadoc is > likely to be the main challenge? > > On Tue, Dec 22, 2020, 8:56 AM Dawid Weiss wrote: >> >> Hi Mike, Ignacio, >> >> Just wanted to let you know that I wanted to go through the rest of >> lucene-core reformatting soon-ish (I've done a lot on the branch >> already and a subset of packages ended on master too). >> >> This will touch packages which you've been working on recently. I >> don't think it'll be a problem, even if you have active modifications >> you're working on, although it may require a bit of manual juggling. >> >> In short, the process is fairly simple - get up-to-date >> spotless.gradle on to your branch (from master), then reformat the >> code on your branch and commit it. git should be smart enough to >> figure out the differences between your branch and master (after >> reformatting) - and these differences should be in your modified code >> only. >> >> Let me know if you need me to do this directly on any of your branches >> and I'll be happy to help. >> >> Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Code reformatting
Thanks for the heads up. If you commit your changes first, I'll tackle the reformatting and let you know if I run into issues. Looks as if javadoc is likely to be the main challenge? On Tue, Dec 22, 2020, 8:56 AM Dawid Weiss wrote: > Hi Mike, Ignacio, > > Just wanted to let you know that I wanted to go through the rest of > lucene-core reformatting soon-ish (I've done a lot on the branch > already and a subset of packages ended on master too). > > This will touch packages which you've been working on recently. I > don't think it'll be a problem, even if you have active modifications > you're working on, although it may require a bit of manual juggling. > > In short, the process is fairly simple - get up-to-date > spotless.gradle on to your branch (from master), then reformat the > code on your branch and commit it. git should be smart enough to > figure out the differences between your branch and master (after > reformatting) - and these differences should be in your modified code > only. > > Let me know if you need me to do this directly on any of your branches > and I'll be happy to help. > > Dawid >
Code reformatting
Hi Mike, Ignacio, Just wanted to let you know that I wanted to go through the rest of lucene-core reformatting soon-ish (I've done a lot on the branch already and a subset of packages ended on master too). This will touch packages which you've been working on recently. I don't think it'll be a problem, even if you have active modifications you're working on, although it may require a bit of manual juggling. In short, the process is fairly simple - get up-to-date spotless.gradle on to your branch (from master), then reformat the code on your branch and commit it. git should be smart enough to figure out the differences between your branch and master (after reformatting) - and these differences should be in your modified code only. Let me know if you need me to do this directly on any of your branches and I'll be happy to help. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [IMPORTANT] Automatic code reformatting (LUCENE-9564)
I am aware of this and I don't intend to touch Solr at the moment. Dawid On Thu, Dec 17, 2020 at 5:10 PM Ishan Chattopadhyaya wrote: > > Let's please leave the Solr side until 8.8 is out. Some big changes are in > flight and I don't want to waste time with the merges to the various branches. > > On Thu, 17 Dec, 2020, 8:43 pm Timothy Potter, wrote: >> >> Sounds great Dawid! And sorely needed in this project, thanks for taking >> this on. I'll do as much as I can on the Solr side ;-) >> >> Cheers, >> Tim >> >> On Thu, Dec 17, 2020 at 4:31 AM Dawid Weiss wrote: >>> >>> Hey everyone, >>> >>> Sorry it took me a while but I wanted to get back to LUCENE-9564 and >>> applying an automated (and non-configurable) code formatter. This will >>> cause some disruption to all existing branches and patches so I'd like >>> to make the process as simple as possible by doing the following: >>> >>> 1) adding spotless (formatter infrastructure) to gradle build on >>> master. This literally changes nothing as initially it wouldn't be >>> including any sources. >>> >>> 2) progressively go package-by-package and project-by-project and >>> reformat code, then commit it back to master. Splitting into smaller >>> work pieces is simpler and perhaps others may help in to review if the >>> formatter didn't screw up anything (I'll start!). >>> >>> 3) IF YOU HAVE AN OPEN PATCH or branch and the master is reformatted, >>> don't despair. It's actually pretty easy to recover -- all you'd need >>> to do would be to cherry pick the initial spotless commit from (1), >>> then take the up-to-date content of spotless.gradle and just run this >>> on your branch: >>> >>> ./gradlew tidy >>> >>> This should reformat the same packages and the same code as on master. >>> If nothing has changed, the diff between your branch and master should >>> be empty. If something *did* change, the reformatted code should still >>> cleanly show just the lines you've changed. >>> >>> Commit the changes to your branch and you should be fine. >>> >>> Does this sound like a plan? I'd like to start with the initial few >>> packages from the core and a few other projects so that folks can see >>> what the process looks like - then I'd really like a helping hand with >>> the rest. I'm only concerned with Lucene at the moment. >>> >>> Dawid >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [IMPORTANT] Automatic code reformatting (LUCENE-9564)
Let's please leave the Solr side until 8.8 is out. Some big changes are in flight and I don't want to waste time with the merges to the various branches. On Thu, 17 Dec, 2020, 8:43 pm Timothy Potter, wrote: > Sounds great Dawid! And sorely needed in this project, thanks for taking > this on. I'll do as much as I can on the Solr side ;-) > > Cheers, > Tim > > On Thu, Dec 17, 2020 at 4:31 AM Dawid Weiss wrote: > >> Hey everyone, >> >> Sorry it took me a while but I wanted to get back to LUCENE-9564 and >> applying an automated (and non-configurable) code formatter. This will >> cause some disruption to all existing branches and patches so I'd like >> to make the process as simple as possible by doing the following: >> >> 1) adding spotless (formatter infrastructure) to gradle build on >> master. This literally changes nothing as initially it wouldn't be >> including any sources. >> >> 2) progressively go package-by-package and project-by-project and >> reformat code, then commit it back to master. Splitting into smaller >> work pieces is simpler and perhaps others may help in to review if the >> formatter didn't screw up anything (I'll start!). >> >> 3) IF YOU HAVE AN OPEN PATCH or branch and the master is reformatted, >> don't despair. It's actually pretty easy to recover -- all you'd need >> to do would be to cherry pick the initial spotless commit from (1), >> then take the up-to-date content of spotless.gradle and just run this >> on your branch: >> >> ./gradlew tidy >> >> This should reformat the same packages and the same code as on master. >> If nothing has changed, the diff between your branch and master should >> be empty. If something *did* change, the reformatted code should still >> cleanly show just the lines you've changed. >> >> Commit the changes to your branch and you should be fine. >> >> Does this sound like a plan? I'd like to start with the initial few >> packages from the core and a few other projects so that folks can see >> what the process looks like - then I'd really like a helping hand with >> the rest. I'm only concerned with Lucene at the moment. >> >> Dawid >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
Re: [IMPORTANT] Automatic code reformatting (LUCENE-9564)
Sounds great Dawid! And sorely needed in this project, thanks for taking this on. I'll do as much as I can on the Solr side ;-) Cheers, Tim On Thu, Dec 17, 2020 at 4:31 AM Dawid Weiss wrote: > Hey everyone, > > Sorry it took me a while but I wanted to get back to LUCENE-9564 and > applying an automated (and non-configurable) code formatter. This will > cause some disruption to all existing branches and patches so I'd like > to make the process as simple as possible by doing the following: > > 1) adding spotless (formatter infrastructure) to gradle build on > master. This literally changes nothing as initially it wouldn't be > including any sources. > > 2) progressively go package-by-package and project-by-project and > reformat code, then commit it back to master. Splitting into smaller > work pieces is simpler and perhaps others may help in to review if the > formatter didn't screw up anything (I'll start!). > > 3) IF YOU HAVE AN OPEN PATCH or branch and the master is reformatted, > don't despair. It's actually pretty easy to recover -- all you'd need > to do would be to cherry pick the initial spotless commit from (1), > then take the up-to-date content of spotless.gradle and just run this > on your branch: > > ./gradlew tidy > > This should reformat the same packages and the same code as on master. > If nothing has changed, the diff between your branch and master should > be empty. If something *did* change, the reformatted code should still > cleanly show just the lines you've changed. > > Commit the changes to your branch and you should be fine. > > Does this sound like a plan? I'd like to start with the initial few > packages from the core and a few other projects so that folks can see > what the process looks like - then I'd really like a helping hand with > the rest. I'm only concerned with Lucene at the moment. > > Dawid > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[IMPORTANT] Automatic code reformatting (LUCENE-9564)
Hey everyone, Sorry it took me a while but I wanted to get back to LUCENE-9564 and applying an automated (and non-configurable) code formatter. This will cause some disruption to all existing branches and patches so I'd like to make the process as simple as possible by doing the following: 1) adding spotless (formatter infrastructure) to gradle build on master. This literally changes nothing as initially it wouldn't be including any sources. 2) progressively go package-by-package and project-by-project and reformat code, then commit it back to master. Splitting into smaller work pieces is simpler and perhaps others may help in to review if the formatter didn't screw up anything (I'll start!). 3) IF YOU HAVE AN OPEN PATCH or branch and the master is reformatted, don't despair. It's actually pretty easy to recover -- all you'd need to do would be to cherry pick the initial spotless commit from (1), then take the up-to-date content of spotless.gradle and just run this on your branch: ./gradlew tidy This should reformat the same packages and the same code as on master. If nothing has changed, the diff between your branch and master should be empty. If something *did* change, the reformatted code should still cleanly show just the lines you've changed. Commit the changes to your branch and you should be fine. Does this sound like a plan? I'd like to start with the initial few packages from the core and a few other projects so that folks can see what the process looks like - then I'd really like a helping hand with the rest. I'm only concerned with Lucene at the moment. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5747) Eclipse settings - prevent automatic code reformatting on save
[ https://issues.apache.org/jira/browse/LUCENE-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14025381#comment-14025381 ] ASF subversion and git services commented on LUCENE-5747: - Commit 1601446 from [~elyograg] in branch 'dev/trunk' [ https://svn.apache.org/r1601446 ] LUCENE-5747: Prevent automatic code reformatting when saving in eclipse Eclipse settings - prevent automatic code reformatting on save -- Key: LUCENE-5747 URL: https://issues.apache.org/jira/browse/LUCENE-5747 Project: Lucene - Core Issue Type: Bug Components: general/build Affects Versions: 4.8.1 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 4.9 Attachments: LUCENE-5747.patch, LUCENE-5747.patch If the user has Eclipse globally configured to automatically reformat code or reorganize imports on save, currently these actions will be performed, because the settings created by ant eclipse do not have any project-specific settings to disable it. This will add those project-specific settings. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5747) Eclipse settings - prevent automatic code reformatting on save
[ https://issues.apache.org/jira/browse/LUCENE-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey resolved LUCENE-5747. -- Resolution: Fixed Committed to trunk and branch_4x. Eclipse settings - prevent automatic code reformatting on save -- Key: LUCENE-5747 URL: https://issues.apache.org/jira/browse/LUCENE-5747 Project: Lucene - Core Issue Type: Bug Components: general/build Affects Versions: 4.8.1 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 4.9 Attachments: LUCENE-5747.patch, LUCENE-5747.patch If the user has Eclipse globally configured to automatically reformat code or reorganize imports on save, currently these actions will be performed, because the settings created by ant eclipse do not have any project-specific settings to disable it. This will add those project-specific settings. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5747) Eclipse settings - prevent automatic code reformatting on save
[ https://issues.apache.org/jira/browse/LUCENE-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14025481#comment-14025481 ] ASF subversion and git services commented on LUCENE-5747: - Commit 1601461 from [~elyograg] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1601461 ] LUCENE-5747: Prevent automatic code reformatting when saving in eclipse (merge trunk r1601446) Eclipse settings - prevent automatic code reformatting on save -- Key: LUCENE-5747 URL: https://issues.apache.org/jira/browse/LUCENE-5747 Project: Lucene - Core Issue Type: Bug Components: general/build Affects Versions: 4.8.1 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 4.9 Attachments: LUCENE-5747.patch, LUCENE-5747.patch If the user has Eclipse globally configured to automatically reformat code or reorganize imports on save, currently these actions will be performed, because the settings created by ant eclipse do not have any project-specific settings to disable it. This will add those project-specific settings. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5747) Eclipse settings - prevent automatic code reformatting on save
Shawn Heisey created LUCENE-5747: Summary: Eclipse settings - prevent automatic code reformatting on save Key: LUCENE-5747 URL: https://issues.apache.org/jira/browse/LUCENE-5747 Project: Lucene - Core Issue Type: Bug Components: general/build Affects Versions: 4.8.1 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 4.9 If the user has Eclipse globally configured to automatically reformat code or reorganize imports on save, currently these actions will be performed, because the settings created by ant eclipse do not have any project-specific settings to disable it. This will add those project-specific settings. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5747) Eclipse settings - prevent automatic code reformatting on save
[ https://issues.apache.org/jira/browse/LUCENE-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated LUCENE-5747: - Attachment: LUCENE-5747.patch Patch implementing the project-specific editor save actions, disabling all such actions. Eclipse settings - prevent automatic code reformatting on save -- Key: LUCENE-5747 URL: https://issues.apache.org/jira/browse/LUCENE-5747 Project: Lucene - Core Issue Type: Bug Components: general/build Affects Versions: 4.8.1 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 4.9 Attachments: LUCENE-5747.patch If the user has Eclipse globally configured to automatically reformat code or reorganize imports on save, currently these actions will be performed, because the settings created by ant eclipse do not have any project-specific settings to disable it. This will add those project-specific settings. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5747) Eclipse settings - prevent automatic code reformatting on save
[ https://issues.apache.org/jira/browse/LUCENE-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated LUCENE-5747: - Attachment: LUCENE-5747.patch Updated patch with CHANGES.txt. Eclipse settings - prevent automatic code reformatting on save -- Key: LUCENE-5747 URL: https://issues.apache.org/jira/browse/LUCENE-5747 Project: Lucene - Core Issue Type: Bug Components: general/build Affects Versions: 4.8.1 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 4.9 Attachments: LUCENE-5747.patch, LUCENE-5747.patch If the user has Eclipse globally configured to automatically reformat code or reorganize imports on save, currently these actions will be performed, because the settings created by ant eclipse do not have any project-specific settings to disable it. This will add those project-specific settings. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5747) Eclipse settings - prevent automatic code reformatting on save
[ https://issues.apache.org/jira/browse/LUCENE-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14021280#comment-14021280 ] Shawn Heisey commented on LUCENE-5747: -- I will commit this late tonight (in my timezone, UTC-6) if there are no objections. Eclipse settings - prevent automatic code reformatting on save -- Key: LUCENE-5747 URL: https://issues.apache.org/jira/browse/LUCENE-5747 Project: Lucene - Core Issue Type: Bug Components: general/build Affects Versions: 4.8.1 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 4.9 Attachments: LUCENE-5747.patch, LUCENE-5747.patch If the user has Eclipse globally configured to automatically reformat code or reorganize imports on save, currently these actions will be performed, because the settings created by ant eclipse do not have any project-specific settings to disable it. This will add those project-specific settings. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5747) Eclipse settings - prevent automatic code reformatting on save
[ https://issues.apache.org/jira/browse/LUCENE-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14021327#comment-14021327 ] Adrien Grand commented on LUCENE-5747: -- +1 Eclipse settings - prevent automatic code reformatting on save -- Key: LUCENE-5747 URL: https://issues.apache.org/jira/browse/LUCENE-5747 Project: Lucene - Core Issue Type: Bug Components: general/build Affects Versions: 4.8.1 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 4.9 Attachments: LUCENE-5747.patch, LUCENE-5747.patch If the user has Eclipse globally configured to automatically reformat code or reorganize imports on save, currently these actions will be performed, because the settings created by ant eclipse do not have any project-specific settings to disable it. This will add those project-specific settings. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5747) Eclipse settings - prevent automatic code reformatting on save
[ https://issues.apache.org/jira/browse/LUCENE-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14021531#comment-14021531 ] Robert Muir commented on LUCENE-5747: - +1 Eclipse settings - prevent automatic code reformatting on save -- Key: LUCENE-5747 URL: https://issues.apache.org/jira/browse/LUCENE-5747 Project: Lucene - Core Issue Type: Bug Components: general/build Affects Versions: 4.8.1 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 4.9 Attachments: LUCENE-5747.patch, LUCENE-5747.patch If the user has Eclipse globally configured to automatically reformat code or reorganize imports on save, currently these actions will be performed, because the settings created by ant eclipse do not have any project-specific settings to disable it. This will add those project-specific settings. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
