Re: Dot-separated list as music function argument
Am 09.07.14 15:15, schrieb David Kastrup: No. If we have some Word in the place of a function argument, LilyPond tries interpreting it as a string first. If the predicate refuses to accept that, the next try is as a one-element symbol list. If that gets accepted, the parser checks whether this symbol list can be extended with .AnotherWord following. If the predicate refuses a symbol list, however, LilyPond tries feeding it a single symbol before giving up. Still, wrapped predicates do not get any special handling by th parser. No predicate at all gets special handling by the parser in music functions any more (as of issue 3618, version 2.17.29). You can wrap them all you want. LilyPond actually calls the predicates (often several times, sometimes on partially parsed input) to make its parsing decisions. thank you, now I understand But then that change has not had a lot of publicity: you'll see that (apart from administrative comments) I have been the only commenter on issue and code review. I see Things are different for markup command arguments: those have not gotten the whole treatment that music/scheme function arguments have. It would be a completely different bag of tricks to do so in markup mode. I thought so. It would be nice, but I would not call it that important. Best, Jan-Peter ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dot-separated list as music function argument
Hi Simon, I also stumbled sometimes ove this behaviour, but I think it is not a real bug. If the parser has a list? predicate, it looks for dot-notation. But if it gets a custom predicate, it will not do so. Am I right, David? IIUC some predefined predicates (list?, string?, ly:duration?, ly:pitch?, ...) are handled in a special way to allow shorter input, but this is not seen by the parser, if they are wrapped in a custom predicate. HTH Jan-Peter Am 08.07.14 13:39, schrieb Simon Albrecht: The 2.18 changes document says that #'(Staff Accidental) and Staff.Accidental were now interchangeable, however if I replace it in the second function call, I get errors (unexpected . etc.). Is there a way to avoid this in the coding of the function or should it be considered a bug? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dot-separated list as music function argument
... o dear ... my mail was delayed one day. But thats not too bad, as the other answers are much more helpful. Still, wrapped predicates do not get any special handling by th parser. Cheers, Jan-Peter On 08.07.2014 13:58, Jan-Peter Voigt wrote: I also stumbled sometimes ove this behaviour, but I think it is not a real bug. If the parser has a list? predicate, it looks for dot-notation. But if it gets a custom predicate, it will not do so. Am I right, David? IIUC some predefined predicates (list?, string?, ly:duration?, ly:pitch?, ...) are handled in a special way to allow shorter input, but this is not seen by the parser, if they are wrapped in a custom predicate. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dot-separated list as music function argument
Jan-Peter Voigt jp.vo...@gmx.de writes: On 08.07.2014 13:58, Jan-Peter Voigt wrote: I also stumbled sometimes ove this behaviour, but I think it is not a real bug. If the parser has a list? predicate, it looks for dot-notation. But if it gets a custom predicate, it will not do so. Am I right, David? No. If we have some Word in the place of a function argument, LilyPond tries interpreting it as a string first. If the predicate refuses to accept that, the next try is as a one-element symbol list. If that gets accepted, the parser checks whether this symbol list can be extended with .AnotherWord following. If the predicate refuses a symbol list, however, LilyPond tries feeding it a single symbol before giving up. IIUC some predefined predicates (list?, string?, ly:duration?, ly:pitch?, ...) are handled in a special way to allow shorter input, but this is not seen by the parser, if they are wrapped in a custom predicate. ... o dear ... my mail was delayed one day. But thats not too bad, as the other answers are much more helpful. Still, wrapped predicates do not get any special handling by th parser. No predicate at all gets special handling by the parser in music functions any more (as of issue 3618, version 2.17.29). You can wrap them all you want. LilyPond actually calls the predicates (often several times, sometimes on partially parsed input) to make its parsing decisions. But then that change has not had a lot of publicity: you'll see that (apart from administrative comments) I have been the only commenter on issue and code review. Things are different for markup command arguments: those have not gotten the whole treatment that music/scheme function arguments have. It would be a completely different bag of tricks to do so in markup mode. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Dot-separated list as music function argument
Hello everybody,
I just wrote a music function to mark grobs as editorial addition by
colouring them grey. See the code and an example:
\version 2.19.8
ed = #(let
((string-or-list?
(lambda (grob)
(or (string? grob)
(list? grob)
(define-music-function
(parser location grob mus)
(string-or-list? ly:music?)
#{ \override $grob . color = #(x11-color 'grey40)
$mus
\revert $grob . color #}
)
)
\relative { \ed NoteHead c' \ed #'(Staff Accidental) { cis dis } es }
%
The 2.18 changes document says that #'(Staff Accidental) and
Staff.Accidental were now interchangeable, however if I replace it in
the second function call, I get errors (unexpected . etc.). Is there a
way to avoid this in the coding of the function or should it be
considered a bug?
Best regards,
Simon
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dot-separated list as music function argument
On Tue, Jul 8, 2014 at 5:39 AM, Simon Albrecht simon.albre...@mail.de
wrote:
Hello everybody,
I just wrote a music function to mark grobs as editorial addition by
colouring them grey. See the code and an example:
\version 2.19.8
ed = #(let
((string-or-list?
(lambda (grob)
(or (string? grob)
(list? grob)
(define-music-function
(parser location grob mus)
(string-or-list? ly:music?)
#{ \override $grob . color = #(x11-color 'grey40)
$mus
\revert $grob . color #}
)
)
\relative { \ed NoteHead c' \ed #'(Staff Accidental) { cis dis } es }
%
The 2.18 changes document says that #'(Staff Accidental) and
Staff.Accidental were now interchangeable, however if I replace it in
the second function call, I get errors (unexpected . etc.). Is
there a way to avoid this in the coding of the function or should it
be considered a bug?
Best regards,
Simon
Simon,
You should be able to use the older syntax for indicating grob
properties:
\override $grob #'color = #(x11-color 'grey40)
$mus
\revert $grob #'color
See if that helps.
-Abraham
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dot-separated list as music function argument
2014-07-08 13:39 GMT+02:00 Simon Albrecht simon.albre...@mail.de:
The 2.18 changes document says that #'(Staff Accidental) and
Staff.Accidental were now interchangeable, however if I replace it in the
second function call, I get errors (unexpected . etc.). Is there a way to
avoid this in the coding of the function or should it be considered a bug?
I think that symbol-list-or-symbol? is what you need:
\version 2.19.8
ed = #(define-music-function (parser location grob mus)
(symbol-list-or-symbol? ly:music?)
#{ \override $grob . color = #(x11-color 'grey40)
$mus
\revert $grob . color #})
\relative { \ed NoteHead c' \ed Staff.Accidental { cis dis } es }
best,
Janek
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dot-separated list as music function argument
2014-07-08 13:39 GMT+02:00 Simon Albrecht simon.albre...@mail.de:
Hello everybody,
I just wrote a music function to mark grobs as editorial addition by
colouring them grey. See the code and an example:
\version 2.19.8
ed = #(let
((string-or-list?
(lambda (grob)
(or (string? grob)
(list? grob)
(define-music-function
(parser location grob mus)
(string-or-list? ly:music?)
#{ \override $grob . color = #(x11-color 'grey40)
$mus
\revert $grob . color #}
)
)
\relative { \ed NoteHead c' \ed #'(Staff Accidental) { cis dis } es }
%
The 2.18 changes document says that #'(Staff Accidental) and
Staff.Accidental were now interchangeable, however if I replace it in the
second function call, I get errors (unexpected . etc.). Is there a way to
avoid this in the coding of the function or should it be considered a bug?
Best regards,
Simon
Hi,
use the predicate symbol-list-or-symbol?
Below a working version, displaying some info as well:
\version 2.19.8
ed =
#(define-music-function (parser location grob mus)
(symbol-list-or-symbol? ly:music?)
;; displaying some info:
(format #t \nI'm the list: \t\t\t~a
My first entry is: \t~a
My next entry is: \t~a
My first entry is a symbol? \t~a
My next entry is a symbol? \t~a
grob
(car grob)
(if (not (null? (cdr grob)))
(cadr grob)
none)
(symbol? (car grob))
(if (not (null? (cdr grob)))
(symbol? (cadr grob))
none found))
(newline)
;; coloring the grob(s)
#{
\override $grob . color = #(x11-color 'grey40)
$mus
\revert $grob . color
#})
\relative { \ed NoteHead c' \ed #'(Staff Accidental) { cis dis } es }
\relative { \ed NoteHead c' \ed Staff.Accidental { cis dis } es }
HTH,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dot-separated list as music function argument
Simon Albrecht simon.albre...@mail.de writes:
Hello everybody,
I just wrote a music function to mark grobs as editorial addition by
colouring them grey. See the code and an example:
\version 2.19.8
ed = #(let
((string-or-list?
(lambda (grob)
(or (string? grob)
(list? grob)
(define-music-function
(parser location grob mus)
(string-or-list? ly:music?)
#{ \override $grob . color = #(x11-color 'grey40)
$mus
\revert $grob . color #}
)
)
See the code is a euphemism. Try telling your mail client not to
reformat stuff.
\relative { \ed NoteHead c' \ed #'(Staff Accidental) { cis dis } es }
The 2.18 changes document says that #'(Staff Accidental) and
Staff.Accidental were now interchangeable, however if I replace it in
the second function call, I get errors (unexpected . etc.). Is there
a way to avoid this in the coding of the function or should it be
considered a bug?
Your predicate string-or-list? accepts a string, so LilyPond does not
look for . or anything else. That's a really bad predicate to use here.
Try symbol-list-or-symbol? instead. That should be pretty close to what
one would expect from override-similar syntax. Probably symbol-list?
alone is fine as well, but it will, of course, not accept #'Accidental
(which is not a symbol list), even though it _will_ accept Accidental
without any quotes.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dot-separated list as music function argument
Janek Warchoł janek.lilyp...@gmail.com writes: 2014-07-08 13:39 GMT+02:00 Simon Albrecht simon.albre...@mail.de: The 2.18 changes document says that #'(Staff Accidental) and Staff.Accidental were now interchangeable, however if I replace it in the second function call, I get errors (unexpected . etc.). Is there a way to avoid this in the coding of the function or should it be considered a bug? I think that symbol-list-or-symbol? is what you need: I'd probably use symbol-list? here. symbol-list-or-symbol? is a bit of a compatibility crutch for functions that previously accepted #'xxx syntax for their arguments, possibly mimicking \override syntax. For newly introduced functions, accepting #'xxx in addition to #'(xxx) does not seem like a necessity. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dot-separated list as music function argument
On Tue, Jul 8, 2014 at 9:48 AM, David Kastrup d...@gnu.org wrote:
Simon Albrecht simon.albre...@mail.de writes:
Hello everybody,
I just wrote a music function to mark grobs as editorial addition by
colouring them grey. See the code and an example:
\version 2.19.8
ed = #(let
((string-or-list?
(lambda (grob)
(or (string? grob)
(list? grob)
(define-music-function
(parser location grob mus)
(string-or-list? ly:music?)
#{ \override $grob . color = #(x11-color 'grey40)
$mus
\revert $grob . color #}
)
)
See the code is a euphemism. Try telling your mail client not to
reformat stuff.
\relative { \ed NoteHead c' \ed #'(Staff Accidental) { cis dis } es
}
The 2.18 changes document says that #'(Staff Accidental) and
Staff.Accidental were now interchangeable, however if I replace it
in
the second function call, I get errors (unexpected . etc.). Is
there
a way to avoid this in the coding of the function or should it be
considered a bug?
Your predicate string-or-list? accepts a string, so LilyPond does not
look for . or anything else. That's a really bad predicate to use
here.
Try symbol-list-or-symbol? instead. That should be pretty close to
what
one would expect from override-similar syntax. Probably symbol-list?
alone is fine as well, but it will, of course, not accept #'Accidental
(which is not a symbol list), even though it _will_ accept Accidental
without any quotes.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Simon,
Disregard my response. After re-reading your initial post and seeing
Janek's and David's responses, I realized that I misunderstood your
question.
Regards,
Abraham
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dot-separated list as music function argument
Thomas Morley thomasmorle...@gmail.com writes: use the predicate symbol-list-or-symbol? Below a working version, displaying some info as well: \version 2.19.8 ed = #(define-music-function (parser location grob mus) (symbol-list-or-symbol? ly:music?) ;; displaying some info: (format #t \nI'm the list: \t\t\t~a My first entry is: \t~a My next entry is: \t~a My first entry is a symbol? \t~a My next entry is a symbol? \t~a grob (car grob) Uh, you should _not_ be using symbol-list-or-symbol? if your code is not prepared to accept a single symbol. In that case, use just symbol-list? as predicate. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dot-separated list as music function argument
Many thanks for the responses, Thomas and David.
And sorry for the messy code layout… I’ll see if I can change that.
Yours, Simon
Am 08.07.2014 15:50, schrieb Thomas Morley:
2014-07-08 13:39 GMT+02:00 Simon Albrecht simon.albre...@mail.de:
Hello everybody,
I just wrote a music function to mark grobs as editorial addition by
colouring them grey. See the code and an example:
\version 2.19.8
ed = #(let
((string-or-list?
(lambda (grob)
(or (string? grob)
(list? grob)
(define-music-function
(parser location grob mus)
(string-or-list? ly:music?)
#{ \override $grob . color = #(x11-color 'grey40)
$mus
\revert $grob . color #}
)
)
\relative { \ed NoteHead c' \ed #'(Staff Accidental) { cis dis } es }
%
The 2.18 changes document says that #'(Staff Accidental) and
Staff.Accidental were now interchangeable, however if I replace it in the
second function call, I get errors (unexpected . etc.). Is there a way to
avoid this in the coding of the function or should it be considered a bug?
Best regards,
Simon
Hi,
use the predicate symbol-list-or-symbol?
Below a working version, displaying some info as well:
\version 2.19.8
ed =
#(define-music-function (parser location grob mus)
(symbol-list-or-symbol? ly:music?)
;; displaying some info:
(format #t \nI'm the list: \t\t\t~a
My first entry is: \t~a
My next entry is: \t~a
My first entry is a symbol? \t~a
My next entry is a symbol? \t~a
grob
(car grob)
(if (not (null? (cdr grob)))
(cadr grob)
none)
(symbol? (car grob))
(if (not (null? (cdr grob)))
(symbol? (cadr grob))
none found))
(newline)
;; coloring the grob(s)
#{
\override $grob . color = #(x11-color 'grey40)
$mus
\revert $grob . color
#})
\relative { \ed NoteHead c' \ed #'(Staff Accidental) { cis dis } es }
\relative { \ed NoteHead c' \ed Staff.Accidental { cis dis } es }
HTH,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
