lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOP-PROP 10: scheme indentation


From: Jan Nieuwenhuizen
Subject: Re: GOP-PROP 10: scheme indentation
Date: Thu, 22 Sep 2011 10:23:00 +0200
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (cygwin)

Graham Percival writes:

>> +1
>
> Automatic indentation *does* solve real problems.

My point exactly: use Emacs.

> Gee, I wonder why we haven't seen any more patches from that new
> contributor?
> </sarcasm>

This looks like a contributor who needs some guidance.  The first thing
I notice is

    benko.pal   
    aargh, that's not too readable.
    what I actually suggest is replacing lines 204-207 of

    204       if ((left_to_do_ - note_dur.get_length ()) > Rational (0))
    205         event->set_property("autosplit-end", ly_bool2scm (true));
    206       else
    207         event->set_property("autosplit-end", ly_bool2scm (false));

    by

       event->set_property ("autosplit-end",
         ly_bool2scm (left_to_do_ - note_dur.get_length () > 0));

which has nothing to do with indentation.  Yes, the space before the
parentheses is missing, but that is of an other order of importance
than the code duplication.

I very much doubt whether indentation is the issue here; it could very
well be the policy of taking patches, or how Rietveld enables or steers
that policy.

If I were a contributor, something like this

    Graham Percival     
    I've identified a few more questionable lines, although maybe you
    should wait for a lilypond C++ expert to look at them.

    lily/tie-engraver.cc:190:
    (assume
    this should be indented with:
    1 tab + 2 spaces

would really be putting me off.  It should suffice to say: please fix
indentation (there is enough other code to spot the errors) and possibly
say we use GNU style.  Luckily we can now say: run fixcc.

However, it seems that we lack a good policy on when to just apply a
patch from a new contributor, fix minor nits, apply it, and email them
the result: "Thanks for your patch, I have applied it with small
modifications/indentation nits, see below."

While you should possibly not be doing that more than 2 or 3 times, this
is a very efficient way of integrating patches and communicating what
kind of code we expect.

Also, it seems to me that the Rietveld interface triggers and
facilitates talk/discussion rather than code massaging.  It could well
be that that sending GIT patches [or git urls] over email, and
responding either with inline comments or with an
alternative/evolutionary GIT patch is much more efficient.

> The "GNU project" is completely irrelevant.  The GNU style
> explicitly states that "We don’t think of these recommendations as
> requirements"

How can you say that?  It is very relevant.  Not making something a
requirement transfers the responsibility of taking a sound choice to the
maintainers.  Of course, life is easier if maintainers follow
recommendations.  Long ago we chose to use the GNU style.  Isn't that
pretty clear?  We saw no good reason to deviate from other GNU projects
and it was an easy choice because we used Emacs.  The GNU project uses
and recommends Emacs as its editor and as long as everyone does, none of
this comes up.

>> Please find an indenter that does what Emacs does.  Most every .scm
>> is indented by Emacs now.
>
> I have no objection to having this script indent in the same way
> that emacs does.

Great!  I truly hope that all the time that this GNU project is spending
on enabling the use of other editors, rather than advocating the use of,
GNU Emacs will pay off.

Jan

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl



reply via email to

[Prev in Thread] Current Thread [Next in Thread]