Re: GOP-PROP 3 - C++ formatting (probable decision)

Graham: ... > ** Eliminate tabs > > I'm going to make the bold step of assuming that we will eliminate > tabs in all C++ files. ... That implies that tabs in strings should be replaced with \t, is that what you want? Regards, /Karl Hammar

Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)

Carl Sorensen writes: > If we want to change the indentation, can't we do it with > > long_variable_name = (first_term >+ second_term); > > and have Emacs indent it this way? We could; python requires this anyway. I still prefer option 3 below: have astyle support 2 space

Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)

On 7/4/11 11:32 PM, "Jan Nieuwenhuizen" wrote: > > >> Also, I tried to make the output of the modified fixcc+asytle pass >> unchanged through emacs, but the very many cases of line-broken >> asssignments will be different. > > That's a problem. > >> long_variable_name = first_term >> +

Re: Fix issue 75: Allow multiple concurrent slurs (issue4643067)

LGTM, with one comment. I do wonder if David is right, and we should be using spanner_id instead of slur_id. Carl http://codereview.appspot.com/4643067/diff/3001/lily/slur-engraver.cc File lily/slur-engraver.cc (right): http://codereview.appspot.com/4643067/diff/3001/lily/slur-engraver.cc#new

Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)

Graham Percival writes: > Ok, so you do not object us adopting fixcc-with-astyle as the > official formatter for C++ code? It seems that this is a huge step forward; just don't change the definition to `whatever astyle can currently handle'; rather than: fixcc is okay and we're working with the a

Re: Fix issues 1259 and 1433 (\breakDynamicSpan and a spanner's style=#'none over a line break) (issue4630070)

LGTM, but I haven't explored the strange behavior you've identified. Carl http://codereview.appspot.com/4630070/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)

> Also, I tried to make the output of the modified fixcc+asytle pass > unchanged through emacs, but the very many cases of line-broken > asssignments will be different. That's a problem. > long_variable_name = first_term > + second_term; // emacs This is correct. > Emacs users will forge

Re: Small pitch bends correct and tested. (issue4654063)

LGTM, with Neil's comments taken Carl http://codereview.appspot.com/4654063/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Flag functions instead of defining glyphs directly (issue4625067)

lgtm I can see how this will work well for defining a whole set. Carl http://codereview.appspot.com/4625067/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: New breve rest with ledger lines (issue4650052)

LGTM Carl http://codereview.appspot.com/4650052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Adds glissando stems to Lilypond. (issue4661061)

Looking at the details of the code, it seems fine. But I tend to agree with Han-Wen's concerns. I'm wondering if it's possible to avoid code dup by making a base_stem_engraver of which glissando_stem_engraver and stem_engraver would be children. I probably don't have the right terminology for t

Re: Fixes multiple line glissandos the right way. (issue4631086)

LGTM Carl http://codereview.appspot.com/4631086/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add display method for \tweak (fixes issue 1733) (issue4645077)

LGTM Carl http://codereview.appspot.com/4645077/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Release candidate for 2.14.2

On 7/4/11 7:26 PM, "Harmath Dénes" wrote: > 9780d79af0855706354029509cbb11464a63d901 is intended to be backported to > stable, 71cea6af77bf3d639dcfd8ad09fd235aab22c5f7 is not. > backported Thanks, Carl ___ lilypond-devel mailing list lilypond-devel

Re: Release candidate for 2.14.2

On 7/4/11 7:23 PM, "Francisco Vila" wrote: > 2011/7/4 Carl Sorensen : >> As far as I can see, all bugfixes from the 2.15 branch are now backported to >> stable/2.14 >> >> I plan to ask Graham to release a new version on Saturday, July 9. >> >> There have been only minor documentation changes si

Re: Release candidate for 2.14.2

