Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[Torsten Hämmerle]

Joram Berger wrote
> Will it also look good for custom key signatures?

Hi Joram,

Well, in your example, there will be no difference between the old and new
coding:

The first two naturals with full overlap get a maximum extra padding of 0.3,
the second and third naturals are (vertically) so far apart that there will
be no extra padding at all.

In general, the algorithm can cope with custom key signatures as it compares
the individual vertical distance between neighbouring naturals and decides
whether to add extra padding (and how much) or not.

The following illustration (linked from issue #5312) compares the old and
new algorithm.


 

Even if not all constellations that may occur in custom key signatures are
directly shown, you can see that the algorithm (checking if the intervals
marked in green touch, overlap or don't overlap) generally will work for any
interval and thus for any custom key signature.

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[Joram]

Will it also look good for custom key signatures?

\relative {
  \set Staff.keyAlterations = #`((6 . ,FLAT)
 (5 . ,FLAT)
 (3 . ,SHARP))
  c'4 d e fis
  aes4 bes c2
  \key c \major
  c
}

Best,
Joram

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[torsten . haemmerle]

On 2018/04/24 21:49:37, Carl wrote:

On 2018/04/24 18:43:45, Be-3 wrote:



> The intervals are just *approximating* the outlines of a run-of-the

mill

> natural glyph. I even played around with the concept using squared

paper.

> This approach more or less relies on the fact that the

square/parallelogram

> part of a natural glyph will be one stave-space high independent of

the font

> used, just like a notehead in *any* font will be one stave-space

high.


So it's a reasonable approximation that the box part of the natural

will extend

about 3/4 staff spaces above the staff position of the natural, and

the

descender
will  descend about 1.5 staff spaces below.



Seems like a reasonable estimate to me, even if it's not exact for a

particular

font.
You can't get too far away from that and still fit in a staff.



Thanks,



Carl


Agreed, Carl,

And, IMHO, there is no need for exaggerated exactness: as soon as two
corners get too close (no matter how close exactly), we need a wee bit
of extra padding.
The main reason for the 3/4 staff spaces, to be honest, was that the two

intervals will be just touching (with intersection length 0) for the
corner-to-corner constellation.

All the best,
Torsten

https://codereview.appspot.com/343020043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[Carl . D . Sorensen]

On 2018/04/24 18:43:45, Be-3 wrote:


The intervals are just *approximating* the outlines of a run-of-the

mill

natural glyph. I even played around with the concept using squared

paper.

This approach more or less relies on the fact that the

square/parallelogram

part of a natural glyph will be one stave-space high independent of

the font

used, just like a notehead in *any* font will be one stave-space high.


So it's a reasonable approximation that the box part of the natural will
extend
about 3/4 staff spaces above the staff position of the natural, and the
descender
will  descend about 1.5 staff spaces below.

Seems like a reasonable estimate to me, even if it's not exact for a
particular font.
You can't get too far away from that and still fit in a staff.

Thanks,

Carl


https://codereview.appspot.com/343020043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: parser.yy / grammar

[Knut Petersen]

Am 24.04.2018 um 21:16 schrieb David Kastrup:




\version "2.21.0"

\score{ { c'2 } \addlyrics  { Hi there }   \layout {}}
\score{ { c'2 } \addlyrics   \displayLilyMusic  { Hi there }   \layout {}}
\score{ { c'2 } \addlyrics { \displayLilyMusic  { Hi there } } \layout {}}
\score{ { c'2 2   } \addlyrics  { Hi there }   \layout {}}
\score{ { c'2 2   } \addlyrics   \displayLilyMusic  { Hi there }   \layout {}}
\score{ { c'2 2   } \addlyrics { \displayLilyMusic  { Hi there } } \layout {}}
\score{ { c'2 2 2 } \addlyrics  { Hi there }   \layout {}}
\score{ { c'2 2 2 } \addlyrics   \displayLilyMusic  { Hi there }   \layout {}}
\score{ { c'2 2 2 } \addlyrics { \displayLilyMusic  { Hi there } } \layout {}}

Uh what?  How is the output correct?



One, two, or three notes, lyrics as expected. See attached pdfs.

To make things clear:

 * \displayLilyMusic is  a music function, it never is acceptable to \addlyrics 
in the current version of lilypond
 * { \displayLilyMusic ... }  is always acceptable because it is a 
grouped_music_list (but the current parser does not automatically force lyric 
state)

Some more examples:

Correct syntax for both original and patched versions:

   \score{ { c'2 2 2 } \addlyrics    { Hi there }   
\layout {}}
   \score{ { c'2 2 2 } \addlyrics {   \lyricmode { Hi there } } 
\layout {}}
   \score{ { c'2 2 2 } \addlyrics { \displayLilyMusic { Hi there } } \layout {}}
   \score{ { c'2 2 2 } \addlyrics { \displayLilyMusic \lyricmode { Hi there } } 
\layout {}}

Bad syntax for old version (bad output), correct syntax for patched version:

   \score{ { c'2 2 2 } \addlyrics   \displayLilyMusic \lyricmode { Hi there }   
\layout {}}

Bad syntax for both versions (bad output for the original version, good output 
for the patched version):

   \score{ { c'2 2 2 } \addlyrics \displayLilyMusic    { Hi there }   
\layout {}}

Attached is a 2nd version of the patch. With that extended version _all_ 
examples above
 compile without warnings/errors and give the desired result.

Knut


ptest.patched.pdf
Description: Adobe PDF document


ptest.orig.pdf
Description: Adobe PDF document
>From 7d6fc17cdfd765bea8491d9df12d09f472c8215d Mon Sep 17 00:00:00 2001
From: Knut Petersen 
Date: Tue, 24 Apr 2018 12:14:03 +0200
Subject: [PATCH] lyric_mode_music: allow music_function_call

Version 2: also push/pop lyric state to allow easier
handling of \displayLilyMusic

Signed-off-by: Knut Petersen 
---
 lily/parser.yy | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/lily/parser.yy b/lily/parser.yy
index 6422f5586b..b127641c41 100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -2624,6 +2624,13 @@ lyric_mode_music:
 		parser->lexer_->pop_state ();
 		$$ = $2;
 	}
+	| {
+		parser->lexer_->push_lyric_state ();
+	} music_function_call
+	{
+		parser->lexer_->pop_state ();
+		$$ = $2;
+	}
 	| MUSIC_IDENTIFIER
 	;
 
-- 
2.16.3

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: parser.yy / grammar

[David Kastrup]

Knut Petersen  writes:

> Hi David!
>> \addlyrics \displayLilyMusic { Hi there! }
>>
>> would not work with your proposed patch while
>>
>> \addlyrics { Hi there! }
>>
>> does.  There is no conceivable reason for the user why this should be
>> so.
>
> Really? \displayLilyMusic after \addlyrics breaks the syntax rules.
> So let's have a look at the attached lilypond source file.
>
> An original unpatched lilypond 2.21 manages to produce a pdf.
> There are error messages for scores 2, 5, 8 and 9.
> The output for score 1 is correct.
> The output for all other scores is incorrect (on ore two notes are missing)
>
> The same lilypond + patch also manages to produce a pdf.
> There are error messages for scores 2, 5 and 8.
> The output for all scores is correct.
>
> Knut
>
> \version "2.21.0"
>
> \score{ { c'2 } \addlyrics  { Hi there }   \layout {}}
> \score{ { c'2 } \addlyrics   \displayLilyMusic  { Hi there }   \layout {}}
> \score{ { c'2 } \addlyrics { \displayLilyMusic  { Hi there } } \layout {}}
> \score{ { c'2 2   } \addlyrics  { Hi there }   \layout {}}
> \score{ { c'2 2   } \addlyrics   \displayLilyMusic  { Hi there }   \layout {}}
> \score{ { c'2 2   } \addlyrics { \displayLilyMusic  { Hi there } } \layout {}}
> \score{ { c'2 2 2 } \addlyrics  { Hi there }   \layout {}}
> \score{ { c'2 2 2 } \addlyrics   \displayLilyMusic  { Hi there }   \layout {}}
> \score{ { c'2 2 2 } \addlyrics { \displayLilyMusic  { Hi there } } \layout {}}

Uh what?  How is the output correct?

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[torsten . haemmerle]

On 2018/04/24 17:59:31, Carl wrote:

LGTM.  I am just a *little* bit concerned about having the dimensions

of the

Emmentaler natural glyph hardcoded in the source, but we already have

magic

numbers reflecting the characteristics of the Emmentaler glyphs.



Maybe it would be good to put a FIXME in recognizing this fact.  Or

maybe we

just go as-is.


Hi Carl,

The intervals are just *approximating* the outlines of a run-of-the mill
natural glyph. I even played around with the concept using squared
paper.
This approach more or less relies on the fact that the
square/parallelogram
part of a natural glyph will be one stave-space high independent of the
font
used, just like a notehead in *any* font will be one stave-space high.

Therefore, it will also work for Gonville, Bravura, all of Abraham's
fonts...
Funny enough, it works for the LilyJAZZ font, too, because even in this
pseudo
handwritten font the square/parallelogram part has the same (standard)
height.

All the best,
Torsten

https://codereview.appspot.com/343020043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[Carl . D . Sorensen]

LGTM.  I am just a *little* bit concerned about having the dimensions of
the Emmentaler natural glyph hardcoded in the source, but we already
have magic numbers reflecting the characteristics of the Emmentaler
glyphs.

Maybe it would be good to put a FIXME in recognizing this fact.  Or
maybe we just go as-is.


https://codereview.appspot.com/343020043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

[torsten . haemmerle]

Reviewers: ,

Message:
Please review...

Thanks,
Torsten

PS: no new regression test needed, there are loads of key cancellations
in the existing regression tests.

Description:
issue 5312: Key cancellation glyph position inconsistent

file lily/key-signature-interface.cc

Using two intervals representing the "vertical skylines" of two
adjacent natural glyphs. This makes a better model of the actual
glyph shape than the original single point within an inverval.
Now we can distiguish between all three cases:
(1) no overlap -> no additional kerning needed
(2) just touching (overlap, but intesection length 0) -> kerning 0.15
(3) overlapping -> kerning 0.3

Case (2) is the new one that couldn't be handled before:
Just touching at the corners made the glyphs cling together.

Basically same  interval technique as before, but I
renamed the Slices from
  pos and overlap_pos
to
  ht_right and last_ht_left.
Using quarter stave-spaces as to get a better (integer) resolution.

Please review this at https://codereview.appspot.com/343020043/

Affected files (+20, -8 lines):
  M Documentation/changes.tely
  M lily/key-signature-interface.cc


Index: Documentation/changes.tely
diff --git a/Documentation/changes.tely b/Documentation/changes.tely
index  
96748ad84dd8f2d91ae058f6545d1697c793b9c9..defcd4f1daabe11cc5855497e51137290de6297e  
100644

--- a/Documentation/changes.tely
+++ b/Documentation/changes.tely
@@ -62,6 +62,16 @@ which scares away people.
 @end ignore

 @item
+Slight padding added between natural glyphs just touching at the corners
+in key cancellations.
+@lilypond[verbatim,quote]
+{
+  \omit Staff.TimeSignature
+  \key ces \major s1 \key c \major s
+}
+@end lilypond
+
+@item
 Two new ornaments have been added.
 @lilypond[verbatim,quote]
 {
Index: lily/key-signature-interface.cc
diff --git a/lily/key-signature-interface.cc  
b/lily/key-signature-interface.cc
index  
79e2bd99482d25b8e5eb1fb10e9fb1ce2255cae7..0c4180d194a283799ff62398be04a2dda2893377  
100644

--- a/lily/key-signature-interface.cc
+++ b/lily/key-signature-interface.cc
@@ -58,7 +58,7 @@ Key_signature_interface::print (SCM smob)
 the cancellation signature.
   */

-  Slice pos, overlapping_pos;
+  Slice ht_right, last_ht_left; /* ht intervals for natural glyph kerning  
*/

   SCM last_glyph_name = SCM_BOOL_F;
   SCM padding_pairs = me->get_property ("padding-pairs");

@@ -87,14 +87,15 @@ Key_signature_interface::print (SCM smob)
 me->warning (_ ("alteration not found"));
   else
 {
-  pos.set_empty ();
+  ht_right.set_empty ();
   Stencil column;
   for (SCM pos_list =  
Lily::key_signature_interface_alteration_positions

  (scm_car (s), c0s, smob);
scm_is_pair (pos_list); pos_list = scm_cdr (pos_list))
 {
   int p = scm_to_int (scm_car (pos_list));
-  pos.add_point (p);
+  ht_right.add_point (2*p - 6);  /* descender */
+  ht_right.add_point (2*p + 3);  /* upper right corner */
   column.add_stencil (acc.translated (Offset (0, p * inter)));
 }
   /*
@@ -108,14 +109,15 @@ Key_signature_interface::print (SCM smob)
   padding_pairs);
   if (scm_is_pair (handle))
 padding = robust_scm2double (scm_cdr (handle), 0.0);
-  else if (glyph_name == "accidentals.natural"
-   && !intersection (overlapping_pos, pos).is_empty ())
-padding += 0.3;
+  else if (glyph_name == "accidentals.natural")
+if (!intersection (ht_right, last_ht_left).is_empty ())
+  padding += (intersection (ht_right, last_ht_left).length ()
+  ? 0.3 /* edges overlap */
+  : 0.15);  /* just touching at the corners */

   mol.add_at_edge (X_AXIS, LEFT, column, padding);

-  pos.widen (4);
-  overlapping_pos = pos + 2;
+  last_ht_left = ht_right + 3;  /* shift up (change to left side)  
*/

   last_glyph_name = glyph_name_scm;
 }
 }



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: parser.yy / grammar

[Knut Petersen]

Hi David!

\addlyrics \displayLilyMusic { Hi there! }

would not work with your proposed patch while

\addlyrics { Hi there! }

does.  There is no conceivable reason for the user why this should be
so.


Really? \displayLilyMusic after \addlyrics breaks the syntax rules.
So let's have a look at the attached lilypond source file.

An original unpatched lilypond 2.21 manages to produce a pdf.
There are error messages for scores 2, 5, 8 and 9.
The output for score 1 is correct.
The output for all other scores is incorrect (on ore two notes are missing)

The same lilypond + patch also manages to produce a pdf.
There are error messages for scores 2, 5 and 8.
The output for all scores is correct.

Knut
\version "2.21.0"

\score{ { c'2 } \addlyrics  { Hi there }   \layout {}}
\score{ { c'2 } \addlyrics   \displayLilyMusic  { Hi there }   \layout {}}
\score{ { c'2 } \addlyrics { \displayLilyMusic  { Hi there } } \layout {}}
\score{ { c'2 2   } \addlyrics  { Hi there }   \layout {}}
\score{ { c'2 2   } \addlyrics   \displayLilyMusic  { Hi there }   \layout {}}
\score{ { c'2 2   } \addlyrics { \displayLilyMusic  { Hi there } } \layout {}}
\score{ { c'2 2 2 } \addlyrics  { Hi there }   \layout {}}
\score{ { c'2 2 2 } \addlyrics   \displayLilyMusic  { Hi there }   \layout {}}
\score{ { c'2 2 2 } \addlyrics { \displayLilyMusic  { Hi there } } \layout {}}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: parser.yy / grammar

[David Kastrup]

Knut Petersen  writes:

> Am 24.04.2018 um 13:46 schrieb David Kastrup:
>>
>> parser.yy is actually quite explicit here:
>>
>> // We must not have lookahead tokens parsed in lyric mode.  In order
>> // to save confusion, we take almost the same set as permitted with
>> // \lyricmode and/or \lyrics.  However, music identifiers are also
>> // allowed, and they obviously do not require switching into lyrics
>> // mode for parsing.
>>
>> lyric_mode_music:
>>  {
>>  parser->lexer_->push_lyric_state ();
>>  } grouped_music_list
>>  {
>>  parser->lexer_->pop_state ();
>>  $$ = $2;
>>  }
>>  | MUSIC_IDENTIFIER
>>  ;
>>
>> It's not like LilyPond is overdocumented.  When there is an explicit
>> comment, chances are that it's sort-of relevant.
>
> I read that comment. But nevertheless I do not see how a music
> function could disturb anything at that point.

\addlyrics \displayLilyMusic { Hi there! }

would not work with your proposed patch while

\addlyrics { Hi there! }

does.  There is no conceivable reason for the user why this should be
so.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: parser.yy / grammar

[Knut Petersen]

Am 24.04.2018 um 13:46 schrieb David Kastrup:


parser.yy is actually quite explicit here:

// We must not have lookahead tokens parsed in lyric mode.  In order
// to save confusion, we take almost the same set as permitted with
// \lyricmode and/or \lyrics.  However, music identifiers are also
// allowed, and they obviously do not require switching into lyrics
// mode for parsing.

lyric_mode_music:
{
parser->lexer_->push_lyric_state ();
} grouped_music_list
{
parser->lexer_->pop_state ();
$$ = $2;
}
| MUSIC_IDENTIFIER
;

It's not like LilyPond is overdocumented.  When there is an explicit
comment, chances are that it's sort-of relevant.


I read that comment. But nevertheless I do not see how a music
function could disturb anything at that point.

Usage example attached ...

Knut
\version "2.21.0"

myscore = #(define-scheme-function () () 
   (ly:parser-include-string #{
"\score {\music \addlyrics { \words }  \layout {}}" #}))
%  ||
% I'd like to get rid of those curly brackets
%
% At some places the lilypond gammar does not allow to
% use a MUSIC_FUNCTION instead of a MUSIC_IDENTIFIER or a
% grouped_music_list. The solution is to use "{ \name }"
% instead of "\name" in those cases. 


% If you use
%
%name = some_music_or_lyrics
%
% name is given the meaning that some_music_or_lyrics has at
% the time of the definition.
%
% If you use
%
%   \macro "name = some_music_or_lyrics"
%
% instead, name is defined to be a music function with the
% meaning of some_music_or_lyrics at the time of its usage.


macro = #(define-scheme-function (arg) (string?)
   (let* (
   (index (string-index arg #\=))
   (left (string-take arg index))
   (right (string-drop arg (+ 1 index
   (ly:parser-include-string  (string-append
   left " = #(define-music-function () () #{ " right  " #})" 

musA = \relative { c'4 e d f g2 }
musB = \relative { g'4 g a b c2 }
musC = \relative { g'4 g f d c2 }
musD = \relative { a'4 a a b c1 \bar "|." }

lyrA = \lyricmode { A B C D E }
lyrB = \lyricmode { F G H I J }
lyrC = \lyricmode { f g h i j }
lyrD = \lyricmode { V W X Y Z }

\macro "music = \musA \musB \musD"
\macro "words = \lyrA \lyrB \lyrD"
\myscore

musB = \musC
lyrB = \lyrC
\myscore

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: parser.yy / grammar

[David Kastrup]

Knut Petersen  writes:

> Hi everybody!
>
> Is there a reason not to allow MUSIC_FUNCTIONs whenever
> MUSIC_IDENTIFIERs are allowed?

Yes.

> One example is \addlyrics. It only accepts grouped_music_lists and
> MUSIC_IDENTIFIERs ...

Intentionally so.  \addlyrics is a mode-changing command and it has to
change back afterwards.

parser.yy is actually quite explicit here:

// We must not have lookahead tokens parsed in lyric mode.  In order
// to save confusion, we take almost the same set as permitted with
// \lyricmode and/or \lyrics.  However, music identifiers are also
// allowed, and they obviously do not require switching into lyrics
// mode for parsing.

lyric_mode_music:
{
parser->lexer_->push_lyric_state ();
} grouped_music_list
{
parser->lexer_->pop_state ();
$$ = $2;
}
| MUSIC_IDENTIFIER
;

It's not like LilyPond is overdocumented.  When there is an explicit
comment, chances are that it's sort-of relevant.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: \unfoldRepeats type none

[David Kastrup]

Knut Petersen  writes:

> Am 23.04.2018 um 14:21 schrieb David Kastrup:
>>
>> Huh.  I'd rather have #f stand for the default, and '() for none.  That
>> seems like a saner interface since an empty list carries obvious
>> meaning.
>>
>> Not backwards-compatible but I think this one has not been released in a
>> stable release yet.
>>
>
> But it has been part of the development tree for about 16 months
> ... If we would also have the type "none" and maybe "all", nobody
> would care about the meaning of '().

If you arrive at '() by constructed means rather than an explicit
constant, that won't help.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

PATCHES - Countdown for April 24th

[James Lowe]

Hello,

Here is the current patch countdown list. The next countdown will be on April 
27th.

A quick synopsis of all patches currently in the review process can be found 
here:

http://philholmes.net/lilypond/allura/



Push:

5308 Context code maintenance - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/5308
http://codereview.appspot.com/346730043

Countdown:

5311 Refine make-tie-stencil - Thomas Morley
https://sourceforge.net/p/testlilyissues/issues/5311
http://codereview.appspot.com/342030043

5309 Refactor Context::get_score_context () - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/5309
http://codereview.appspot.com/346750043

5307 Skyline Refinements (Rounded Boxes and Rotated Ellipses) - be-3
https://sourceforge.net/p/testlilyissues/issues/5307
http://codereview.appspot.com/341140043


Review: No patches in Review at this time.

New: No patches to push at this time.


Regards

James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: parser.yy / grammar

[Knut Petersen]

Is there a reason not to allow MUSIC_FUNCTIONs whenever MUSIC_IDENTIFIERs are 
allowed?
One example is \addlyrics. It only accepts grouped_music_lists and MUSIC_IDENTIFIERs ... 


I think this patch would be enough ...

Knut
>From bd9ac344b02eb908d9536e3679050e0b7eca3ab9 Mon Sep 17 00:00:00 2001
From: Knut Petersen 
Date: Tue, 24 Apr 2018 12:14:03 +0200
Subject: [PATCH] lyric_mode_music: allow music_function_call

Signed-off-by: Knut Petersen 
---
 lily/parser.yy | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lily/parser.yy b/lily/parser.yy
index 6422f5586b..8bea159b3f 100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -2625,6 +2625,7 @@ lyric_mode_music:
 		$$ = $2;
 	}
 	| MUSIC_IDENTIFIER
+	| music_function_call
 	;
 
 mode_changed_music:
-- 
2.16.3

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

parser.yy / grammar

[Knut Petersen]

Hi everybody!

Is there a reason not to allow MUSIC_FUNCTIONs whenever MUSIC_IDENTIFIERs are 
allowed?
One example is \addlyrics. It only accepts grouped_music_lists and 
MUSIC_IDENTIFIERs ...

Knut

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: \unfoldRepeats type none

[Knut Petersen]

Am 23.04.2018 um 14:21 schrieb David Kastrup:


Huh.  I'd rather have #f stand for the default, and '() for none.  That
seems like a saner interface since an empty list carries obvious
meaning.

Not backwards-compatible but I think this one has not been released in a
stable release yet.



But it has been part of the development tree for about 16 months ... If we would also have the type 
"none" and maybe "all", nobody would care about the meaning of '().

Knut



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel