Re: [RFC+PATCHES] Refactoring `tests/defs.in'.

[Stefano Lattarini]

On Thursday 02 September 2010, Ralf Wildenhues wrote:
> Hi Stefano,
> 
> * Stefano Lattarini wrote on Wed, Sep 01, 2010 at 11:35:47PM CEST:
> > I think it's about time to start the refactoring of
> > `tests/defs.in' we spoke about many times in the past.
> > 
> > I'd like to do this in small steps, posting one or two patches at
> > the time and waiting to have them reviewed/approved before
> > posting the following ones (thus avoding a "diff-bomb" of a
> > patch series with twenty patches or more).
> 
> OK sounds good.
>
> [CUT]
>
> If it is problematic to share code between master and maint, then
> we should just go for master.  I don't expect branch-1.11 to see a
> lot more updates, a point release or two maybe.  Let's avoid doing
> double work.
Agreed; only for master then.
 
> I'm fine if you just name the branch refactor-defs or tests-init or
> so. The name prefix is not really needed with the big number of
> branches we have at the moment.  ;-)
OK, let's go with tests-init.

Do you have any particualr suggestion on how to create a new remote
branch the right way?  Is 'git push orig tests-init' enough?
 
> > In the meantime, I have prepared and attached a couple of (mostly
> > cosmetic) patches extracted from my old private branch.
> 
> 1/2 is ok, thanks.  I actually find that some of the extra spacing
> removed in 2/2 makes the code a bit more readable.
The removal of spaces near the subshells' parentheses was just for 
consistency (other subshells use no spaces, and I margninally prefer 
this); I can do it the other way around (consistently adding spaces)
if you prefer, or even drop this part of the patch if you object. 
However, I want to keep the part that converts tabs into spaces in 
indentations.
> I don't have a strong opinion on norming the spacing; another reason
> the code is
> not very consistent wrt. spacing around parentheses is that in some
> situations spaces are required, e.g., ((subsubshell)) is wrong, as
> would be {oops;}.  This is probably why it's inconsistent
> throughout the code.  I don't think that is a big problem though.
Definitely not a problem, just a minor "stylistic" annoyance -- which 
I'd like to fix nonetheless, if you don't object.

Regards,
  Stefano