Re: font defects in scripts.varsegno and accordion.push
Am 24.10.2010 00:58, schrieb Carl Sorensen: [...] varsegno is now fixed, with commit bd4bb4efdb7e3a3e7ff23dbf35a33efb9b296bbc. Thanks a lot, Carl - I was just about to have a closer look at the definition of draw_bulb ... I owe you. Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part-combine: Add a way to override the part-combination decision by a ctx prop (issue1698054)
LGTM Carl http://codereview.appspot.com/1698054/diff/17001/ly/music-functions-init.ly File ly/music-functions-init.ly (right): http://codereview.appspot.com/1698054/diff/17001/ly/music-functions-init.ly#newcode602 ly/music-functions-init.ly:602: #(define (symbol-or-boolean? x) (or (symbol? x) (boolean? x))) add to scm/c++.scm, and add entry to scm/lily.scm http://codereview.appspot.com/1698054/diff/17001/scm/part-combiner.scm File scm/part-combiner.scm (right): http://codereview.appspot.com/1698054/diff/17001/scm/part-combiner.scm#newcode548 scm/part-combiner.scm:548: (analyse-forced-combine 0 #f) U.S. spelling -- analyze But I see that the standard in this file is analyse, so I'm not sure what the best way to proceed is. http://codereview.appspot.com/1698054/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly: option to only modify changed files. (issue2642041)
LGTM. This is a feature that has been needed. Thanks for working on it. Carl http://codereview.appspot.com/2642041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problematic commit 02fe038744e634b42f1a3377c4f0dc3d25e80344
On Sun, Oct 24, 2010 at 3:43 AM, Graham Percival gra...@percival-music.ca wrote: I would have liked to see this in codereview before it showed up in git master. Feel free to revert it. changes.tely: - why is \include still recommended? Because \include works with arabic.ly. pitches.itely: - if \include is still recommended, then why is \language discussed first? Because it's way simpler. - I see a @noindent, which is heavily discouraged by the doc policy. - I see @exmaples, which are also discouraged by the doc policy. Have you had a look at the current doc? http://lilypond.org/doc/v2.13/Documentation/notation/writing-pitches#note-names-in-other-languages I see talking through the code, which is heavily discouraged by the doc policy and IMO much worse than having a clean @example block. - does \language support scoping? If so, it would be nice to see that discussed. Nope. That's why it isn't discussed. (As Neil pointed out, scoping wouldn't be much of an interesting feature in this case.) - perhaps we should not consider arabic.ly as a language, but rather as an instrument (or music) style, like bagpipes.ly or gregorian.ly. If so, then this is the appropriate time to discuss it. So I suggested. But since I wouldn't make this choice on my own, in the meantime I updated the docs in a way that preserved the logic we used so far: not only is arabic.ly still regarded as a language, but the languages are still referred to with a .ly extension in the table (which wouldn't make any sense if we emphasized and recommended the \language command). I believe that deprecating the language.ly approach deserves more thoughts and discussions, and before we do that, this commit fills the gap. Cheers. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problematic commit 02fe038744e634b42f1a3377c4f0dc3d25e80344
On 24 October 2010 12:32, Valentin Villenave valen...@villenave.net wrote: On Sun, Oct 24, 2010 at 3:43 AM, Graham Percival Feel free to revert it. TBH, I'm sorely tempted to myself. There's a memory leak from `make-void-music', which suggests you haven't done a regression test check or run make doc. I don't think it's appropriate to gulp files and evaluate code for this. The pitch alists should be moved to a single file instead, so they're resident, leaving the existing language files as skeletons until they're removed. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix #888: Add ly:stencil-scale. (issue2275042)
Reviewers: Valentin Villenave, Patrick McCarty, Message: On 2010/10/04 10:36:47, Valentin Villenave wrote: Hi Neil, your patch looks awesome! Thanks. Wouldn't a number-pair be more consistent with existing markup commands such as translate-scaled? Yep, and it saves a hash too. :) Cheers, Neil Description: Fix #888: Add ly:stencil-scale. * lily/stencil-interpret.cc (interpret_stencil_expression): interpret new stencil command `scale-stencil', unscaling offset of body to compensate for change in output scale * lily/stencil-scheme.cc (ly_stencil_scale): export new function `ly:stencil-scale' * lily/stencil.cc, include/stencil.hh (scale): new method for scaling stencils * scm/define-markup-commands.scm (scale): new markup command * scm/define-stencil-commands.scm (ly:all-stencil-commands): add stencil commands for setting and resetting scale (`setscale', `resetscale') (ly:all-output-backend-commands): add `scale-stencil' command * scm/output-ps.scm, output-svg.scm (setscale, resetscale): implement stencil outputters for scaling Please review this at http://codereview.appspot.com/2275042/ Affected files: A input/regression/stencil-scale.ly M lily/include/stencil.hh M lily/stencil-interpret.cc M lily/stencil-scheme.cc M lily/stencil.cc M scm/define-markup-commands.scm M scm/define-stencil-commands.scm M scm/output-ps.scm M scm/output-svg.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix #888: Add ly:stencil-scale. (issue2275042)
On 2010/10/08 05:32:32, Patrick McCarty wrote: Looks great! Thanks. http://codereview.appspot.com/2275042/diff/2001/input/regression/stencil-scale.ly File input/regression/stencil-scale.ly (right): http://codereview.appspot.com/2275042/diff/2001/input/regression/stencil-scale.ly#newcode21 input/regression/stencil-scale.ly:21: (ly:stencil-scale (ly:text-interface::print grob) 2 1.6)) There is trailing whitespace on this line. Oops, standards are slipping. ;) http://codereview.appspot.com/2275042/diff/2001/lily/stencil-interpret.cc File lily/stencil-interpret.cc (right): http://codereview.appspot.com/2275042/diff/2001/lily/stencil-interpret.cc#newcode104 lily/stencil-interpret.cc:104: y_scale)); resetscale doesn't really need any formal parameters, since they are unused in the backends. Interestingly, resetrotation also has (unused) formal parameters, but resetcolor does not. :) Ah, I just obediently followed the example of `resetrotation', while thinking it slightly silly to send unused params. http://codereview.appspot.com/2275042/diff/2001/scm/define-markup-commands.scm File scm/define-markup-commands.scm (right): http://codereview.appspot.com/2275042/diff/2001/scm/define-markup-commands.scm#newcode3375 scm/define-markup-commands.scm:3375: (number? number? markup?) On 2010/10/04 10:36:47, Valentin Villenave wrote: Hi Neil, your patch looks awesome! Minor comment: Wouldn't a number-pair be more consistent with existing markup commands such as translate-scaled? I have a slight preference for a number-pair instead of two separate numbers. OK, I'll sort out a revised patch with all the suggested changes. Cheers, Neil http://codereview.appspot.com/2275042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problematic commit 02fe038744e634b42f1a3377c4f0dc3d25e80344
On Sun, Oct 24, 2010 at 1:40 PM, Neil Puttock n.putt...@gmail.com wrote: On 24 October 2010 12:32, Valentin Villenave valen...@villenave.net wrote: Feel free to revert it. TBH, I'm sorely tempted to myself. Then please do. There's a memory leak from `make-void-music', which suggests you haven't done a regression test check or run make doc. I have not, since the new function isn't used anywhere. I didn't suspect a stupid music-function hack that is not invoked anywhere could cause such things. ... Indeed, it can. I don't think it's appropriate to gulp files and evaluate code for this. I never said it was. The only point was to make the patch as unnoticeable as possible, in order to get it accepted. The pitch alists should be moved to a single file instead, so they're resident, leaving the existing language files as skeletons until they're removed. No kidding. And we could name this new single file, I don't know, lang-init.ly for example? (sigh) OK. Reverting. Better luck next time (if there is a next time, which I doubt)... Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problematic commit 02fe038744e634b42f1a3377c4f0dc3d25e80344
On 24 October 2010 13:17, Valentin Villenave valen...@villenave.net wrote: On Sun, Oct 24, 2010 at 1:40 PM, Neil Puttock n.putt...@gmail.com wrote: On 24 October 2010 12:32, Valentin Villenave valen...@villenave.net wrote: Feel free to revert it. TBH, I'm sorely tempted to myself. Then please do. There's a memory leak from `make-void-music', which suggests you haven't done a regression test check or run make doc. I have not, since the new function isn't used anywhere. I didn't suspect a stupid music-function hack that is not invoked anywhere could cause such things. Well, to be fair, it's not the music function that's the problem; rather, you've neglected to make `make-void-music' a thunk, which means it's evaluated immediately music-functions.scm is loaded. I don't think it's appropriate to gulp files and evaluate code for this. I never said it was. Sure, I understand that (your comments in the music function suggest as much). The only point was to make the patch as unnoticeable as possible, in order to get it accepted. Believe me, I understand your frustration at waiting for GLISS to start, but a change like this needs a more considered approach which I don't think we can afford at the moment. OK. Reverting. You can keep the `make-void-music' if you fix the bug (it just needs parentheses around the name). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now?
On Sun, Oct 24, 2010 at 5:22 AM, Graham Percival gra...@percival-music.ca wrote: We're about 10-20 hours of work away from having 0 Critical issues. On one hand, that sounds great; we're almost there! On the other hand, we've been in this state for the past month. I'm not seeing a lot of excitement and work towards 2.14. I'm afraid that the longer you wait, the less people will be excited. As I told you before, I think you should get 2.14 out now, or at least a release candidate. As for the rest of your TL;DR mail (didn't know this one, thanks! ;) I do have some comments, not all of which would be of the nice-and-fluffy kind. But it can wait. GLHF Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizations for pure-height approximations. (issue1817045)
On 2010/10/03 04:52:35, joeneeman wrote: I was just waiting to see if the memory problems are still there. I can't reproduce them (and it seems that Neil can't either any more) so I'm not sure what to do. I could just push it and then revert if people howl... I'm still not sure what was going on when I first tested this, but it's never come back. FWIW, I've had no problems with this patch; I've tested GUB builds for mingw, linux-x86 and linux-64 with the patch applied, and experienced no problems (just great improvements in compile times). I think we should go ahead and push. I'll pop a rebased diff on the tracker soon. Cheers, Neil http://codereview.appspot.com/1817045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problematic commit 02fe038744e634b42f1a3377c4f0dc3d25e80344
On Sun, Oct 24, 2010 at 2:35 PM, Neil Puttock n.putt...@gmail.com wrote: Well, to be fair, it's not the music function that's the problem; rather, you've neglected to make `make-void-music' a thunk, which means it's evaluated immediately music-functions.scm is loaded. I had initially defined it using parentheses, because it's the only way to add a doc-string. But I thought it would be cleaner to remove the parentheses. Uh, ironic. Believe me, I understand your frustration I don't think you do. (But that's another problem, I'm trying to keep it cool here.) but a change like this needs a more considered approach which I don't think we can afford at the moment. Sure. But you certainly do understand that my most pressing concern is the user-exposed syntax. For the past two years my main occupation has been to go and visit music schools, conservatories, teaching facilities, small non-profit associations here and there in France, trying to promote LilyPond and convince people that they can *actually* use it. My whole sales-pitch is based on Every musician can easily type note names: `do, re mi, fa sol etc.' Do not think of LilyPond as a programming language, think of it as the way musicians naturally express themselves!. Then comes the hardest part: Okay, now open your text editor, and type, er, `\include italiano.ly'. I can't tell you the look on their faces at this point. That being said, I understand that this may not be much of an issue for English-speaking users (and developers). You can keep the `make-void-music' if you fix the bug (it just needs parentheses around the name). I absolutely have no interest in keeping this function. In case you haven't noticed, that wasn't the point. Whilst I agree with you that my solution isn't (well, wasn't) elegant, it does have one advantage over yours: what you're suggesting is that *all* pitchname alists should be defined and loaded at launch time, no matter which one will actually be used. Granted, that's not much of an overhead, but still. In all fairness, I cannot say I'm entirely happy with removing it altogether. (Euphemism inside.) Well, thanks for the support. Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now?
On Sun, Oct 24, 2010 at 1:56 PM, Valentin Villenave valen...@villenave.net wrote: On Sun, Oct 24, 2010 at 5:22 AM, Graham Percival gra...@percival-music.ca wrote: We're about 10-20 hours of work away from having 0 Critical issues. On one hand, that sounds great; we're almost there! On the other hand, we've been in this state for the past month. I'm not seeing a lot of excitement and work towards 2.14. I'm afraid that the longer you wait, the less people will be excited. As I told you before, I think you should get 2.14 out now, or at least a release candidate. Who's these people? Patches for the 5 current Critical defects will almost certainly come from Carl, Joe, Patrick, Neil, Reinhold, or David. (apologies if I missed anybody -- if there's no other emergencies next week, I'll tackle 1336) I don't think that any of those persons would work any harder if I made a release candidate. Many of them are involved the academic Fall term (either as students or teachers), so we should expect them to be busy. If we _did_ have a 2.14.0 release now, what would happen? Most people would try running it on their old scores. Many would encounter one of the music running off the end of the page bugs. Those are serious. I mean, if I was trying to use a new music typesetting program, and it tried to print music outside the page, I'd switch to Sibelius pretty quickly. But wait, it gets worse! Suppose I decide to be helpful, so I send a bug report about the issue -- and get told yeah, we knew about that 3 months ago, but we made a new stable release anyway. I really don't think that we can ignore the spacing bugs, especially since improved vertical spacing is one of the main new features of 2.14. Granted, we could probably get away with ignoring the segfault issues -- they only happen in pretty specific circumstances. But this is really a cultural issue between windows+osx programs and unix programs. In unix-land, a segfault is a serious, serious problem. In windows+osx-land, a program crashing isn't particularly worth remarking on. Believe me, I've spent time looking at these issues, trying to find any excuse to downgrade the priority. Other than 1355 (for which we could argue it's impossible to ensure that scheme code doesn't die in bad ways, so that segfault isn't important), and 1288 (which will be fixed soon anyway), I can't in good conscience describe them as ok for a stable release. I mean, if they were *unknown* bugs that were only reported after 2.14.0 was out, I wouldn't lose any sleep over them. But since we know about them already, I don't think we can honestly claim that 2.13 is ready for stable productive use. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LyricText #'font-series = #'bold-narrow ?!
On 2010-10-20 15:34, Werner LEMBERG wrote: why does LyricText #'font-series default to #'bold-narrow? This looks like an oversight. The change is from 2004 where TeX has been still used as the output device. Ok. So #'medium should be correct now? It's hardly worth it (it's just one change in scm/define-grobs.scm), but here's a patch: http://codereview.appspot.com/2675042/. Would you check this? Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problematic commit 02fe038744e634b42f1a3377c4f0dc3d25e80344
On 10/24/10 6:17 AM, Valentin Villenave valen...@villenave.net wrote: Better luck next time (if there is a next time, which I doubt)... Don't give up now! The documentation stuff can be worked out -- if you had posted it on Rietveld, Graham would have given you feedback. And now you've got the right way to do it given to you: Create a file language-init.ily that creates an alist of the key name alists. Then have your \language function get the proper alist and assign it, just like you're doing now. And then adjust the LANG.ly files so that each of them just contains a call to \language LANG And then you'll have the new, safe-mode-compatible infrastructure all set up. And you can use it with your students. GLHF! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now?
On Sat, Oct 23, 2010 at 8:22 PM, Graham Percival gra...@percival-music.cawrote: We're about 10-20 hours of work away from having 0 Critical issues. On one hand, that sounds great; we're almost there! On the other hand, we've been in this state for the past month. I'm not seeing a lot of excitement and work towards 2.14. Ok, I get the hint. The most worrying part of 1240 (ie. comment #5) is fixed in git and I can finish closing it this evening. I can tweak the defaults so that 1285 looks nicer, but I'm not sure that it's really critical any more (basically, the height-estimation routines in 2.13 are more accurate and so the spacing routine is capable of doing tighter spacing than it was in 2.12). No ETA for 1252 yet, but I'll work on it... Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reorganize language files and add a new \language command. (issue2699041)
Reviewers: , Message: Greetings everybody. Third time's a charm: here's a new attempt to get the \language foobar syntax merged. Cons: this patch does move a lot of files around. Pros: this is a lot less hackish that my two previous attempts. Please have a look and feel free to comment; if this patch is approved, then I'll upload a second patch set to handle Documentation changes! Thanks to Neil and Carl for their comments and suggestions. Hopefully this time I got it right... :-) Description: Reorganize language files and add a new \language command. This commit adds a new \language command that may be used to select note names language in lieu of the more complicated \include foobar.ly syntax. All language files have been emptied and the pitchnames alists have been gathered in a new language-init.ly file. The old syntax is still supported; to avoid code duplication, language files just use the new \language command internally. arabic.ly isn't affected by this change and must still be manually included. This specificity will have to be taken into account when documenting the new syntax. Please review this at http://codereview.appspot.com/2699041/ Affected files: M Documentation/changes.tely M ly/arabic.ly M ly/catalan.ly M ly/declarations-init.ly M ly/deutsch.ly M ly/english.ly M ly/espanol.ly M ly/italiano.ly M ly/music-functions-init.ly M ly/nederlands.ly M ly/norsk.ly M ly/portugues.ly M ly/suomi.ly M ly/svenska.ly M ly/vlaams.ly ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganize language files and add a new \language command. (issue2699041)
I like this a lot -- it's looking like real lilypond code, instead of a hack. Thanks for doing this! Carl http://codereview.appspot.com/2699041/diff/1/Documentation/changes.tely File Documentation/changes.tely (right): http://codereview.appspot.com/2699041/diff/1/Documentation/changes.tely#newcode74 Documentation/changes.tely:74: is still supported, but might be deprecated in the future. Don't forget to add that the new syntax is compatible with safe mode (at least I think it is). http://codereview.appspot.com/2699041/diff/1/ly/catalan.ly File ly/catalan.ly (right): http://codereview.appspot.com/2699041/diff/1/ly/catalan.ly#newcode4 ly/catalan.ly:4: \version 2.12.0 Update the \version string in all of these files! http://codereview.appspot.com/2699041/diff/3001/ly/music-functions-init.ly File ly/music-functions-init.ly (right): http://codereview.appspot.com/2699041/diff/3001/ly/music-functions-init.ly#newcode365 ly/music-functions-init.ly:365: (_i Select note names language.) It would be more like standard lilypond to have language-init.ly do something like: language-pitch-names = `((nederlands . ((ceses . ,(ly:make-pitch -1 0 DOUBLE-FLAT)) (ceh . ,(ly:make-pitch -1 0 SEMI-FLAT)) ... )) (italiano . (() ... )) (english .... )) ) so that you have a single alist. Then, the argument to your music function would not be a string, but rather a symbol: \language #'italiano And the definition of language becomes: #(define-music-function (parser location lang) (symbol?) ... (let ((alist-def (assoc-get lang language-pitch-names '( ... (the rest of your stuff is the same) That way we don't have to mess with strings and string comparisons, we just use symbols. http://codereview.appspot.com/2699041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganize language files and add a new \language command. (issue2699041)
On Mon, Oct 25, 2010 at 3:57 AM, carl.d.soren...@gmail.com wrote: Update the \version string in all of these files! Well, I was reluctant to put a minor version number. Do you think putting 2.14.0 would be okay? Then, the argument to your music function would not be a string, but rather a symbol: \language #'italiano I did consider it. However, I have three reasons not to use symbols: - from a user perspective, typing italiano is slightly more straightforward than typing #'italiano. Remember, this function is intended for newcomers, who wouldn't even use music variables or \score blocks, let alone \overrides, boolean or symbols! - this also allows me to treat the given argument as case-insensitive. - last but not least, if we ever do implement the \language command as a parser token, taking a simple-string argument, then almost no changes will be needed (if anything, the foobar syntax will still work, but plain \language foobar, without quotes, will also be possible). That being said, I can indeed nest all the alists together, without necessarily using a (symbol?) argument: string-symbol is reliable enough A new patchset is on its way.. That way we don't have to mess with strings and string comparisons, we just use symbols. Well, I hope I made my point about using strings. I'm pretty hopeful that string-symbol does a reliable enough of a job to not qualify as messy :-) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganize language files and add a new \language command. (issue2699041)
On 10/24/10 8:17 PM, Valentin Villenave v.villen...@gmail.com wrote: On Mon, Oct 25, 2010 at 3:57 AM, carl.d.soren...@gmail.com wrote: Update the \version string in all of these files! Well, I was reluctant to put a minor version number. Do you think putting 2.14.0 would be okay? Then, the argument to your music function would not be a string, but rather a symbol: \language #'italiano I did consider it. However, I have three reasons not to use symbols: - from a user perspective, typing italiano is slightly more straightforward than typing #'italiano. Remember, this function is intended for newcomers, who wouldn't even use music variables or \score blocks, let alone \overrides, boolean or symbols! Well, although your intention is to make it easy for newcomers, that's not (IMO) a good reason to move forward on this. There are lots of other ways to make it easy on newcomers (e.g. a template file that starts with the language statement). For me, the real reason is to get a language selection method that can run in safe mode. - this also allows me to treat the given argument as case-insensitive. I think this is a reason *not* to use the case-insensitive implementation. LilyPond input *is* case sensitive (r1 is not the same as R1, c4 is not the same as C4). I think we should always be case-sensitive if we're ever case-sensitive. I would prefer to eliminate the case conversion part of the patch. I think that the best thing we can do to be easier is to be consistent. - last but not least, if we ever do implement the \language command as a parser token, taking a simple-string argument, then almost no changes will be needed (if anything, the foobar syntax will still work, but plain \language foobar, without quotes, will also be possible). This answer is much more compelling to me. \language italiano (like \clef treble) is very consistent. So you've convinced me that a string argument is OK. That being said, I can indeed nest all the alists together, without necessarily using a (symbol?) argument: string-symbol is reliable enough A new patchset is on its way.. Perfect! That way we don't have to mess with strings and string comparisons, we just use symbols. Well, I hope I made my point about using strings. I'm pretty hopeful that string-symbol does a reliable enough of a job to not qualify as messy :-) Yep, it's fine. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1240. (issue2065041)
Reviewers: carl.d.sorensen_gmail.com, Message: Thanks. In the end, I committed this mostly as-is, but a change I made while working on 1252 allowed me to do without the dummy Paper_columns. Description: Fix 1240. Include fixed spacings in the calculation of minimum spacings. Please review this at http://codereview.appspot.com/2065041/ Affected files: M lily/align-interface.cc M lily/grob.cc M lily/include/align-interface.hh M lily/include/grob.hh M lily/include/page-layout-problem.hh M lily/include/system.hh M lily/page-layout-problem.cc M lily/system.cc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganize language files and add a new \language command. (issue2699041)
http://codereview.appspot.com/2699041/diff/9001/input/regression/note-names.ly File input/regression/note-names.ly (right): http://codereview.appspot.com/2699041/diff/9001/input/regression/note-names.ly#newcode8 input/regression/note-names.ly:8: \version 2.13.37 I prefer having \version statements at the top of regression tests, but it's up to you. http://codereview.appspot.com/2699041/diff/9001/ly/catalan.ly File ly/catalan.ly (right): http://codereview.appspot.com/2699041/diff/9001/ly/catalan.ly#newcode2 ly/catalan.ly:2: (see language-init.ly) Even though you are making these legacy files, I would not remove copyright information from any of them. Jan made a big effort adding all of these copyright statements to comply closer with GNU standards... http://codereview.appspot.com/2699041/diff/9001/ly/language-init.ly File ly/language-init.ly (right): http://codereview.appspot.com/2699041/diff/9001/ly/language-init.ly#newcode23 ly/language-init.ly:23: ; Language: Nederlands ; Scheme code comments traditionally use two semicolons, that is ;; Language: etc. http://codereview.appspot.com/2699041/diff/9001/ly/language-init.ly#newcode25 ly/language-init.ly:25: ; Copyright (C) 1996--2010 Han-Wen Nienhuys han...@xs4all.nl IMO, the code starts to look cluttered seeing all of these copyright statements spread throughout the file. I would put them all in the file header. http://codereview.appspot.com/2699041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganize language files and add a new \language command. (issue2699041)
\language italiano (like \clef treble) is very consistent. So you've convinced me that a string argument is OK. Mhmm, in the documentation, please use \language italiano instead. Even newcomers must get used to it... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LyricText #'font-series = #'bold-narrow ?!
This looks like an oversight. The change is from 2004 where TeX has been still used as the output device. Ok. So #'medium should be correct now? Yes. Patch applied, thanks. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix #888: Add ly:stencil-scale. (issue2275042)
LGTM. Thanks, Patrick http://codereview.appspot.com/2275042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
