https://codereview.appspot.com/201140043/diff/1/input/regression/minimum-length-after-break.ly
File input/regression/minimum-length-after-break.ly (right):
https://codereview.appspot.com/201140043/diff/1/input/regression/minimum-length-after-break.ly#newcode15
input/regression/minimum-length-aft
please review
https://codereview.appspot.com/199460043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/201140043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2015/02/09 06:09:34, lemzwerg wrote:
LGTM. It would be nice if David's checker script could be added, too.
More, I'd consider it a good idea to use the checker on the current
patch again.
There was such a mess that I'm not sure I corrected all.
https://codereview.appspot.com/199460043/di
'using-alternative-flag-styles.ly' is not in Documentation/snippets/new/
any more.
I changed it directly in LSR. The changed snippet will show up after
next LSR-import.
Looks I can't post to the tracker-issue for 3591 any more, because it's
closed.
https://codereview.appspot.com/14303044/
_
Reviewers: ,
Message:
please review
Description:
making measure-counter-stencil public
Issue 4292
In order to work with 'make-stencil-boxer' etc
Please review this at https://codereview.appspot.com/203130043/
Affected files (+1, -1 lines):
M scm/output-lib.scm
Index: scm/output-lib.scm
d
https://codereview.appspot.com/207620043/diff/20001/scm/output-lib.scm
File scm/output-lib.scm (right):
https://codereview.appspot.com/207620043/diff/20001/scm/output-lib.scm#newcode1190
scm/output-lib.scm:1190: (shift (if (and (ly:grob? script-column)
minor nit:
Is it possible to stick to the 8
https://codereview.appspot.com/207620043/diff/20001/scm/output-lib.scm
File scm/output-lib.scm (right):
https://codereview.appspot.com/207620043/diff/20001/scm/output-lib.scm#newcode1196
scm/output-lib.scm:1196: (grob::has-interface s 'script-interface)
On 2015/03/11 23:49:44, thomasmorley651 wr
LGTM
https://codereview.appspot.com/207620043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
One question:
https://codereview.appspot.com/217260043/diff/1/scm/output-lib.scm
File scm/output-lib.scm (right):
https://codereview.appspot.com/217260043/diff/1/scm/output-lib.scm#newcode165
scm/output-lib.scm:165: (use-modules (ice-9 pretty-print))
I always regretted that (ice-9 pretty-
https://codereview.appspot.com/217260043/diff/1/scm/output-lib.scm
File scm/output-lib.scm (right):
https://codereview.appspot.com/217260043/diff/1/scm/output-lib.scm#newcode165
scm/output-lib.scm:165: (use-modules (ice-9 pretty-print))
On 2015/03/25 13:59:20, david.nalesnik wrote:
On 2015/03/2
Reviewers: ,
Message:
please review
Description:
No midi with ChordNames
Issue 4330
Restore the behaviour for ChordNames and ChordNameVoice in
performer-init.ly
which was changed by the patch for issue 4281
Please review this at https://codereview.appspot.com/217450043/
Affected files (+7, -
https://codereview.appspot.com/222810043/diff/1/ly/init.ly
File ly/init.ly (right):
https://codereview.appspot.com/222810043/diff/1/ly/init.ly#newcode38
ly/init.ly:38: #(use-modules (ice-9 pretty-print))
On 2015/04/07 17:43:07, david.nalesnik wrote:
On 2015/04/07 16:13:44, dak wrote:
> Uh, wher
On 2015/04/08 08:11:35, dak wrote:
On 2015/04/07 23:25:09, thomasmorley651 wrote:
> https://codereview.appspot.com/222810043/diff/1/ly/init.ly
> File ly/init.ly (right):
>
> https://codereview.appspot.com/222810043/diff/1/ly/init.ly#newcode38
> ly/init.ly:38: #(use-modules (ice-9 pretty-print))
>
On 2015/04/08 10:21:55, dak wrote:
value->lily-string is probably the most useful reasonably generic
printing
facility right now. But nobody really knows it.
At least, I wasn't aware of it, because of (in a ly-file)
#(display value->lily-string)
-> Unbound variable: value->lily-string
ht
Please review.
Intended is a pure maintaining change. Maybe a first step for more
flexibility, easier customizing etc.
If I sorted it correctly, no change in visible output should occur.
Apart from the Banter-style (see commit-message) no bug-fixing happens,
although I noticed one (see FIXME in
On 2015/04/13 02:22:15, Carl wrote:
I think that this is a great start. You're working in a really
complex area,
and trying to sort it out. Good for you!
I've made some specific comments below. I think the separation
between list
creation and markup creation needs to be made stronger an
Although, this is not the final patch for this topic, James, may I ask
you to run patchy against it?
https://codereview.appspot.com/223420043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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 i
I suggest to update regtests ‘markup-rest.ly’ and
‘markup-rest-styles.ly’ as well.
If no glyph for a certain style is found the default is taken anyway,
but it would be nice if the new glyphs would be demonstrated via markup
as well.
Also, it deserves an entry in changes, imho.
https://codereview
Can't review this one.
Though, from description, I'd like to suggest to put up an entry in
`changes'.
https://codereview.appspot.com/336670043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
A nit below
https://codereview.appspot.com/339390043/diff/1/input/regression/textetc.ly
File input/regression/textetc.ly (right):
https://codereview.appspot.com/339390043/diff/1/input/regression/textetc.ly#newcode5
input/regression/textetc.ly:5: event functions for \\samp{TextScript}
even
On 2018/03/20 12:56:37, dak wrote:
On 2018/03/16 19:19:15, thomasmorley651 wrote:
> Can't review this one.
> Though, from description, I'd like to suggest to put up an entry in
`changes'.
Ugh. Documentation for \etc is sort-of sparse, and the main problem
for
"Changes" is "which Changes"?
Hi Dan,
some remarks/questions:
https://codereview.appspot.com/340650043/diff/1/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
https://codereview.appspot.com/340650043/diff/1/ly/music-functions-init.ly#newcode833
ly/music-functions-init.ly:833: #(define-music-function (lab
LGTM
https://codereview.appspot.com/344770043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi Carl,
many thanks for your work.
Some remarks:
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#new
On 2018/04/30 22:19:12, Carl wrote:
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/343060043/diff/40001/Documentation/learning/fundamental.itely#newcode465
Doc
On 2018/04/30 22:55:35, thomasmorley651 wrote:
On 2018/04/30 22:19:12, Carl wrote:
> I don't think I agree that things are attached with "-" signs. For
example,
> \staccato, \mordent, \turn, \fermata, \prall, (, [. None of these
are attached
> with "-" signs, although they can have a dire
On 2018/05/01 02:47:20, Carl wrote:
According to parser.yy:
In line 3259, a post_event is either:
1) post_event_nofinger, or
2) '-' plus a fingering
In line 3200, a post_event_nofinger is either
1) direction_less_event
2) script_dir plus a music_function
3,4 ) Lyric hyphen or lyric ex
Hi Carl,
nice work.
A general thought:
As far as I understand the code will work automatically. Though, I
foresee some users wanting to switch it off (ofcourse not the majority,
but there is always somebody with different wishes).
Any chance to create an option for it?
Some inline remarks below
Hi Carl,
apart from one nit (see below)
LGTM
Probably not related to this patch:
Clicking "Delta from patch set" gives strange results. No clue what
Rietveld does...
https://codereview.appspot.com/294570043/diff/20001/scm/translation-functions.scm
File scm/translation-functions.scm (right):
On 2018/05/05 23:07:45, Carl wrote:
Remove debug printing
Very nice!
LGTM ofcourse
Thanks!
https://codereview.appspot.com/294570043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
From description and regtest: very nice.
Will it work for below as well?
#(define frac (inexact->exact (/ 3.0 4.0)))
{ r1*/frac }
https://codereview.appspot.com/346810043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/m
Reviewers: ,
Description:
Improve make-bracket-bar-line
The previously used ly:stencil-scale -1 1 resulted in wrongly positioned
SpanBars in certain cases.
Replaces ly:stencil-scale by flip-stencil.
Please review this at https://codereview.appspot.com/339670043/
Affected files (+1, -1 lines):
Reviewers: ,
Description:
Let general-column deal reliable with empty args
Previously an args-list of empty-stencils issued a programming error:
Improbable offset for stencil: -inf staff space
This patch removes empty stencils from the args-list.
If args-list is empty, an empty stencil is retu
Reviewers: ,
Description:
Change highmidtom to himidtom in notation-appendices.itely
Please review this at https://codereview.appspot.com/355740043/
Affected files (+4, -4 lines):
M Documentation/es/notation/notation-appendices.itely
M Documentation/fr/notation/notation-appendices.itely
M
Can't review C++.
But from a little testing:
http://lilypond.1069038.n5.nabble.com/Iterating-music-for-voiceOne-Checking-with-equal-td215135.html#a215158
it works as wished.
A question not directly related to your patch:
https://codereview.appspot.com/363740043/diff/1/lily/prob.cc
File lily/pr
LGTM
https://codereview.appspot.com/345090043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Even without your patch one can do:
part.1,1 = "foo"
part.1,2 = "bar"
part.1,3 = "buzz"
part.2,1 = "xx"
part.2,2 = "yy"
part.2,3 = "zz"
part.3 = "whatever"
#(format #t "\n\"part\" contains:\n~y\n" part)
#(format #t "Example call in guile: \"1\" of \"part\":\n~a" (assoc-get 1
part))
#(format #t
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
https://lists.gnu.org/mailma
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
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 produc
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.
T
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
https://lists.gnu.org/mailman
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
O
LGTM
https://codereview.appspot.com/357840043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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
Documentation/notation/rhythms.itely
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):
https://codereview.appspot.com/353850043/diff/1/Documentation/snippets/new/numbering-single-measure-rests.ly#new
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 ...
https://codereview.appspot.com/
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):
https://code
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 o
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, o
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 (wh
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
lilypond-devel
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):
https://codereview.appspot.com/566540043/
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. Creat
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 ove
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
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 define-co
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 bei
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 f
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 elem
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 yo
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 i
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 i
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 a/scm/define-grob-properties
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
e3ae2147be607304a7d3c449
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
scm/define-markup-commands.sc
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
https://lists.gnu.org/mailman/list
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/
___
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 a/lily/line-spann
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 2019/05/
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 (a
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 201
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
Thanks for review
https://codereview.appspot.com/560670043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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 the
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 https://codereview.appspot.com/562850043
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 https://coderevie
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 #'(off
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" prope
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 \under
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_
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 state
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.
htt
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
lily/measure-a
What about a regtest?
https://codereview.appspot.com/575330043/
From testing with tidy 5.2.0
LGTM
https://codereview.appspot.com/551250043/
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, user-gen
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
(e
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
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:
input/regression/footnote-auto-numbering-ve
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/
Dan, I've set it to needs_work for now.
https://codereview.appspot.com/577180043/
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
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 exam
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 testin
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:
https://lists.g
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/
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
- f
101 - 200 of 455 matches
Mail list logo