9780d79af0855706354029509cbb11464a63d901 is intended to be backported to stable, 71cea6af77bf3d639dcfd8ad09fd235aab22c5f7 is not. On 2011.07.05., at 3:23, Francisco Vila wrote: > 2011/7/4 Carl Sorensen : >> As far as I can see, all bugfixes from the 2.15 branch are now backported to >> stable/2.

Re: Release candidate for 2.14.2

2011/7/4 Carl Sorensen : > As far as I can see, all bugfixes from the 2.15 branch are now backported to > stable/2.14 > > I plan to ask Graham to release a new version on Saturday, July 9. > > There have been only minor documentation changes since 2.14.1, IIUC, but I > would invite the translators

Re: an example of minimal example (issue4636082)

Hello, my comments inline. James http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi File Documentation/web/community.itexi (right): http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode283 Documentation/web/community.itexi:28

Re: Fix issue 75: Allow multiple concurrent slurs (issue4643067)

On Di.,  5. Jul. 2011 00:30:52 CEST, pkx1...@gmail.com wrote: > On 2011/07/04 12:17:46, Reinhold wrote: > > On 2011/07/04 00:18:07, J_lowe wrote: > > > Hello, I get an error when I try to make: > > > That's fixed now. > Make succeeds, and reg tests look ok, but there is one note in one of > the

Re: an example of minimal example (issue4636082)

On Mon, Jul 04, 2011 at 11:46:30PM +0200, Janek Warchoł wrote: > 2011/7/4 : > > On 2011/07/04 21:01:44, Janek Warchol wrote: > >> Umm.. is it right now? > > > > why the mao are you asking me?  Cut&paste this and tell me yourself: > >  cd build/ > >  make website > > > > It either compiles, or it d

Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)

On 2011/07/04 21:22:58, Neil Puttock wrote: On 4 July 2011 21:57, wrote: > We already have the unused ligature-interface.  What if I just added > ligature-interface to NoteHead? Sounds fine to me. OK, so I've added ligature-interface to NoteHead, and

Re: Fix issue 75: Allow multiple concurrent slurs (issue4643067)

On 2011/07/04 12:17:46, Reinhold wrote: On 2011/07/04 00:18:07, J_lowe wrote: > Hello, I get an error when I try to make: That's fixed now. Make succeeds, and reg tests look ok, but there is one note in one of the .ly files that the reg test threw up that may or may not be significant. --sni

Re: an example of minimal example (issue4636082)

2011/7/4 : > On 2011/07/04 21:01:44, Janek Warchol wrote: >> Umm.. is it right now? > > why the mao are you asking me?  Cut&paste this and tell me yourself: >  cd build/ >  make website > > It either compiles, or it doesn't. Ooops, sorry... I didn't know that it's possible to compile website sepa

Re: Fixes multiple line glissandos the right way. (issue4631086)

LGTM apart from some indentation infelicities (space before tab in indent). http://codereview.appspot.com/4631086/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

GOP-PROP 3 - C++ formatting (probable decision)

http://lilypond.org/~graham/gop/gop_3.html ** Proposal summary Speaking academically, C++ code style is a "solved problem". Let’s pick one of the existing solutions, and let a computer deal with this. Humans should not waste their time, energy, and creativity manually adding tabs or spaces to sou

Re: an example of minimal example (issue4636082)

On 2011/07/04 21:01:44, Janek Warchol wrote: 2011/7/4 : > this won't compile; it would have to be @example instead, and that will require > @{ @} escapes. Umm.. is it right now? why the mao are you asking me? Cut&paste this and tell me yourself: cd build/ make website It either comp

Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)

On 4 July 2011 21:57, wrote: > The original way you suggested was to have two internal_has_interface () > calls; this one only adds one. But for the invalid heads, all three calls would be made (and of course, for a NoteHead itself only the first interface check will ever happen, so the other c

tuplet number on cross-staff kneed-beam

Hello, all -- First of all, I hope that I'm asking this question on the appropriate list! I'm trying to simplify the workaround relating to tuplet-number position on kneed beams http://lsr.dsi.unimi.it/LSR/Snippet?id=646 and I'm running into an unexpected problem. My reasoning is that, since the

Re: an example of minimal example (issue4636082)

New patch set uploaded. 2011/7/4 : I'm glad that you're working on it!  I'm just warning you that there will be many nitpicks. No problem. If they aren't about code style, i can handle them :) http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi File Documentation

Re: Separate flags into their own sub-font. (issue4654084)

I've almost forgotten: i checked that Carl's patch set passes regtests. http://codereview.appspot.com/4654084/diff/42/mf/feta-scripts.mf File mf/feta-scripts.mf (right): http://codereview.appspot.com/4654084/diff/42/mf/feta-scripts.mf#newcode1450 mf/feta-scripts.mf:1450: begingroup; On 2011/07/

Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)

On 2011/07/04 20:30:10, Neil Puttock wrote: On 2011/07/04 01:54:40, Carl wrote: > Instead of filtering out bad events, I chose to filter in only events with > ligature interfaces. That's a lot of internal_has_interface () calls. :) I wondered about that. But I think the first one that is

Re: Release candidate for 2.14.2

On 7/4/11 2:30 PM, "Graham Percival" wrote: > On Mon, Jul 04, 2011 at 01:57:54PM -0600, Carl Sorensen wrote: >> I plan to ask Graham to release a new version on Saturday, July 9. > > May or may not happen. That's the last day of the conference; > I'll probably be in the Venice airport for 2-3 h

Re: Separate flags into their own sub-font. (issue4654084)

Thanks for the review, Janek. http://codereview.appspot.com/4654084/diff/42/mf/feta-flags-generic.mf File mf/feta-flags-generic.mf (right): http://codereview.appspot.com/4654084/diff/42/mf/feta-flags-generic.mf#newcode4 mf/feta-flags-generic.mf:4: % Copyright (C) 1997--2011 Han-Wen Nienhuys On

Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)

On Mon, Jul 04, 2011 at 09:58:14PM +0200, Jan Nieuwenhuizen wrote: > Carl Sorensen writes: > > > I've tried Emacs, and I can't see the benefits justifying fighting through > > the learning curve. It's not comfortable for me; I have 30+ years of > > experience with vi(m), so it's hardwired in my b

Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)

On 2011/07/04 09:28:26, janneke_gnu.org wrote: The GNU standards are implemented by Emacs, Well, it looks like the problems with fixcc.py were caused by regexps, not emacs. Also, I tried to make the output of the modified fixcc+asytle pass unchanged through emacs, but the very many cases of l

Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)

On 4 July 2011 21:33, wrote: > Where is set_property defined? lily/include/lily-guile-macros.hh The actual type-checking occurs in Context::internal_set_property (). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.

Re: an example of minimal example (issue4636082)

On 2011/07/04 20:02:59, Carl wrote: I like this, but I think it should have a little bit more information. I don't think that the changes in the comments affect whether it is minimal or not -- perhaps the comments should be the same in both cases. Imo it's more readable when the comment is

Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)

On 2011/07/04 13:14:55, Neil Puttock wrote: Context_def::add_context_mod () is where the assignment takes place (and you can see from set_property () how the type-checking is done). Where is set_property defined? cheers, Janek http://codereview.appspot.com/4650070/ __

Re: Release candidate for 2.14.2

On Mon, Jul 04, 2011 at 01:57:54PM -0600, Carl Sorensen wrote: > I plan to ask Graham to release a new version on Saturday, July 9. May or may not happen. That's the last day of the conference; I'll probably be in the Venice airport for 2-3 hours, and then London Heathrow terminal 5 for 14 hours.

Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)

On 2011/07/04 01:54:40, Carl wrote: Instead of filtering out bad events, I chose to filter in only events with ligature interfaces. That's a lot of internal_has_interface () calls. :) You might as well create a new interface just for NoteHead (e.g., ligature-head-interface). Cheers, Neil h

Re: an example of minimal example (issue4636082)

We need to be careful about adding stuff to the webpage; perfection is when there's nothing left to remove, not when there's nothing left to add. I'm glad that you're working on it! I'm just warning you that there will be many nitpicks. http://codereview.appspot.com/4636082/diff/3/Documentatio

Re: Separate flags into their own sub-font. (issue4654084)

LGTM! Thank you, Carl! http://codereview.appspot.com/4654084/diff/42/mf/feta-flags-generic.mf File mf/feta-flags-generic.mf (right): http://codereview.appspot.com/4654084/diff/42/mf/feta-flags-generic.mf#newcode4 mf/feta-flags-generic.mf:4: % Copyright (C) 1997--2011 Han-Wen Nienhuys Shouldn'

Re: modifying default behaviour of tremolo slashes (issue4636081)

Hi Janek, I'm afraid I don't like this at all. While the authorities may be in agreement that the slashes should be sloped, all the scores I've looked at follow the same style as LilyPond (which I think reflects a more traditional hand-engraved style). It would be preferable to allow users to c

Re: an example of minimal example (issue4636082)

I like this, but I think it should have a little bit more information. I don't think that the changes in the comments affect whether it is minimal or not -- perhaps the comments should be the same in both cases. What we wanted to get rid of is any unnecessary LilyPond input. In this case that

Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)

Carl Sorensen writes: > I've tried Emacs, and I can't see the benefits justifying fighting through > the learning curve. It's not comfortable for me; I have 30+ years of > experience with vi(m), so it's hardwired in my bones. Something went wrong here; it's awesome if we can manage not to depend

Release candidate for 2.14.2

As far as I can see, all bugfixes from the 2.15 branch are now backported to stable/2.14 I plan to ask Graham to release a new version on Saturday, July 9. There have been only minor documentation changes since 2.14.1, IIUC, but I would invite the translators to check to see if there is any work

an example of minimal example (issue4636082)

Reviewers: Graham Percival, james.lowe_datacore.com, Message: In response to http://lists.gnu.org/archive/html/lilypond-user/2011-07/msg00060.html Description: an example of minimal example for some people it's not clear enough how tiny a tiny example should be. So i used a recently discussed e

Re: modifying default behaviour of tremolo slashes (issue4636081)

Looks mostly good to me. Thanks, Carl http://codereview.appspot.com/4636081/diff/1/lily/stem-tremolo.cc File lily/stem-tremolo.cc (right): http://codereview.appspot.com/4636081/diff/1/lily/stem-tremolo.cc#newcode42 lily/stem-tremolo.cc:42: that it's not proper notation. We shouldn't keep the

modifying default behaviour of tremolo slashes (issue4636081)

Reviewers: xratamacue_hotmail.com, reinhold_kainhofer.com, Message: Passes regtests. Description: modifying default behaviour of tremolo slashes It turned out that tremolo slashes should have quite constant slope (definately not depending on beam slope), so i change that. I also changed slash s

Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)

On Mon, 04 Jul 2011 09:32:21 -0700, Trevor Daniels wrote: Jan Nieuwenhuizen wrote Monday, July 04, 2011 10:28 AM It seems to me that someone is spending a lot of effort `just' to accommodate people who haven't found how awesome Emacs is to edit code and thus introduce layout problems. Sure

Re: does anybody care about LSR?

2011/7/3 Reinhold Kainhofer : > Am Sonntag, 3. Juli 2011, 14:58:50 schrieb Jan Warchoł: >> 2011/7/3 Francisco Vila : >> > A pity it goes down sooo frequently, I ignore if it's hardware or >> > configuration to blame. >> >> I hope we will resolve this when we discuss "Subdomains of >> *.lilypond.org

Re: compiling documentation

On Mon, Jul 4, 2011 at 7:55 AM, Jonathan Kulp wrote: >> >> However ./autogen.sh and/or ./configure should report any missing/old/wrong >> dependencies. So do you get anything back from them (you will probably get >> something about a 'recommended' Fontforge version as I do - the lilydev >> vers

Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)

On 7/4/11 3:28 AM, "Jan Nieuwenhuizen" wrote: > Trevor Daniels writes: > >> I agree. This is a big improvement, and would >> give us control over the layout style ourselves >> (rather than "what emacs does"). > > While the work being done here is possibly a good thing, let me remind > you once

Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)

Jan Nieuwenhuizen wrote Monday, July 04, 2011 10:28 AM Trevor Daniels writes: I agree. This is a big improvement, and would give us control over the layout style ourselves (rather than "what emacs does"). While the work being done here is possibly a good thing, let me remind you once mor

Re: Adds redirect-lilypond-output option to lilypond-book (issue4664060)

- Original Message - From: To: ; Cc: ; Sent: Sunday, July 03, 2011 7:25 PM Subject: Re: Adds redirect-lilypond-output option to lilypond-book (issue4664060) LGTM, and fantastic website with testing info. I have three requests for future work, but this patch should get pushed fir

Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)

On Jul 4, 2011, at 5:04 PM, Reinhold Kainhofer wrote: > Am Montag, 4. Juli 2011, 16:39:08 schrieb Neil Puttock: >> On 4 July 2011 15:31, Carl Sorensen wrote: >>> Plus, I don't think it's really a redundant check; I think it's a real >>> check. Absent such a check, we're trusting on the *-init.l

Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)

Am Montag, 4. Juli 2011, 16:39:08 schrieb Neil Puttock: > On 4 July 2011 15:31, Carl Sorensen wrote: > > Plus, I don't think it's really a redundant check; I think it's a real > > check. Absent such a check, we're trusting on the *-init.ly files being > > correct, which admits a potential progra

Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)

On 4 July 2011 15:31, Carl Sorensen wrote: > Would a redundant check of settings from default context definitions be a > problem?  I can't imagine that such a check would take 1% of the processing > time. I don't know, though I agree is unlikely to be a significant overhead. > Plus, I don't thin

Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)

On 7/4/11 7:14 AM, "Neil Puttock" wrote: > On 4 July 2011 13:53, m...@apollinemike.com wrote: > >> I didn't realize this was the real issue :) >> Any tips as to how one would go about fixing this?  Anything that happens >> before engravers kick in (dispatchers, parsers, etc.) remains a mystery

Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)

On 4 July 2011 13:53, m...@apollinemike.com wrote: > I didn't realize this was the real issue :) > Any tips as to how one would go about fixing this?  Anything that happens > before engravers kick in (dispatchers, parsers, etc.) remains a mystery to > me... Context_def::add_context_mod () is w

Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)

On Jul 4, 2011, at 2:47 PM, n.putt...@gmail.com wrote: > On 2011/07/04 12:38:06, MikeSol wrote: >> Fixes issue 1734. > > On 2011/07/04 12:38:06, MikeSol wrote: >> Fixes issue 1734. > > I think this covers up the real problem: context settings in a \layout > block have no type check. I didn't re

Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)

On 2011/07/04 12:38:06, MikeSol wrote: Fixes issue 1734. On 2011/07/04 12:38:06, MikeSol wrote: Fixes issue 1734. I think this covers up the real problem: context settings in a \layout block have no type check. Your addition simply duplicates Guile's error message for fingeringOrientations

Re: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)

On 11-07-04 03:54 AM, Graham Percival wrote: On Mon, Jul 04, 2011 at 08:14:45AM +0100, Graham Percival wrote: Remarks from the CG: Patch review tool: Reitveld is inconvenient in some respects: it requires a google account, and there’s no way to see all patches relating to lilypond. Shou

Re: compiling documentation

On Mon, Jul 4, 2011 at 4:58 AM, James Lowe wrote: > )I'm running Linux Mint Debian Edition, which is based on Debian Testing > )branch. Not sure what consequences that might have for this situation. I > )just run "apt-get build-dep lilypond" when setting up build env. I also > )install "gnome-comm

Re: Fix issue 75: Allow multiple concurrent slurs (issue4643067)

reinhold.kainho...@gmail.com writes: > Description: > Fix issue 75: Allow multiple concurrent slurs > > Rewrite the Slur_engraver and the Phrasing_slur_engraver to support > multiple concurrent slurs. The default lilypond syntax using parentheses > still supports only one slur at a time, but by ad

Adds a warning for non-list fingeringOrientations settings. (issue4650070)

Reviewers: , Message: Fixes issue 1734. Description: Adds a warning for non-list fingeringOrientations settings. Please review this at http://codereview.appspot.com/4650070/ Affected files: M lily/new-fingering-engraver.cc Index: lily/new-fingering-engraver.cc diff --git a/lily/new-fingeri

Re: Fix issue 75: Allow multiple concurrent slurs (issue4643067)

Reviewers: J_lowe, Message: On 2011/07/04 00:18:07, J_lowe wrote: Hello, I get an error when I try to make: That's fixed now. Cheers, Reinhold Description: Fix issue 75: Allow multiple concurrent slurs Rewrite the Slur_engraver and the Phrasing_slur_engraver to support multiple concurrent

Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)

Am Montag 04 Juli 2011, 11:28:19 schrieb Jan Nieuwenhuizen: > The GNU standards are implemented by Emacs, and if it makes an error, > then that's a serious bug that should be reported (to emacs). It seems > to me that someone is spending a lot of effort `just' to accomodate > people who haven't fo

RE: compiling documentation

Hello, )-Original Message- )From: lilypond-devel-bounces+james.lowe=datacore@gnu.org )[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On )Behalf Of Jonathan Kulp )Sent: 03 July 2011 16:35 )To: Graham Percival )Cc: lilypond-devel@gnu.org )Subject: Re: compiling documenta

Re: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)

On Mon, Jul 04, 2011 at 08:14:45AM +0100, Graham Percival wrote: > Remarks from the CG: > Patch review tool: Reitveld is inconvenient in some respects: it > requires a google account, and there’s no way to see all patches > relating to lilypond. Should we switch to something like > gerritt?

Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)

On Mon, Jul 04, 2011 at 11:28:19AM +0200, Jan Nieuwenhuizen wrote: > While the work being done here is possibly a good thing, let me remind > you once more that we are a GNU project and thus use the GNU standards > and thus we need no control over, we need not decide about, we need not > discuss la

Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)

Trevor Daniels writes: > I agree. This is a big improvement, and would > give us control over the layout style ourselves > (rather than "what emacs does"). While the work being done here is possibly a good thing, let me remind you once more that we are a GNU project and thus use the GNU standard

Fixes multiple line glissandos the right way. (issue4631086)

Reviewers: , Message: Passes regtests - should be good to go! Thanks to Neil & Han-Wen for the help. Cheers, MS Description: Fixes multiple line glissandos the right way. Please review this at http://codereview.appspot.com/4631086/ Affected files: M lily/line-spanner.cc M scm/define-grobs

Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)

wrote Monday, July 04, 2011 4:33 AM I really, really, wish Astyle had a fully gnu-compliant mode out of the box. I went through the regexp's again and think this is good to go. I agree. This is a big improvement, and would give us control over the layout style ourselves (rather than "what

Re: lilymidi: Add --pretty switch to lilymidi.py to display midi in human-readable form (with --dump) (issue4628078)

On Sun, Jul 03, 2011 at 03:45:09PM -0600, Colin Campbell wrote: > > Given the above, perhaps it would be wise to defer any formal Patch > Meister role until we have decided how (and if) patches are to be > recorded. I can carry on with keeping an eye on the tracker, but > anything else would requ