shortened stems and flags

shortened stems and flags

This improves the way that stems in forced directions are shortened and adds loads of new flags to be used with these shortened stems.

[lemniskata.bernoulliego, 2011-02-06 13:08:10]

This is a bogus comment.
Am i doing this right?
Janek

[MikeSol, 2011-02-06 13:38:50]

Great work!
I can't really speak to the font stuff.  You can make your C++ code a lot
shorter by using arrays.  And I see that you've wiped a lot of the tabbing in
the original code.  You may want to start by copying a fresh version of the file
into your git repository and then copying and pasting the new code into that to
save you the headache of dealing w/ all of those tabs.

Other than that, arrays are your friend.
Everything else looks good!

http://codereview.appspot.com/4134041/diff/1/lily/stem.cc
File lily/stem.cc (right):

http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode92
lily/stem.cc:92: Staff_symbol_referencer::get_position (e[UP]));
Try to keep the same indentation from the previous file (here, there were 2
tabs).

http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode190
lily/stem.cc:190: while (flip (&d) != DOWN);
Ditto.

http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode231
lily/stem.cc:231: }
Ditto.

http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode246
lily/stem.cc:246: {
Ditto.  I'll stop "dittoing," but check out the side by side diff to rectify
this :)

http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode350
lily/stem.cc:350: Direction dir = get_grob_direction (me);
Try:
Real potential_lengths[] = {7,7,7,7,8.5,10,11.5};
length = potential_lengths[durlog-1];

http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode373
lily/stem.cc:373: }
Same approach as above - you can use an array here.

http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode388
lily/stem.cc:388: length -= shorten;
You can also use an array here.

Real potential_shortenings[] = {0.833,0.666,0.555,0.333,0.166};
shorten *= potential_shortenings[(int)(head_positions (me)[dir])];

http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode715
lily/stem.cc:715: }
Ditto - use arrays.

http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode728
lily/stem.cc:728: }
Same - arrays can be used here (see above for how to handle else if).

[lemniskata.bernoulliego, 2011-02-06 23:20:09]

2011/2/6  <mtsolo@gmail.com>:
> Great work!

Thank you!

> I can't really speak to the font stuff.

Why not? Every one has his own personal preferences.
And the font stuff is what matters the most for me :)
Of course some changes are very subtle. It's best to open pdfs called
"flag testing" side-by-side on a big resolution screen (i have 24",
1920x1080 screen), zoomed to 300-400%, but it can be done on smaller
displays too.
Here are the pdfs made with my commit: http://www.sendspace.com/file/j9dq5t
Here are pdfs made with 2.13.47 for comparison:
http://www.sendspace.com/file/ogl8rk
Here are the .ly files: http://www.sendspace.com/file/gjh6ng

> You can make your C++ code a
> lot shorter by using arrays.

I've made it shorter in some places by using grob properties, but i
was unable to upload that new patch. It should be available soon.

> And I see that you've wiped a lot of the
> tabbing in the original code.  You may want to start by copying a fresh
> version of the file into your git repository and then copying and
> pasting the new code into that to save you the headache of dealing w/
> all of those tabs.

Frankly, i really do not know what is happening here. Files before and
after the change look the same to me.
I'm using lilydev, but the default text editor wasn't to my taste, so
i edited the files outside lilydev, in Notepad++. I set Notepad++ to
write all tabs as spaces (if i remember correctly, our policy for the
code says that all indentation should be done with spaces?) and it
looked ok...

> Other than that, arrays are your friend.
> Everything else looks good!
>
> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc
> File lily/stem.cc (right):
>
> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode92
> lily/stem.cc:92: Staff_symbol_referencer::get_position (e[UP]));
> Try to keep the same indentation from the previous file (here, there
> were 2 tabs).
>
> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode190
> lily/stem.cc:190: while (flip (&d) != DOWN);
> Ditto.
>
> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode231
> lily/stem.cc:231: }
> Ditto.
>
> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode246
> lily/stem.cc:246: {
> Ditto.  I'll stop "dittoing," but check out the side by side diff to
> rectify this :)

