buglet in ly:stencil_combine_at_edge

In file stencil-scheme.cc, the variable `minimum' in function ly_stencil_combine_at_edge is documented, but the corresponding code does nothing. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/l

redundant code in Multi_measure_rest::print function?

In multi-measure-rest.cc, the function Multi_measure_rest::print checks the property `measure-count', but it does nothing with it. Either something is missing, or this code is redundant. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.o

Re: Add scripts/auxiliar/guileindent.scm (issue 4896043)

Looks awesome; I'm going to make this the next GOP-PROP issue. It should just be a rubber-stamping affair, but that's the best kind of proposal to get through the systme. I'm thinking of a grand fix-scheme.py run on 2011 Sep 01. It won't mess up many patches, and in any case the C++ run went ama

Re: redundant code in Multi_measure_rest::print function?

Am Monday, 15. August 2011, 09:24:13 schrieb Werner LEMBERG: > In multi-measure-rest.cc, the function Multi_measure_rest::print > checks the property `measure-count', but it does nothing with it. > > Either something is missing, or this code is redundant. It was initially used in Multi_measure::b

Re: buglet in ly:stencil_combine_at_edge

Am Monday, 15. August 2011, 09:06:27 schrieb Werner LEMBERG: > In file stencil-scheme.cc, the variable `minimum' in function > ly_stencil_combine_at_edge is documented, but the corresponding code > does nothing. Removed by Han-Wen in 2007 with commit: 98166b94174b63666a14a6a62bc16cf1b4163bce "Rem

Re: redundant code in Multi_measure_rest::print function?

> Again, I think this is a left-over and can ba safely removed. Thanks for checking. > Will you remove both left-overs that you found? Done. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/li

Re: GOP-PROP 8: issue priorities (probable decision)

On Wed 10 Aug 2011, 22:04 Colin Campbell wrote: > On 11-08-10 10:46 AM, Graham Percival wrote: > > * Type-ignorance: (fixme name?) it is not clear what the > > correct output should look like. We need scans, references, > > examples, etc. > > > > Perhaps more diplomatically as "Typ

Re: GOP-PROP 8: issue priorities (probable decision)

On Wed 10 Aug 2011, 09:46 Graham Percival wrote: > ** More new/changed types > > * Type-crash: any segfault, regardless of what the input file > looks like or which options are given. Disclaimer: this > might not be possible in some cases, for example certain > guile programs

Re: GOP-PROP 8: issue priorities (probable decision)

On Wed 10 Aug 2011, 09:46 Graham Percival wrote: > In case you're wondering: yes, I am serious proposing that we > elminiate priorities completely, and this is not a joke. Nobody Do we want to discuss labels -- backport/invalid/invalid-verified/etc-etc or like that, as this was discussed a bit in

Re: Fixes heights and pure heights of stems. (issue 4898044)

Hey all, Thanks for your comments! I'm outta town now, so I won't be able to fully reply till tomorrow, but I'm working on everything you've suggested with the code and regtests. Also, just a quick reply to let you know that the calc_stem_end and calc_stem_begin methods are left in the code bas

[PATCH] Loglevels for python scripts

this patch adds the --loglevel option also to most of our python scripts (lilypond-book, musicxml2ly, convert-ly): http://codereview.appspot.com/4908041 Please review, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http:

Re: Fixes heights and pure heights of stems. (issue 4898044)

Hey all, I've addressed all the concerns sent in so far in a new patch set. Cheers, MS http://codereview.appspot.com/4898044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: cartouche collides with heading

- Original Message - From: "Werner LEMBERG" To: Sent: Monday, August 15, 2011 5:10 AM Subject: Fw: cartouche collides with heading A fix from Karl. Please test and report back. Updating the current delivered texinfo.tex with this patch fixes our problem. However, we need to be c

Re: cartouche collides with heading

> Updating the current delivered texinfo.tex with this patch fixes our > problem. Good! > However, we need to be careful accepting a new version of > texinfo.tex without full testing. Running the version that you > forwarded 10 days ago fails on learning.texi with this output: > ... > l.232 @fun

Issue 905: Gracefully ignore UTF-8 BOM in the middle of a file (issue 4908043)

Could you please tell me what this patch is good for? A BOM not at the beginning of a file is no longer a BOM... I don't oppose to emitting a warning if U+FEFF is encountered, and we subsequently ignore it (since its use as zero width no-break space is deprecated), but only within strings... Wh

Re: Issue 905: Gracefully ignore UTF-8 BOM in the middle of a file (issue 4908043)

Reviewers: lemzwerg, Message: On 2011/08/15 18:14:21, lemzwerg wrote: Could you please tell me what this patch is good for? A BOM not at the beginning of a file is no longer a BOM... I don't oppose to emitting a warning if U+FEFF is encountered, and we subsequently ignore it (since its use

Re: GOP-PROP 8: issue priorities (probable decision)

On Mon, Aug 15, 2011 at 02:56:21PM +0300, Dmytro O. Redchuk wrote: > On Wed 10 Aug 2011, 09:46 Graham Percival wrote: > > ** More new/changed types > > No type-documentation any more? Why? Sorry, I've jumped a bit late thought. That was only a list of changed types. Anything left unmentioned (i.

Re: GOP-PROP 8: issue priorities (probable decision)

On Mon, Aug 15, 2011 at 03:00:05PM +0300, Dmytro O. Redchuk wrote: > On Wed 10 Aug 2011, 09:46 Graham Percival wrote: > > In case you're wondering: yes, I am serious proposing that we > > elminiate priorities completely, and this is not a joke. Nobody > > Do we want to discuss labels -- backport/

Re: GOP-PROP 8: issue priorities (probable decision)

Am Monday, 15. August 2011, 21:36:58 schrieb Graham Percival: > I know that there's some dissatisfaction with the way that > "invalid/duplicate/verified" works, but that relies on google's > infrastructure, and I'm not certain if anybody has bothered to > follow this up with google yet. http://cod

Re: Issue 905: Gracefully ignore UTF-8 BOM in the middle of a file (issue 4908043)

On 2011/08/15 18:14:21, lemzwerg wrote: Could you please tell me what this patch is good for? A BOM not at the beginning of a file is no longer a BOM... I don't oppose to emitting a warning if U+FEFF is encountered, and we subsequently ignore it (since its use as zero width no-break space i

Fixes issue 1628. (issue 4876051)

Reviewers: , Message: Cheers, MS Description: Fixes issue 1628. Please review this at http://codereview.appspot.com/4876051/ Affected files: M lily/include/slur-scoring.hh M lily/include/slur.hh M lily/new-fingering-engraver.cc M lily/slur-configuration.cc M lily/slur-engraver.cc M

recent commit breaks GUB releases

We've had a number of relatively big internal changes, and I would really like to have a release to make sure that things haven't broken in the regtests or for users. However, I cannot build GUB due to 7cd9444ea5dfc80782befa6b64bae015bddbd967 http://code.google.com/p/lilypond/issues/detail?id=1820

Re: Fixes heights and pure heights of stems. (issue 4898044)

On 15 August 2011 13:31, wrote: > Also, just a quick reply to let you know that the calc_stem_end and > calc_stem_begin methods are left in the code base for people who want to > override the Y-extent of the stem while conserving either the beginning > or end of the stem, ie: > > \override Stem

Fix 1816: Lilypond-Book: don't clear the auto-detected line-with, rather modify it (issue 4888046)

Thanks so much for looking into this! http://codereview.appspot.com/4888046/diff/1/python/book_snippets.py File python/book_snippets.py (left): http://codereview.appspot.com/4888046/diff/1/python/book_snippets.py#oldcode424 python/book_snippets.py:424: if type == 'lilypond': This part is only e

Re: [PATCH] Loglevels for python scripts

General comment: python has a nifty logging module. If we're doing large changes in this space, we might as well switch over to that. On Mon, Aug 15, 2011 at 10:44 AM, Reinhold Kainhofer wrote: > this patch adds the --loglevel option also to most of our python scripts > (lilypond-book, musicxml2

Re: Fixes heights and pure heights of stems. (issue 4898044)

On Sun, Aug 14, 2011 at 1:25 PM, wrote: > THE UGLY: > > Because this patch effects stem extents across the board, the regtest > comparisons are nightmarish to check.  The layout probably does not > change at all in most regtests (at least not to the naked eye), but > because of the change in Y-e

Re: Fix 1816: Lilypond-Book: don't clear the auto-detected line-with, rather modify it (issue 4888046)

Reviewers: Graham Percival, http://codereview.appspot.com/4888046/diff/1/python/book_snippets.py File python/book_snippets.py (left): http://codereview.appspot.com/4888046/diff/1/python/book_snippets.py#oldcode424 python/book_snippets.py:424: if type == 'lilypond': On 2011/08/15 21:34:16, Graha

Re: Fixes heights and pure heights of stems. (issue 4898044)

On Aug 15, 2011, at 11:33 PM, Neil Puttock wrote: > On 15 August 2011 13:31, wrote: > >> Also, just a quick reply to let you know that the calc_stem_end and >> calc_stem_begin methods are left in the code base for people who want to >> override the Y-extent of the stem while conserving either

probably no releases until 2011 Sep

We've hit a snag: http://code.google.com/p/lilypond/issues/detail?id=1821 As I've written in that bug report, I don't have physical access to that machine until 2011 Aug 30, and in any case almost all my time is devoted to running GOP. So I'm not going to investigate further. This is unfortunate

Re: Fixes heights and pure heights of stems. (issue 4898044)

overall comment: since you're hijacking the Y-extent property for storing the logical end of the stem, how will you deal with stem flags that are oddly shaped? I think it is legit for a flag to be larger than the end point of the stem. consider a hypothetical flag / |/ x| (hope you get th

Re: Issue 905: Gracefully ignore UTF-8 BOM in the middle of a file (issue 4908043)

OK. Please make the warning message more verbose, though. http://codereview.appspot.com/4908043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Texi2HTML: don't wrap around the contents of table cells. (issue 4891044)

LGTM; please push after fixing Neil's whitespace concerns. http://codereview.appspot.com/4891044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add scripts/auxiliar/guileindent.scm (issue 4896043)

New patch set uploaded with driver script and ignoring detabify output. Neil, what behavior would you like to see for else? THanks, Carl http://codereview.appspot.com/4896043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu

PATCH: 48-Hour countdown 21:00 MDT 2011-08-17

For 21:00 Wednesday August 17 T Issue 1811 : Revise warning re cueDuring font size Rhttp://codereview.appspot.com/4850051 T Issue 1349 : Guile 2.0 compat: Scheme macros must be de

Re: GOP-PROP 8: issue priorities (probable decision)

On Sat, Aug 13, 2011 at 05:26:09PM +0100, Trevor Daniels wrote: > > I like Keith's "Needs". > This easily extends to several labels if we > find that is desirable. Other suggestions: Thanks, I like "Needs_evidence"; it's general enough to apply to "we need to be able to reproduce the bug", "we n

GOP-PROP 8: issue priorities (probable 2)

Minor update for clarity and discussion from the past few days. We're aiming to accept the final proposal on Thursday. http://lilypond.org/~graham/gop/gop_8.html ** Proposal summary Let’s get rid of priorities. We will simply describe bugs in neutral terms; each contributor can search and interp

GOP-PROP 10: scheme indentation

There seems to be general happiness with Carl's work; a few minor tweaks here and there may still be necessary, but hopefully this discussion will pretty much be rubber-stamping. http://lilypond.org/~graham/gop/gop_10.html ** Proposal summary Speaking academically, scheme code style is a “solve

Re: Commas in section headings

On Fri, Aug 12, 2011 at 11:09:45PM +0100, Trevor Daniels wrote: > > Graham Percival wrote Friday, August 12, 2011 10:44 PM > > >Because some new doc editor -- quite possibly with relatively poor > >English skills -- will write something new and @ref{} the section > >name they see in the HMTL docs

Re: Search box changes

On Mon, Aug 08, 2011 at 04:04:17PM +0100, Phil Holmes wrote: > > Now that the regtest is out of the way, I think I can redo this. My > latest concern over the 2 boxes (which I think is a good > enhancement) is getting the translations updated. Since it's been a week, this seems to be in danger o

Re: Fixes issue 1628. (issue 4876051)

So far, so good. Would you include the corresponding changes to phrasing-slur-engraver.cc (mostly a duplication of slur-engraver.cc) in your next patch set? http://codereview.appspot.com/4876051/ ___ lilypond-devel mailing list lilypond-devel@gnu.org