Re: Lilypond source code indenter and formatter

[David Kastrup]

Colin Hall <address@hidden> writes:

> On Thu, Jun 07, 2012 at 01:32:08PM +0200, David Kastrup wrote:
>> Colin Hall <address@hidden> writes:
>>
>> >> You don't have the choice to make indentation compromises while a
>> >> file is actively being worked on.  Reverts and merges often fail.
>> >
>> > Yes, that's a feature. One only gets to check in code that meets the
>> > agreed standard. Compromise the indentation on your own branch.
>> >> file is actively being worked on.  Reverts and merges often fail.
>> >
>> > Yes, that's a feature. One only gets to check in code that meets the
>> > agreed standard. Compromise the indentation on your own branch.
>
> So, do you accept this is a feature?

If you want to call failing reverts and merges a feature, nothing keeps
you from it.

>> The tool to consult about merge conflicts is git, and using git in a
>> colloborative setting was what the thread was supposed to be about.
>
> Yes, that's a good point. If I may quote you again:
>
>> > > It is not really helpful for diffs if you get completely different
>> > > indentation for a while file because of having to add a delimiter pair
>> > > somewhere.
>> >
>> > Please describe a chain of events leading to that scenario.
>>
>> { 50 lines }  =>  << { 50 lines } { mixture of s and dynamics } >>
>
> Let's see how that looks in git diff:
>
> $         
> $ git diff
> diff --git a/score.ly b/score.ly
> index 9000b2f..a12e07e 100644
> --- a/score.ly
> +++ b/score.ly
> @@ -1,10 +1,17 @@
>  \score
>  {
> -  {
> -    c c c c |
> -    c c c c |
> -    c c c c |
> -    c c c c |
> -    c c c c |
> -  }
> +  <<
> +    {
> +      c c c c |
> +      c c c c |
> +      c c c c |
> +      c c c c |
> +    }
> +    {
> +      s\p s s s |
> +      s s s s |
> +      s\mf s s s |
> +      s s s s |
> +    }
> +  >>
> }
> $ 
> $ 
>
> I think this is pretty clear and not the least unhelpful.

We are still talking about colloborative editing, right?  Where someone
else might have been working on the melody part, right?  With git not
detecting any common line between the two different changes and
consequently not doing _any_ merge resolution, right?

I don't think we are going to reach consensus on the meaning of words
and phrases like "feature" and "not the least unhelpful", so we might as
well stop here.

-- 
David Kastrup