As i've said, i fail to see how it was different :(
there is the same amount of whitespace, and when i copy a fragment of
the file to some external editor, it behaves all the same (like if all
indentation was done with spaces).
If it weren't for these tiny » in side-by-side diff, i wouldn't know
what you are talking about :(

> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode350
> lily/stem.cc:350: Direction dir = get_grob_direction (me);
> Try:
> Real potential_lengths[] = {7,7,7,7,8.5,10,11.5};
> length = potential_lengths[durlog-1];

This one i improved with grob properties.

> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode373
> lily/stem.cc:373: }
> Same approach as above - you can use an array here.
>
> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode388
> lily/stem.cc:388: length -= shorten;
> You can also use an array here.
>
> Real potential_shortenings[] = {0.833,0.666,0.555,0.333,0.166};
> shorten *= potential_shortenings[(int)(head_positions (me)[dir])];

It didn't work, i got stems with length 0 and general mess :(
i'll investigate tomorrow.

> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode715
> lily/stem.cc:715: }
> Ditto - use arrays.
>
> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode728
> lily/stem.cc:728: }
> Same - arrays can be used here (see above for how to handle else if).
>
> http://codereview.appspot.com/4134041/

Thanks for help!

[mike_apollinemike.com, 2011-02-06 23:47:19]

On Feb 6, 2011, at 6:19 PM, Jan Warchoł wrote:

> 2011/2/6  <mtsolo@gmail.com>:
>> Great work!
> 
> Thank you!
> 
>> I can't really speak to the font stuff.
> 
> Why not? Every one has his own personal preferences.
> And the font stuff is what matters the most for me :)
> Of course some changes are very subtle. It's best to open pdfs called
> "flag testing" side-by-side on a big resolution screen (i have 24",
> 1920x1080 screen), zoomed to 300-400%, but it can be done on smaller
> displays too.
> Here are the pdfs made with my commit: http://www.sendspace.com/file/j9dq5t
> Here are pdfs made with 2.13.47 for comparison:
> http://www.sendspace.com/file/ogl8rk
> Here are the .ly files: http://www.sendspace.com/file/gjh6ng
> 
>> You can make your C++ code a
>> lot shorter by using arrays.
> 
> I've made it shorter in some places by using grob properties, but i
> was unable to upload that new patch. It should be available soon.
> 
>> And I see that you've wiped a lot of the
>> tabbing in the original code.  You may want to start by copying a fresh
>> version of the file into your git repository and then copying and
>> pasting the new code into that to save you the headache of dealing w/
>> all of those tabs.
> 
> Frankly, i really do not know what is happening here. Files before and
> after the change look the same to me.
> I'm using lilydev, but the default text editor wasn't to my taste, so
> i edited the files outside lilydev, in Notepad++. I set Notepad++ to
> write all tabs as spaces (if i remember correctly, our policy for the
> code says that all indentation should be done with spaces?) and it
> looked ok...

I'm just passing along a comment I got about my code when I tried to wipe out
indentations.  I actually have no idea what best practice is, but as a general
rule, commits should be centered around one "theme."  A separate patch, titled
"eliminate indentations in the stem.cc", could take care of the indentation
problem if it is in fact a problem (that said, my coding style is so bad that I
should really not even be talking...).

