Re: [gwt-contrib] Re: Autoformat the api-checker tool source (issue1405801)

2011-04-06 Thread Eric Ayers
On Wed, Apr 6, 2011 at 12:11 AM, John Tamplin j...@google.com wrote:
 On Tue, Apr 5, 2011 at 8:35 PM, Ray Ryan rj...@google.com wrote:

 I don't think it's reasonable to ask Eric to tweak the auto formatter. We
 had that conversation already. He's just doing the same thing we have
 eclipse configured to do, right?

 Well, my understanding of the changes made to the formatter settings were:

 change the line width to 100
 let lines break at method invocations

 So, I am not sure why there are other changes which, IMHO, look really
 terrible.
 I thought the point of doing a few small blocks of code first was
 specifically to look for things like this that could be improved before we
 run it on everything.

 I can't look for real right now. Did you really find something aggregious?

 Well, I think it is pretty egregious, but YMMV.  In particular:

 the loss of the space in array initialization is a change for the worse that
 is one checkbox to fix

Fixed in another patch

 the assignment breaking is harder to fix, but I think the change is net for
 the worse because while the old settings allowed overly long lines,

The decision to turn that property on was due to the effects in:

  http://gwt-code-reviews.appspot.com/1368802

There were some internal discussions about this that culminated in the
gwt_format.xml change to turn on wrapping assignments at

http://gwt-code-reviews.appspot.com/1371802

 they
 seemed to occur only rarely in field initializers, and it is easy enough to
 work around that by initializing them in an initializer block instead of on
 the same line.  The current settings will screw up line breaks on
 assignments all over the place.
 The indentation issue I am talking about is like this.  Previous settings:
 logger.log(TreeLogger.log,
     A really long message 
     + variable);
 while the new settings do this:
 logger.log(TreeLogger.log,
     A really long message 
       + variable);
 however, I don't see where this is coming from.

From what I can tell, this isn't a setting (at least not anymore),
maybe the eclipse formatter in Eclipse 3.6 has changed.

 Regarding detecting the builder pattern, it could detect multiple
 invocations a.foo().bar().foo().baz() etc, but I agree the current formatter
 doesn't have that capability and the new setting is better than the old
 setting.




-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors


Re: [gwt-contrib] Re: Autoformat the api-checker tool source (issue1405801)

2011-04-05 Thread John Tamplin
On Tue, Apr 5, 2011 at 8:35 PM, Ray Ryan rj...@google.com wrote:

 I don't think it's reasonable to ask Eric to tweak the auto formatter. We
 had that conversation already. He's just doing the same thing we have
 eclipse configured to do, right?

Well, my understanding of the changes made to the formatter settings were:

   - change the line width to 100
   - let lines break at method invocations

So, I am not sure why there are other changes which, IMHO, look really
terrible.

I thought the point of doing a few small blocks of code first was
specifically to look for things like this that could be improved before we
run it on everything.

  I can't look for real right now. Did you really find something
 aggregious?

Well, I think it is pretty egregious, but YMMV.  In particular:

   - the loss of the space in array initialization is a change for the worse
   that is one checkbox to fix
   - the assignment breaking is harder to fix, but I think the change is net
   for the worse because while the old settings allowed overly long lines, they
   seemed to occur only rarely in field initializers, and it is easy enough to
   work around that by initializing them in an initializer block instead of on
   the same line.  The current settings will screw up line breaks on
   assignments all over the place.
   - The indentation issue I am talking about is like this.  Previous
   settings:
   logger.log(TreeLogger.log,
   A really long message 
   + variable);
   while the new settings do this:
   logger.log(TreeLogger.log,
   A really long message 
 + variable);
   however, I don't see where this is coming from.

Regarding detecting the builder pattern, it could detect multiple
invocations a.foo().bar().foo().baz() etc, but I agree the current formatter
doesn't have that capability and the new setting is better than the old
setting.

-- 
John A. Tamplin
Software Engineer (GWT), Google

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors