Re: Remove deprecated context properties (issue 560030044 by v.villen...@gmail.com)

Not sure about chordNameExceptionsFull and chordNameExceptionsPartial. I thought our deprecating policy would be to wait for 1 or even 2 stable versions before deleting from source. Well, the snippet demonstrates a user-level reimplementation, but this makes little sense to me. Also, banter-style

Issue 5919 Make InstrumentName.X-offset more robust (issue 553930044 by thomasmorle...@gmail.com)

Reviewers: , Description: Issue 5919 Make InstrumentName.X-offset more robust Currently system-start-text::calc-y-offset takes right end of system-start-grobs into account, which may lead to bad results, if one of them is omitted (collapse-height) or moved to the right. Instead we always use the

Re: Revert "Load only the default font for System_start_delimiter" (issue 557670043 by thomasmorle...@gmail.com)

https://codereview.appspot.com/557670043/diff/569610043/input/regression/system-start-brace-style.ly File input/regression/system-start-brace-style.ly (right): https://codereview.appspot.com/557670043/diff/569610043/input/regression/system-start-brace-style.ly#newcode4

Revert "Load only the default font for System_start_delimiter" (issue 557670043 by thomasmorle...@gmail.com)

Reviewers: , Message: Contains two commits: [PATCH 2/2] Revert "Load only the default font for System_start_delimiter" [PATCH 1/2] Regtest for setting SystemStartGrob.style to 'brace Description: Revert "Load only the default font for System_start_delimiter" This reverts commit

Re: Remove ly:grob-properties (issue 549840044 by hanw...@gmail.com)

> Fixes > Documentation/snippets/overriding-articulations-of-destinct-type, > which should be mirrored back into LSR. Fixed in LSR https://codereview.appspot.com/549840044/

Re: Remove ly:grob-properties (issue 549840044 by hanw...@gmail.com)

On 2020/04/11 16:31:48, thomasmorley651 wrote: > Btw, it's used in > input/regression/multi-measure-rest-reminder.ly > input/regression/scheme-text-spanner.ly > as well. No, that's ly:grob-properties? Bad grepping ... https://codereview.appspot.com/549840044/

Re: Remove ly:grob-properties (issue 549840044 by hanw...@gmail.com)

The change in the snippet is ofcourse nice. Though, please don't delete ly:grob-properties or ly:grob-basic-properties. I use them every day. They are tools to get insights at the grob at hand. Don't judge from our code base and the few occurencies there. Btw, it's used in

Re: mf: use python scripting for generating Emmentaler fonts (issue 553580043 by hanw...@gmail.com)

On 2020/04/02 21:20:58, dak wrote: > On 2020/04/02 21:09:57, thomasmorley651 wrote: > > On 2020/04/02 21:04:06, dak wrote: > > > On 2020/04/02 20:32:39, hanwenn wrote: > > > > Jonas, what is the status of 2.21.0 ? > > > > > > I wanted to give Phil the go-ahead tomorrow, once some backdated

Re: mf: use python scripting for generating Emmentaler fonts (issue 553580043 by hanw...@gmail.com)

On 2020/04/02 21:04:06, dak wrote: > On 2020/04/02 20:32:39, hanwenn wrote: > > Jonas, what is the status of 2.21.0 ? > > I wanted to give Phil the go-ahead tomorrow, once some backdated convert-ly rule > is in. Probably depends on how well the LSR import works whether this gets out > then.