> 
>> Other than that, arrays are your friend.
>> Everything else looks good!
>> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc
>> File lily/stem.cc (right):
>> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode92
>> lily/stem.cc:92: Staff_symbol_referencer::get_position (e[UP]));
>> Try to keep the same indentation from the previous file (here, there
>> were 2 tabs).
>> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode190
>> lily/stem.cc:190: while (flip (&d) != DOWN);
>> Ditto.
>> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode231
>> lily/stem.cc:231: }
>> Ditto.
>> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode246
>> lily/stem.cc:246: {
>> Ditto.  I'll stop "dittoing," but check out the side by side diff to
>> rectify this :)
> 
> As i've said, i fail to see how it was different :(
> there is the same amount of whitespace, and when i copy a fragment of
> the file to some external editor, it behaves all the same (like if all
> indentation was done with spaces).
> If it weren't for these tiny » in side-by-side diff, i wouldn't know
> what you are talking about :(
> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode350
>> lily/stem.cc:350: Direction dir = get_grob_direction (me);
>> Try:
>> Real potential_lengths[] = {7,7,7,7,8.5,10,11.5};
>> length = potential_lengths[durlog-1];
> 
> This one i improved with grob properties.
> 
OK!

>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode373
>> lily/stem.cc:373: }
>> Same approach as above - you can use an array here.
>> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode388
>> lily/stem.cc:388: length -= shorten;
>> You can also use an array here.
>> 
>> Real potential_shortenings[] = {0.833,0.666,0.555,0.333,0.166};
>> shorten *= potential_shortenings[(int)(head_positions (me)[dir])];
> 
> It didn't work, i got stems with length 0 and general mess :(
> i'll investigate tomorrow.

Hm...lemme know.  It should be doable w/ arrays somehow - if you don't crack it,
lemme know & I'll give it a more protracted glance.
> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode715
>> lily/stem.cc:715: }
>> Ditto - use arrays.
>> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode728
>> lily/stem.cc:728: }
>> Same - arrays can be used here (see above for how to handle else if).
>> 
>> http://codereview.appspot.com/4134041/
> 
> Thanks for help!

[Janek Warchol, 2011-02-07 13:07:40]

New patch set uploaded.

[lemniskata.bernoulliego, 2011-02-07 13:18:57]

2011/2/7 mike@apollinemike.com <mike@apollinemike.com>:
>
> On Feb 6, 2011, at 6:19 PM, Jan Warchoł wrote:
>
>> 2011/2/6  <mtsolo@gmail.com>:
>>> I can't really speak to the font stuff.
>>
>> Why not? Every one has his own personal preferences.
>> And the font stuff is what matters the most for me :)
>> Of course some changes are very subtle. It's best to open pdfs called
>> "flag testing" side-by-side on a big resolution screen (i have 24",
>> 1920x1080 screen), zoomed to 300-400%, but it can be done on smaller
>> displays too.
>> Here are the pdfs made with my commit: http://www.sendspace.com/file/j9dq5t
>> Here are pdfs made with 2.13.47 for comparison:
>> http://www.sendspace.com/file/ogl8rk
>> Here are the .ly files: http://www.sendspace.com/file/gjh6ng
>>
>>> And I see that you've wiped a lot of the
>>> tabbing in the original code.  You may want to start by copying a fresh
>>> version of the file into your git repository and then copying and
>>> pasting the new code into that to save you the headache of dealing w/
>>> all of those tabs.
>>
>> Frankly, i really do not know what is happening here. Files before and
>> after the change look the same to me.
>> I'm using lilydev, but the default text editor wasn't to my taste, so
>> i edited the files outside lilydev, in Notepad++. I set Notepad++ to
>> write all tabs as spaces (if i remember correctly, our policy for the
>> code says that all indentation should be done with spaces?) and it
>> looked ok...
>
> I'm just passing along a comment I got about my code when
> I tried to wipe out indentations.  I actually have no idea what
> best practice is, but as a general rule, commits should be centered
> around one "theme."  A separate patch, titled "eliminate indentations
> in the stem.cc", could take care of the indentation problem
> if it is in fact a problem (that said, my coding style is so bad
> that I should really not even be talking...).

I think i get rid of this problem in stem.cc (feta-flags.mf are
changed so much that i don't think fiddling with tabs is feasible).

>>> Real potential_shortenings[] = {0.833,0.666,0.555,0.333,0.166};
>>> shorten *= potential_shortenings[(int)(head_positions (me)[dir])];
>>
>> It didn't work, i got stems with length 0 and general mess :(
>> i'll investigate tomorrow.
>
> Hm...lemme know.  It should be doable w/ arrays somehow -
> if you don't crack it, lemme know & I'll give it a more protracted glance.

I've managed to do this, luckily :)

>>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode728
>>> lily/stem.cc:728: }
>>> Same - arrays can be used here (see above for how to handle else if).

Arrays for handling intervals of floating point numbers?
I don't see how this could be done.

thanks,
Janek

[mike_apollinemike.com, 2011-02-07 14:35:57]

On Feb 7, 2011, at 8:18 AM, Jan Warchoł wrote:

> 2011/2/7 mike@apollinemike.com <mike@apollinemike.com>:
>> 
>> On Feb 6, 2011, at 6:19 PM, Jan Warchoł wrote:
>> 
>>> 2011/2/6  <mtsolo@gmail.com>:
>>>> I can't really speak to the font stuff.
>>> 
>>> Why not? Every one has his own personal preferences.
>>> And the font stuff is what matters the most for me :)
>>> Of course some changes are very subtle. It's best to open pdfs called
>>> "flag testing" side-by-side on a big resolution screen (i have 24",
>>> 1920x1080 screen), zoomed to 300-400%, but it can be done on smaller
>>> displays too.
>>> Here are the pdfs made with my commit: http://www.sendspace.com/file/j9dq5t
>>> Here are pdfs made with 2.13.47 for comparison:
>>> http://www.sendspace.com/file/ogl8rk
>>> Here are the .ly files: http://www.sendspace.com/file/gjh6ng
>>> 
>>>> And I see that you've wiped a lot of the
>>>> tabbing in the original code.  You may want to start by copying a fresh
>>>> version of the file into your git repository and then copying and
>>>> pasting the new code into that to save you the headache of dealing w/
>>>> all of those tabs.
>>> 
>>> Frankly, i really do not know what is happening here. Files before and
>>> after the change look the same to me.
>>> I'm using lilydev, but the default text editor wasn't to my taste, so
>>> i edited the files outside lilydev, in Notepad++. I set Notepad++ to
>>> write all tabs as spaces (if i remember correctly, our policy for the
>>> code says that all indentation should be done with spaces?) and it
>>> looked ok...
>> 
>> I'm just passing along a comment I got about my code when
>> I tried to wipe out indentations.  I actually have no idea what
>> best practice is, but as a general rule, commits should be centered
>> around one "theme."  A separate patch, titled "eliminate indentations
>> in the stem.cc", could take care of the indentation problem
>> if it is in fact a problem (that said, my coding style is so bad
>> that I should really not even be talking...).
> 
> I think i get rid of this problem in stem.cc (feta-flags.mf are
> changed so much that i don't think fiddling with tabs is feasible).
> 
>>>> Real potential_shortenings[] = {0.833,0.666,0.555,0.333,0.166};
>>>> shorten *= potential_shortenings[(int)(head_positions (me)[dir])];
>>> 
>>> It didn't work, i got stems with length 0 and general mess :(
>>> i'll investigate tomorrow.
>> 
>> Hm...lemme know.  It should be doable w/ arrays somehow -
>> if you don't crack it, lemme know & I'll give it a more protracted glance.
> 
> I've managed to do this, luckily :)
> 
>>>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode728
>>>> lily/stem.cc:728: }
>>>> Same - arrays can be used here (see above for how to handle else if).
> 
> Arrays for handling intervals of floating point numbers?
> I don't see how this could be done.

Sorry - if it's intervals, then use a vector.
vector<Interval> foo;

Cheers,
MS

[lemniskata.bernoulliego, 2011-02-07 20:09:44]

2011/2/7 mike@apollinemike.com <mike@apollinemike.com>
>
> On Feb 7, 2011, at 8:18 AM, Jan Warchoł wrote:
>
> > 2011/2/7 mike@apollinemike.com <mike@apollinemike.com>:
> >>
> >> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode728
> >> lily/stem.cc:728: }
> >> Same - arrays can be used here (see above for how to handle else if).
> >
> > Arrays for handling intervals of floating point numbers?
> > I don't see how this could be done.
>
> Sorry - if it's intervals, then use a vector.
> vector<Interval> foo;
>
> Cheers,
> MS

Sorry, but i simply don't know how to use vectors :( I'm not skilled
enough with c++ yet :/
So if you know how to do this better, go ahead and fix it :)

thanks.
Janek

[mike_apollinemike.com, 2011-02-07 20:27:51]

On Feb 6, 2011, at 6:19 PM, Jan Warchoł wrote:

> 2011/2/6  <mtsolo@gmail.com>:
>> Great work!
> 
> Thank you!
> 
>> I can't really speak to the font stuff.
> 
> Why not? Every one has his own personal preferences.
> And the font stuff is what matters the most for me :)
> Of course some changes are very subtle. It's best to open pdfs called
> "flag testing" side-by-side on a big resolution screen (i have 24",
> 1920x1080 screen), zoomed to 300-400%, but it can be done on smaller
> displays too.
> Here are the pdfs made with my commit: http://www.sendspace.com/file/j9dq5t
> Here are pdfs made with 2.13.47 for comparison:
> http://www.sendspace.com/file/ogl8rk
> Here are the .ly files: http://www.sendspace.com/file/gjh6ng
> 
>> You can make your C++ code a
>> lot shorter by using arrays.
> 
> I've made it shorter in some places by using grob properties, but i
> was unable to upload that new patch. It should be available soon.
> 
>> And I see that you've wiped a lot of the
>> tabbing in the original code.  You may want to start by copying a fresh
>> version of the file into your git repository and then copying and
>> pasting the new code into that to save you the headache of dealing w/
>> all of those tabs.
> 
> Frankly, i really do not know what is happening here. Files before and
> after the change look the same to me.
> I'm using lilydev, but the default text editor wasn't to my taste, so
> i edited the files outside lilydev, in Notepad++. I set Notepad++ to
> write all tabs as spaces (if i remember correctly, our policy for the
> code says that all indentation should be done with spaces?) and it
> looked ok...
> 
>> Other than that, arrays are your friend.
>> Everything else looks good!
>> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc
>> File lily/stem.cc (right):
>> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode92
>> lily/stem.cc:92: Staff_symbol_referencer::get_position (e[UP]));
>> Try to keep the same indentation from the previous file (here, there
>> were 2 tabs).
>> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode190
>> lily/stem.cc:190: while (flip (&d) != DOWN);
>> Ditto.
>> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode231
>> lily/stem.cc:231: }
>> Ditto.
>> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode246
>> lily/stem.cc:246: {
>> Ditto.  I'll stop "dittoing," but check out the side by side diff to
>> rectify this :)
> 
> As i've said, i fail to see how it was different :(
> there is the same amount of whitespace, and when i copy a fragment of
> the file to some external editor, it behaves all the same (like if all
> indentation was done with spaces).
> If it weren't for these tiny » in side-by-side diff, i wouldn't know
> what you are talking about :(
> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode350
>> lily/stem.cc:350: Direction dir = get_grob_direction (me);
>> Try:
>> Real potential_lengths[] = {7,7,7,7,8.5,10,11.5};
>> length = potential_lengths[durlog-1];
> 
> This one i improved with grob properties.
> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode373
>> lily/stem.cc:373: }
>> Same approach as above - you can use an array here.
>> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode388
>> lily/stem.cc:388: length -= shorten;
>> You can also use an array here.
>> 
>> Real potential_shortenings[] = {0.833,0.666,0.555,0.333,0.166};
>> shorten *= potential_shortenings[(int)(head_positions (me)[dir])];
> 
> It didn't work, i got stems with length 0 and general mess :(
> i'll investigate tomorrow.
> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode715
>> lily/stem.cc:715: }
>> Ditto - use arrays.
>> 
>> http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode728
>> lily/stem.cc:728: }
>> Same - arrays can be used here (see above for how to handle else if).
>> 
>> http://codereview.appspot.com/4134041/
> 
> Thanks for help!

I just looked over your code again - the bit I'm talking about doesn't really
deal w/ intervals.

Try:

Real factors[] = {1,2,3,4,5,basic_length / incraments[log]};
string numbers[] = {"1","2","3","4","5","6"};
for (int i = 0; i < 6; i++)
  if (length > (basic_length - factors[i] * increments[log]))
  {
    font_char += numbers[i];
    break;
  }

I'm not sure if the above is 100% correct, but it or something like it should
get the job done!

Cheers,
MS

[Janek Warchol, 2011-02-07 23:12:25]

New patch set uploaded. 
The coding still needs some work, but i need some sleep now ;)
I have an idea how this could work better if i knew how to calculate something
div ((length - basic_length), increments [i])
(my problem is: div wants integers and these arguments are Reals).
Good night :)

http://codereview.appspot.com/4134041/diff/1/lily/stem.cc
File lily/stem.cc (right):

http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode728
lily/stem.cc:728: }
On 2011/02/06 13:38:50, MikeSol wrote:
> Same - arrays can be used here (see above for how to handle else if).

I don't see how this would be possible here.
We don't have integers here - we have floating point numbers...

[Graham Percival, 2011-02-08 02:09:02]

On Mon, Feb 07, 2011 at 06:37:29PM -0700, Carl Sorensen wrote:
> I tried to get that policy implemented, but was not successful.  Our current
> policy is "do whatever Emacs does".  Emacs can do it either way.

Correction: our current policy is to defer any policy decisions
until GOP.  Source formatting is definitely on the list; I've
spent about 10 hours experimenting with different programs+styles
and writing a report for us to consider at the appropriate time.

Cheers,
- Graham

[c_sorensen, 2011-02-08 02:10:10]

On 2/6/11 4:19 PM, "Jan Warchoł" <lemniskata.bernoulliego@gmail.com> wrote:

> 2011/2/6  <mtsolo@gmail.com>:
>> And I see that you've wiped a lot of the
>> tabbing in the original code.  You may want to start by copying a fresh
>> version of the file into your git repository and then copying and
>> pasting the new code into that to save you the headache of dealing w/
>> all of those tabs.
> 
> Frankly, i really do not know what is happening here. Files before and
> after the change look the same to me.
> I'm using lilydev, but the default text editor wasn't to my taste, so
> i edited the files outside lilydev, in Notepad++. I set Notepad++ to
> write all tabs as spaces (if i remember correctly, our policy for the
> code says that all indentation should be done with spaces?) and it
> looked ok...
> 

I tried to get that policy implemented, but was not successful.  Our current
policy is "do whatever Emacs does".  Emacs can do it either way.

The current recommendation is to follow the tab function in the current file
you're working on.  You will get change requests if you convert tabs to
spaces.

Thanks,

Carl

[Janek Warchol, 2011-02-08 22:25:33]

New patch set uploaded. 
Some more stylistic changes (hopefully for the better). There are 3 files in
this patch (although only stem.cc has changed), because i broke something and
had to delete my git repository, download it again and make changes again. Sorry
for that.

[marek1, 2011-02-24 12:04:32]

I have created new [PATCH] issue for this:
http://code.google.com/p/lilypond/issues/detail?id=1538

Marek

[Janek Warchol, 2011-02-24 15:18:43]

2011/2/24 Marek Klein <marek@gregoriana.sk>
>
> I have created new [PATCH] issue for this:
> http://code.google.com/p/lilypond/issues/detail?id=1538

Thanks for remembering! However, i'm afraid this issue is invalid. We
decided to divide this problem and the first part is discussed in
http://lists.gnu.org/archive/html/lilypond-devel/2011-02/msg00391.html
(i hope to upload a patch for that within a few hours).

cheers,
Janek