Remove all uses of markup macro from scm/*.scm (issue 575930043 by d...@gnu.org)

patch itself LGTM Ofcourse there are other folders than scm/*.scm, like snippets, snippets/new, ly-examples, Documentation... Follow up planned? https://codereview.appspot.com/575930043/

Re: Issue #1204: Document, and add regtest for, external fonts. (issue 557640051 by v.villen...@gmail.com)

On 2020/03/30 18:29:37, Valentin Villenave wrote: > On 2020/03/30 16:06:08, lemzwerg wrote: > > Is it guaranteed that we can create this directory? What about srcdir != > > builddir? > > Yes. It’s a (tmpnam) name, located in /tmp or $TMPDIR or whatever: >

Re: Add #f to format in lilypond-book.itely (issue 553690043 by thomasmorle...@gmail.com)

On 2020/03/13 13:33:29, hanwenn wrote: > LGTM > > typo in the commit message Done. https://codereview.appspot.com/553690043/

Add #f to format in lilypond-book.itely (issue 553690043 by thomasmorle...@gmail.com)

Reviewers: , Description: Add #f to format in lilypond-book.itely In the defiition of oly:create-toc-file a simple string is wished for the local outfilename. Thus add #f after format in: (outfilename (format "~a.toc" output-name)) Please review this at https://codereview.appspot.com/553690043/

Re: Fix Windows resource to enable manifest (issue 551580044 by truer...@gmail.com)

On 2020/03/08 12:11:43, Be-3 wrote: > On 2020/03/08 11:38:29, dak wrote: > > We don't really document bug fixes as a rule in changes.tely. It's pretty > long > > already... > > Yes, certainly. > But I think this is a special case. Speaking for myself, I'm taking it for > granted that UTF-8

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/03/07 12:39:31, dak wrote: > Han-Wen Nienhuys writes: > > > On Fri, Mar 6, 2020 at 11:18 PM wrote: > >> > >> Sigh. I just noticed that opposed to the patch title, this does not > >> just introduce a file lock for lilypond-book but _also_

Do not allow page breaks on the first column of a score (issue 581720054 by hanw...@gmail.com)

I've applied your patch and did some testings. It indeed solves the code given with boom.ly at https://sourceforge.net/p/testlilyissues/issues/5801/ Though, I posted two minimals there. While the first one now compiles fine, the second still crashes with: GNU LilyPond 2.21.0 Processing

Make make-autochange function upwards-compatible to 2.18 (issue 567280043 by d...@gnu.org)

LGTM https://codereview.appspot.com/567280043/

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

On 2020/02/26 21:56:46, dak wrote: > On 2020/02/26 21:50:05, lemzwerg wrote: > > > How about > > > * beamed-stem-french-adjustment > > > * french-beaming-stem-adjustment > > > …? > > > > I like the second one. > > I'd be fine with it. +1 https://codereview.appspot.com/557500043/

Re: Fix portuguese in all copies of utf-8.ly (issue 571640044 by hanw...@gmail.com)

On 2020/02/18 07:39:45, lemzwerg wrote: > > Werner, may I ask you to have a look? > > What exactly shall I check? If you look at https://lsr.di.unimi.it/form.php?type=snippet;id=600;rld=m_snippet you'll see: portuguese = \lyricmode { à vo -- cê uma can -- ção legal } I don't know how to

Re: Fix portuguese in all copies of utf-8.ly (issue 571640044 by hanw...@gmail.com)

On 2020/02/15 21:41:57, thomasmorley651 wrote: > https://codereview.appspot.com/571640044/diff/571650043/Documentation/snippets/utf-8.ly > File Documentation/snippets/utf-8.ly (right): > > https://codereview.appspot.com/571640044/diff/571650043/Documentation/snippets/utf-8.ly#newcode1 >

Confirm grob-status in input/regression/multi-measure-rest-reminder.ly (issue 547670044 by thomasmorle...@gmail.com)

Reviewers: , Description: Confirm grob-status in input/regression/multi-measure-rest-reminder.ly Oversight Please review this at https://codereview.appspot.com/547670044/ Affected files (+2, -0 lines): M input/regression/multi-measure-rest-reminder.ly Index:

Re: input/regression/multi-measure-rest-reminder: a demo of user-defined grobs (issue 557380044 by hanw...@gmail.com)

On 2020/02/17 10:01:29, hanwenn wrote: > https://codereview.appspot.com/557380044/diff/569320045/input/regression/multi-measure-rest-reminder.ly > File input/regression/multi-measure-rest-reminder.ly (right): > >

Express define-markup-list-command-internal using define-markup-command-internal (issue 555300043 by hanw...@gmail.com)

Not tested, but from reading: very nice. LGTM https://codereview.appspot.com/555300043/

Re: input/regression/multi-measure-rest-reminder: a demo of user-defined grobs (issue 557380044 by hanw...@gmail.com)

https://codereview.appspot.com/557380044/diff/569320045/input/regression/multi-measure-rest-reminder.ly File input/regression/multi-measure-rest-reminder.ly (right): https://codereview.appspot.com/557380044/diff/569320045/input/regression/multi-measure-rest-reminder.ly#newcode26

Re: input/regression/multi-measure-rest-reminder: a demo of user-defined grobs (issue 557380044 by hanw...@gmail.com)

Sorry being that late to the party. Though, I'm confused. Iiuc a new grob called MultiMeasureRestReminder should be created. Alas, if I try to insert \override Voice.MultiMeasureRestReminder.after-line-breaking = #'() I get: warning: not a grob name, `MultiMeasureRestReminder' What am I missing?

Re: Inline assembler fallback for _FPU_SETCW() missing in x86 platforms (issue 575600043 by thomasmorle...@gmail.com)

On 2020/02/01 00:52:15, thomasmorley651 wrote: > This adds Masamichi-san's suggestions from > https://codereview.appspot.com/577450043/ > Comment #7 > Sorry, for the new issue, initiated by accident > > This does _not_ reflect the discussion of >

Re: Fix portuguese in all copies of utf-8.ly (issue 571640044 by hanw...@gmail.com)

https://codereview.appspot.com/571640044/diff/571650043/Documentation/snippets/utf-8.ly File Documentation/snippets/utf-8.ly (right): https://codereview.appspot.com/571640044/diff/571650043/Documentation/snippets/utf-8.ly#newcode1 Documentation/snippets/utf-8.ly:1: % DO NOT EDIT this file

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

On 2020/02/09 15:32:14, lilypond_ptoye.com wrote: > Surely "standard scale pitch or previously altered pitch". In D major: "cis c > cis" the first note is an alteration but not an accidental, the second is an > accidental but not an alteration, the third is both. Now I'm really splitting > hairs.

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

I'd love to see more opinions about comments #12 and #14. Otherwise I'd object to this part of the patch https://codereview.appspot.com/579280043/

Re: parser-ly-from-scheme: Make #{ compilable (issue 581610043 by d...@gnu.org)

On 2020/02/08 22:02:59, dak wrote: > Uh, is this the right issue to discuss this with? Likely not, I opened a thread on -devel. > Are you completely sure that you are using a version of LilyPond compiled with > Guile-2.2.6? At least $ lilypond-git scheme-sandbox returns: GNU LilyPond

Don't let display-lily-tests use anonymous functions (issue 545550044 by d...@gnu.org)

LGTM https://codereview.appspot.com/545550044/

parser-ly-from-scheme: Make #{ compilable (issue 581610043 by d...@gnu.org)

Afaict, LGTM A remark: https://codereview.appspot.com/581610043/diff/569310043/scm/parser-ly-from-scheme.scm File scm/parser-ly-from-scheme.scm (right): https://codereview.appspot.com/581610043/diff/569310043/scm/parser-ly-from-scheme.scm#newcode19 scm/parser-ly-from-scheme.scm:19: (define

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/common-notation.itely File Documentation/learning/common-notation.itely (right): https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/common-notation.itely#newcode162

Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ball...@gmail.com)

Hi Dan, I've difficulties to understand what this is about. And my lack of C++-knowledge hinders my to deduce it. Could you give a ly-code-example which is not possible with current possibilities or where using current possibilities leads to some uglyness?

Inline assembler fallback for _FPU_SETCW() missing in x86 platforms (issue 575600043 by thomasmorle...@gmail.com)

Reviewers: arnold.wendl_siemens.com2, Message: This adds Masamichi-san's suggestions from https://codereview.appspot.com/577450043/ Comment #7 Sorry, for the new issue, initiated by accident This does _not_ reflect the discussion of

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

On 2020/01/31 10:45:42, trueroad wrote: > Hello Arnold. > Thank you for your patch. > > If I understand correctly, we only need check the definitions of `__x86__` and > `__i386__` check. > > In x86_64 environment, neither `__x86__` nor `__i386__` are defined. > > ``` > $ echo |

Re: allow overriding of GUILE_AUTO_COMPILE (issue 579270043 by hanw...@gmail.com)

https://codereview.appspot.com/579270043/diff/579270044/lily/main.cc File lily/main.cc (right): https://codereview.appspot.com/579270043/diff/579270044/lily/main.cc#newcode760 lily/main.cc:760: sane_putenv("GUILE_AUTO_COMPILE", "1", false); // disable auto-compile Shouldn't the comment be

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

https://codereview.appspot.com/577450043/diff/579260043/lily/main.cc File lily/main.cc (right): https://codereview.appspot.com/577450043/diff/579260043/lily/main.cc#newcode174 lily/main.cc:174: /* x86 defaults to using 80-bit extended precision arithmetic. This can cause On 2020/01/29 23:54:27,

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

On 2020/01/29 22:36:03, Carl wrote: > While this answer is specific, it could be clearer, IMO: > > Reviewing the Intel Manuals at > https://software.intel.com/sites/default/files/managed/a4/60/253665-sdm-vol-1.pdf > Section 4.2.2. > > We can see that the 64 bit significand of Double Extended

Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

Reviewers: , Description: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries Issue 4943 As Issue 4943 on Windows compilation was triggered by missing _FPU_SETCW() in the MINGW libraries, an alternate call to initiate the X87 FPU setup as an inline-assembler command is added -

Re: Doc: Corrected doc string for ly:dimension? (issue 547470049 by davidgrant...@gmail.com)

I don't see any difference to checking for a number either. Thus "distinguish" feels strange. Ofcourse it's a predicate, thus LGTM Thanks! You can't be motivated to go through the other doc-strings listed in IR 4. Scheme functions ? :) https://codereview.appspot.com/547470049/

Re: ly_scm_write_string: call scm_write directly (issue 545450043 by hanw...@gmail.com)

Here https://lists.gnu.org/archive/html/lilypond-devel/2019-10/msg00236.html I reported some problems, likely caused by ly_scm_write_string. Once I'll be back from Salzburg I'll try to compile LilyPond against guile-3.0 with the patches linked above and the changes mentioned here:

Re: Issue 5656: Warn about accessing the Global context explicitly (issue 567050043 by nine.fierce.ball...@gmail.com)

On 2020/01/14 17:43:19, Dan Eble wrote: On 2020/01/14 13:12:54, Dan Eble wrote: > Harm, > Do you want more time to consider this change, or are you now comfortable with > my pushing it? Since your primary concern was that modifying Global in a \layout block should still work, and my

Re: Doc: Added documentation for fill-line line-width (issue 583340043 by davidgrant...@gmail.com)

The patch itself LGTM Though sometimes I muse about whether we need NR 1.8.2 Formatting text in it's current state at all. Why do we explain some markup-commands explicitely and others not? They are all listed with examples in NR A.11 Text markup commands! An alternative would be to improve

Issue 5656: Warn about accessing the Global context explicitly (issue 567050043 by nine.fierce.ball...@gmail.com)

I know several custom codings (defining a new grob, thus the need to reintroduce all-grob-descriptions at Global level) using \layout { \context { \Global \grobdescriptions #all-grob-descriptions } } will this be disallowed with this patch? Then I'd object. If it stays allowed, why

Re: Introduce breakingRehearsalMarks for line-breaking RehearsalMarks (issue 577180043 by thomasmorle...@gmail.com)

Dan, I've set it to needs_work for now. https://codereview.appspot.com/577180043/

Re: Fix regtests about Footnote (issue 549320043 by thomasmorle...@gmail.com)

patch-description is changed. Fixing footnote-auto-numbering-vertical-order.ly will take more work than simply correct context-settings https://codereview.appspot.com/549320043/

Fix regtests about Footnote (issue 549320043 by thomasmorle...@gmail.com)

Reviewers: , Description: Fix regtests about Footnote Several regtest about FootnoteItem/Spanner contained overrides without specifying the context. Footnote_engraver lives in Score-context, though. Thus the Score-context is added to the overrides in:

Re: Introduce breakingRehearsalMarks for line-breaking RehearsalMarks (issue 577180043 by thomasmorle...@gmail.com)

Hi Dan, up to now we provide only RehearsalMark taking arbitrary text with the possibility to align it to the value taken from 'break-align-symbols. The other grobs supporting break-alignable-interface are BarNumber and MetronomeMark, even less convenient to take arbitrary text. So users have no

Re: Introduce breakingRehearsalMarks for line-breaking RehearsalMarks (issue 577180043 by thomasmorle...@gmail.com)

On 2019/12/07 17:48:07, Dan Eble wrote: Harm, I have to prepare for a musical event tonight. I will probably be some time before I can review and understand your changes. I've no problem to postpone this for while. Please clarify whether you are using this for genuine rehearsal marks

Introduce breakingRehearsalMarks for line-breaking RehearsalMarks (issue 577180043 by thomasmorle...@gmail.com)

Reviewers: , Description: Introduce breakingRehearsalMarks for line-breaking RehearsalMarks This music-function expects two mark-events and puts out different stencils at line-end/start looking at the label-properties of the marks. Incrementing the mark is done. Text-input is accepted,

Re: Issue 5630: use alt="" in regtest HTML to appease tidy 5.2.0 (issue 551250043 by nine.fierce.ball...@gmail.com)

From testing with tidy 5.2.0 LGTM https://codereview.appspot.com/551250043/

Re: add property label-alignments to OttavaBracket (issue 575330043 by lilyp...@maltemeyn.de)

What about a regtest? https://codereview.appspot.com/575330043/

Re: Implement MeasureAttachedSpanner (issue 571180043 by david.nales...@gmail.com)

Thanks for working on it !! Some other nits: https://codereview.appspot.com/571180043/diff/565230043/lily/measure-attached-spanner.cc File lily/measure-attached-spanner.cc (right): https://codereview.appspot.com/571180043/diff/565230043/lily/measure-attached-spanner.cc#newcode93

Re: Implement MeasureAttachedSpanner (issue 571180043 by david.nales...@gmail.com)

https://codereview.appspot.com/571180043/diff/565230043/ly/spanners-init.ly File ly/spanners-init.ly (right): https://codereview.appspot.com/571180043/diff/565230043/ly/spanners-init.ly#newcode25 ly/spanners-init.ly:25: "View side-by-side diff with in-line comments" is broken for this file.

Re: Implement MeasureAttachedSpanner (issue 571180043 by david.nales...@gmail.com)

On 2019/11/16 14:27:25, Dan Eble wrote: On 2019/11/15 19:21:09, Carl wrote: > I think the name should be changed from MeasureAttachedSpanner to > BarAttachedSpanner. Calling it just MeasureSpanner would also address the specific problem you raised. Is it more important for the name to

Re: Fix underline-markup to make multiple calls have nice output (issue 559150043 by thomasmorle...@gmail.com)

On 2019/10/21 11:20:03, dak wrote: > > The combination > > \markup \underline \overtie huh > > would likely be madly confusing if the \underline managed to shift the \overtie > around. So maybe \underline should retain the previous meaning and setting of offset and add an _additional_

Re: Fix underline-markup to make multiple calls have nice output (issue 559150043 by thomasmorle...@gmail.com)

On 2019/10/21 11:24:02, thomasmorley651 wrote: On 2019/10/21 11:13:17, dak wrote: > The combination > > \markup \underline \overtie huh > > would likely be madly confusing if the \underline managed to shift the \overtie > around. One could work around with \markup \underline

Re: Fix underline-markup to make multiple calls have nice output (issue 559150043 by thomasmorle...@gmail.com)

On 2019/10/21 10:31:32, dak wrote: On 2019/10/21 09:52:41, thomasmorley651 wrote: > Does this one need a convert-rule? > > If so, I'd need some help. My python-skill is more or less zero. I've just taken some look. It would appear that the only other markup commands using the "offset"

Re: Fix underline-markup to make multiple calls have nice output (issue 559150043 by thomasmorle...@gmail.com)

On 2019/10/21 11:13:17, dak wrote: The combination \markup \underline \overtie huh would likely be madly confusing if the \underline managed to shift the \overtie around. One could work around with \markup \underline \underline \underline \underline \underline \override

Fix underline-markup to make multiple calls have nice output (issue 559150043 by thomasmorle...@gmail.com)

Reviewers: , Message: Does this one need a convert-rule? If so, I'd need some help. My python-skill is more or less zero. Description: Fix underline-markup to make multiple calls have nice output Amend regtest markup-commands.ly with an example for it. Please review this at

Add ly version t0 swing.ly (issue 562850043 by thomasmorle...@gmail.com)

Reviewers: , Message: While testing GUB this one popped up. Not sure if it's the cause of GUB-fail, but should be fixed anyway. As soon as the automated tests succeed I'll push it prematurely. Description: Add ly version t0 swing.ly Please review this at

New function css-color (accompanying x11-color) (issue 570690043 by g...@ursliska.de)

https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm File scm/color.scm (right): https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm#newcode678 scm/color.scm:678: (define css-color-list Is there anything new in this list or are all entries always alias? If

Re: Document bound-details (sub-)properties in line-spanner-cc for IR (issue 560670043 by thomasmorle...@gmail.com)

Thanks for review https://codereview.appspot.com/560670043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Give NoteNames context an \alias Staff (issue 544700043 by d...@gnu.org)

I didn't find the time to do it myself, sorry. Ofcourse, LGTM https://codereview.appspot.com/544700043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Document bound-details (sub-)properties in line-spanner-cc for IR (issue 560670043 by thomasmorle...@gmail.com)

https://codereview.appspot.com/560670043/diff/582680043/lily/line-spanner.cc File lily/line-spanner.cc (right): https://codereview.appspot.com/560670043/diff/582680043/lily/line-spanner.cc#newcode421 lily/line-spanner.cc:421: " @code{stencil-offset}, expecting a number-pair, the stencil" On

Re: Document bound-details (sub-)properties in line-spanner-cc for IR (issue 560670043 by thomasmorle...@gmail.com)

On 2019/05/11 03:55:46, lemzwerg wrote: https://codereview.appspot.com/560670043/diff/552680043/lily/line-spanner.cc File lily/line-spanner.cc (right): https://codereview.appspot.com/560670043/diff/552680043/lily/line-spanner.cc#newcode421 lily/line-spanner.cc:421: " of the line" Oh, here

Re: Document bound-details (sub-)properties in line-spanner-cc for IR (issue 560670043 by thomasmorle...@gmail.com)

https://codereview.appspot.com/560670043/diff/550690043/lily/line-spanner.cc File lily/line-spanner.cc (right): https://codereview.appspot.com/560670043/diff/550690043/lily/line-spanner.cc#newcode395 lily/line-spanner.cc:395: "Sets the Y-coordinate of the end point, in staff-spaces" On

Document bound-details (sub-)properties in line-spanner-cc for IR (issue 560670043 by thomasmorle...@gmail.com)

Reviewers: , Message: Please review Description: Document bound-details (sub-)properties in line-spanner-cc for IR Please review this at https://codereview.appspot.com/560670043/ Affected files (+44, -1 lines): M lily/line-spanner.cc Index: lily/line-spanner.cc diff --git

Re: Avoid some crashes for bad "control-points" property (issue 576610043 by d...@gnu.org)

On 2019/04/28 19:14:53, dak wrote: Fix slur configuration too (thanks, Han-Wen) I've downloaded you're patch. After playing around with it: all seems to work nicely, no glitch found. Thus, from testing: LGTM https://codereview.appspot.com/576610043/

Avoid some crashes for bad "control-points" property (issue 576610043 by d...@gnu.org)

As always, I can't review C++. So let me ask, how will LilyPond react seeing 5 or more control-points after your patch? https://codereview.appspot.com/576610043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org

Use new syntax throughout the doc and examples (issue 572640043 by v.villen...@gmail.com)

LGTM Some nit below Thanks, Harm https://codereview.appspot.com/572640043/diff/552640043/scm/define-markup-commands.scm File scm/define-markup-commands.scm (right): https://codereview.appspot.com/572640043/diff/552640043/scm/define-markup-commands.scm#newcode1310

Add doc-string for allowVoltaHook (issue 556640043 by thomasmorle...@gmail.com)

Reviewers: , Description: Add doc-string for allowVoltaHook Please review this at https://codereview.appspot.com/556640043/ Affected files (+1, -0 lines): M ly/property-init.ly Index: ly/property-init.ly diff --git a/ly/property-init.ly b/ly/property-init.ly index

Reflect new syntax in example of define-grob-properties.scm (issue 560620043 by thomasmorle...@gmail.com)

Reviewers: , Description: Reflect new syntax in example of define-grob-properties.scm Please review this at https://codereview.appspot.com/560620043/ Affected files (+1, -2 lines): M scm/define-grob-properties.scm Index: scm/define-grob-properties.scm diff --git

Re: Charles Winston's chord-semantics GSOC work (issue 568650043 by carl.d.soren...@gmail.com)

On 2019/04/08 18:47:13, lilypond-pkx wrote: Are we sure all the reg tests are OK (see tracker for download link)? For example regression/chord-name-major7.ly This looks completely broken with this patch I had a look at the regtest-results, too. Though, I didn't check for changed code

Re: Charles Winston's chord-semantics GSOC work (issue 568650043 by carl.d.soren...@gmail.com)

On 2019/04/08 18:47:13, lilypond-pkx wrote: Are we sure all the reg tests are OK (see tracker for download link)? For example regression/chord-name-major7.ly This looks completely broken with this patch I had a look at the regtest-results, too. Though, I didn't check for changed code

Re: Axis_group_engraver + Scheme engraver for staff combining (issue 576540043 by pkxgnugi...@runbox.com)

On 2019/03/18 22:26:15, dak wrote: mailto:thomasmorle...@gmail.com writes: > On 2019/03/17 01:45:49, saul.james.tobin wrote: > >> Re cdr is not a predicate — the list being processed here is composed > of >> pairs, the cdr of which is ##t or ##f. > > The description is still confusing. Do

Re: Axis_group_engraver + Scheme engraver for staff combining (issue 576540043 by pkxgnugi...@runbox.com)

On 2019/03/17 01:45:49, saul.james.tobin wrote: Re cdr is not a predicate — the list being processed here is composed of pairs, the cdr of which is ##t or ##f. The description is still confusing. Do you mean something like below? #(define (divide-true-cdr ls) "Split @var{ls} into those

Re: Add a procedure to add slashes to Beams and straight Flags (issue 562550043 by thomasmorle...@gmail.com)

Hi Malte, thanks for review. Currently I follow a different route: create a Slash-grob. Once it is mature I'll publish a concurrent patch-set in a different issue. For now I'll set this one back to 'needs-work'. However you spotted some valid points, which I'll likely have to take into account

Add warning message for unknown code in fret-diagram-verbose (issue 570540043 by carl.d.soren...@gmail.com)

https://codereview.appspot.com/570540043/diff/548530043/scm/fret-diagrams.scm File scm/fret-diagrams.scm (right): https://codereview.appspot.com/570540043/diff/548530043/scm/fret-diagrams.scm#newcode267 scm/fret-diagrams.scm:267: (symbol->string my-code symbol->string relies on my-code

Re: Axis_group_engraver + Scheme engraver for staff combining (issue 576540043 by pkxgnugi...@runbox.com)

Can't review C++-code. Some concerns in the ly-file: https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly File ly/divisi_engraver.ly (right): https://codereview.appspot.com/576540043/diff/578520043/ly/divisi_engraver.ly#newcode3 ly/divisi_engraver.ly:3: % From

Fix #687: Include MIDI swing script in default distribution (issue 572520044 by v.villen...@gmail.com)

Hi Valentin, up to now I didn't test, but read the code only. Several small suggestions: https://codereview.appspot.com/572520044/diff/574520044/ly/swing.ly File ly/swing.ly (right): https://codereview.appspot.com/572520044/diff/574520044/ly/swing.ly#newcode99 ly/swing.ly:99: (fold (lambda (x

Re: Add a procedure to add slashes to Beams and straight Flags (issue 562550043 by thomasmorle...@gmail.com)

On 2019/03/10 17:08:33, Valentin Villenave wrote: On 2019/03/10 13:37:42, thomasmorley651 wrote: > Oversights Greetings Harm, looks good; much better than the hack I had previously suggested about #1333. However, you’re using a somewhat similar approach (although much more fine-tuned) by

Add a procedure to add slashes to Beams and straight Flags (issue 562550043 by thomasmorle...@gmail.com)

Reviewers: , Message: Please review Description: Add a procedure to add slashes to Beams and straight Flags Adds procedure slash-stencil to stencil.scm Replaces add-stroke-straight from flag-styles.scm with slash-stencil. Amends defs in grace-init.ly with slashedBeam. Amends Beam.details.

Doc: CG - Minor updates to 3.4.9 - Commit access (issue 566540043 by pkxgnugi...@runbox.com)

It's too long I had to follow those lines, thus I can't say anything to your changes. One nit: https://codereview.appspot.com/566540043/diff/566530044/Documentation/contributor/source-code.itexi File Documentation/contributor/source-code.itexi (right):

Re: Issue 5489: improve prall glyphs (issue 341560043 by lilyp...@maltemeyn.de)

Thanks for correcting the imho wrong spelling of "trilelement". Please add a conversion rule for it. Sometimes I used "trilelement" and maybe I'm not the only one. https://codereview.appspot.com/341560043/ ___ lilypond-devel mailing list

Re: add fermata markup commands (issue 344160043 by lilyp...@maltemeyn.de)

On 2019/02/28 09:41:26, lemzwerg wrote: [Oops, pressed the wrong button] The idea of \fermata 'foo is its open endedness; you don't have to define a new command for a new fermata type. I'm a fan of a smaller set of multiplex commands instead of a larger set of specific macros

Re: Use "simple strings" rather than #"hash-prefixed Scheme strings" (issue 363910043 by v.villen...@gmail.com)

On 2019/02/10 18:41:33, Carl wrote: Because this represents a change in the documentation policy as listed in the CG, I think it should be discussed. In the past, one could get along by saying "All properties start with #", even though it wasn't strictly necessary. With this new change,

Issue 5218: document footnote-separator-markup (issue 349080043 by lilyp...@maltemeyn.de)

Some nits: https://codereview.appspot.com/349080043/diff/1/Documentation/notation/spacing.itely File Documentation/notation/spacing.itely (right): https://codereview.appspot.com/349080043/diff/1/Documentation/notation/spacing.itely#newcode1082 Documentation/notation/spacing.itely:1082: bottom

Re: Issue 5251/1: set default restNumberThreshold = 1 (issue 353850043 by lilyp...@maltemeyn.de)

Sorry to come back to this that late. I can't comment on the C++ part of it. Some other remarks, though: https://codereview.appspot.com/353850043/diff/60001/input/regression/multi-measure-rest-number-threshold.ly File input/regression/multi-measure-rest-number-threshold.ly (right):

Re: Issue 5251/1: set default restNumberThreshold = 1 (issue 353850043 by lilyp...@maltemeyn.de)

While you're on it, how about creating a reg-test? Currently 'restNumberThreshold' is only used in 'input/regression/mozart-hrn3-defs.ily', which is included in 'input/regression/mozart-hrn-3.ly' Though, it uses 'restNumberThreshold = #1', not much of a test ...

Re: Issue 5251/1: set default restNumberThreshold = 1 (issue 353850043 by lilyp...@maltemeyn.de)

https://codereview.appspot.com/353850043/diff/1/Documentation/snippets/new/numbering-single-measure-rests.ly File Documentation/snippets/new/numbering-single-measure-rests.ly (right):

Issue 5251/1: set default restNumberThreshold = 1 (issue 353850043 by lilyp...@maltemeyn.de)

Hi Malte, some concerns: https://codereview.appspot.com/353850043/diff/1/Documentation/notation/rhythms.itely File Documentation/notation/rhythms.itely (right): https://codereview.appspot.com/353850043/diff/1/Documentation/notation/rhythms.itely#newcode966

Give \key command a better predicate for scale type (issue 357840043 by d...@gnu.org)

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

Re: Improve markup->string (issue 347000043 by thomasmorle...@gmail.com)

Hi Paul, thanks for review https://codereview.appspot.com/34743/diff/40001/scm/markup.scm File scm/markup.scm (right): https://codereview.appspot.com/34743/diff/40001/scm/markup.scm#newcode141 scm/markup.scm:141: ;; The string is split at line-breaks, emty strings removed and finally

Re: Improve markup->string (issue 347000043 by thomasmorle...@gmail.com)

On 2018/11/11 15:08:57, thomasmorley651 wrote: simplify, catch string-markups patch-set 3 reflects my musing in comment #5 https://codereview.appspot.com/34743/ ___ lilypond-devel mailing list lilypond-devel@gnu.org

Re: Improve markup->string (issue 347000043 by thomasmorle...@gmail.com)

On 2018/11/11 11:07:35, dak wrote: On 2018/11/11 10:57:31, thomasmorley651 wrote: > 'all-relevant-markup-commands' tries to get all markup-(list-)commands where > 'markup->string' may return reasonable output. I have to get used to the thought of not having the monopoly on good ideas.

Re: Improve markup->string (issue 347000043 by thomasmorle...@gmail.com)

On 2018/11/10 12:53:18, dak wrote: I wonder whether it might be reasonable to just have all markup commands with a last argument of markup? produce their last (recursively treated) argument as default, and possibly all markup list commands with a last argument of markup-list? similarly

Improve markup->string (issue 347000043 by thomasmorle...@gmail.com)

Reviewers: , Message: Please review. There are some TODOs in the code where I'd appreciate some feedback. Thanks- Description: Improve markup->string 'all-relevant-markup-commands' is now a toplevel-defined procedure. So it is not longer a part of the rekursive 'markup->string'. It needs to be

Use different `values' implementation of Guilev2 (issue 345100043 by d...@gnu.org)

I can't review the code but I've tested with guile-versions: 1.8.8, 2.0.14, 2.2.4, 2.9.1 It always works as desired. Thus LGTM https://codereview.appspot.com/345100043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org

  1   2   3   4   5   >