Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)
I like it.
http://codereview.appspot.com/6635050/diff/15002/Documentation/notation/changing-defaults.itely
File Documentation/notation/changing-defaults.itely (right):
http://codereview.appspot.com/6635050/diff/15002/Documentation/notation/changing-defaults.itely#newcode4202
Documentation/notation/changing-defaults.itely:4202: \tweak
NoteHead.stencil #ly:text-interface::print
The dotted form is very nice.
This way we always have two arguments, each of which can be expanded to
a dotted form to clarify where to find the thing we want LilyPond to
change. This more-regular syntax is easier to remember than optional
arguments.
{ \override Script X-offset = #-0.5
d'-
d'-\tweak X-offset #-0.5 -
\override Staff.Stem X-offset = #0.7
g' \\ b
\tweak Stem.X-offset #0.25 g' }
http://codereview.appspot.com/6635050/diff/15002/lily/footnote-engraver.cc
File lily/footnote-engraver.cc (left):
http://codereview.appspot.com/6635050/diff/15002/lily/footnote-engraver.cc#oldcode49
lily/footnote-engraver.cc:49: IMPLEMENT_TRANSLATOR_LISTENER
(Footnote_engraver, footnote);
I don't see now the new syntax avoids the need for a listener -- is this
clean-up of unused code ?
http://codereview.appspot.com/6635050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)
On 2012/10/09 21:08:47, janek wrote: I'm just skimming the discussion (the patch is big and non-trivial, so i will have problems reviewing it), but i spotted one interesting sentence... On Tue, Oct 9, 2012 at 10:38 AM, mailto:d...@gnu.org wrote: We can get rid of a _lot_ of #' style thingies with this patch series. A!!! So this is the patch i've been waiting for for about 5 years now! :D Well, I uploaded a version of the patch with a heavy-handed conversion rule for demonstration purposes. Now you can probably wait for about 5 years before the patch downloads... http://codereview.appspot.com/6635050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)
Reviewers: lemzwerg, Message: On 2012/10/09 05:04:50, lemzwerg wrote: LGTM, without testing, and without really understanding the change. However, simplifications and generalizations are always a good thing. http://codereview.appspot.com/6635050/diff/1/Documentation/de/notation/pitches.itely File Documentation/de/notation/pitches.itely (right): http://codereview.appspot.com/6635050/diff/1/Documentation/de/notation/pitches.itely#newcode1529 Documentation/de/notation/pitches.itely:1529: \accidentalStyle StaffGroup.voice This looks strange. I don't expect double quotes after a dot. Any better representation possibility? Agreed. _All_ of the following will work: \accidentalStyle StaffGroup.voice \accidentalStyle StaffGroup.voice \accidentalStyle StaffGroup.voice whereas everything involving #Staffgroup... will _not_ work (only LilyPond strings autoconvert to symbols). I think I'd go for \accidentalStyle Staffgroup.piano-cautionary myself as then the temptation to employ Scheme strings by accident is smaller, but then it seems inconsistent to use \accidentalStyle piano-cautionary so I'd crank open another convert-ly rule to turn those into \accidentalStyle piano-cautionary as well. Which makes for worse backward-compatibility of scores. What do people prefer to see? Description: Make arguments like Context.GrobName accessible as symbol lists This is a rather awkward case for a Rietveld review since it consists of 14 separate commits (listed below). The principal target was to allow things like \omit Staff.TimeSignature to work as expected. The same treatment has been given to \alterBroken, \hide, \overrideProperty and \shape, as well as to \accidentalStyle. For improving backward compatibility, dotted _LilyPond_ strings like Staff.TimeSignature are also accepted in lieu of symbol list. A rather surprising corollary is that \override Lyrics.LyricText #'font-shape = #'italic now works without needing to offset . with spaces. While Lyrics.LyricText is indeed run into a single LilyPond string in this case, \override will happily pick that string apart again. LilyPond strings are also acceptable for symbol? predicates. The conversions will only be attempted if the string is not accepted by a predicate in the form of a string. Run scripts/auxiliar/update-with-convert-ly.sh convert-ly rule for \alterbroken, \accidentalStyle, \overrideProperty This is required since not all of the old call forms can be automatically recognized anymore, in particular not when the Scheme-only form #Context.GrobName is being used. Change \accidentalStyle to get a symbol list as argument Make \alterBroken, \hide, \omit, \overrideProperty, \shape take unquoted Context.Grob specs Add symbol-list-or-music? predicate Allow the string xxx.yyy to parse as a symbol list Allow property and grob paths to be constructed from strings Add symbol-list? predicate Allow LilyPond strings to stand in for symbols when parsing Let accidentalStyle detect its optional context argument by looking at its letter case Factor SCM_IDENTIFIER out from embedded_scm_arg* parser.yy: make is_regular_identifier match the lexer definition parser.yy: FRACTION does not require a closed expression before it Assignments can't contain literal lyric music (wrong lexer mode) Please review this at http://codereview.appspot.com/6635050/ Affected files: M Documentation/de/extending/programming-interface.itely M Documentation/de/notation/pitches.itely M Documentation/de/notation/spacing.itely M Documentation/es/extending/programming-interface.itely M Documentation/es/notation/pitches.itely M Documentation/es/notation/spacing.itely M Documentation/extending/programming-interface.itely M Documentation/fr/extending/programming-interface.itely M Documentation/fr/notation/pitches.itely M Documentation/fr/notation/spacing.itely M Documentation/it/notation/pitches.itely M Documentation/ja/notation/pitches.itely M Documentation/ja/notation/spacing.itely M Documentation/notation/pitches.itely M Documentation/notation/spacing.itely M Documentation/snippets/text-headword.ly M input/regression/alignment-vertical-manual-setting.ly M input/regression/alter-broken.ly M input/regression/page-layout-manual-position.ly M input/regression/page-spacing-bass-figures.ly M input/regression/page-spacing.ly M lily/parser.yy M ly/music-functions-init.ly M ly/property-init.ly M python/convertrules.py M scm/c++.scm M scm/lily.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make arguments like Context.GrobName accessible as symbol lists(issue 6635050)
d...@gnu.org: Tuesday, October 09, 2012 8:36 AM On 2012/10/09 05:04:50, lemzwerg wrote: http://codereview.appspot.com/6635050/diff/1/Documentation/de/notation/pitches.itely#newcode1529 Documentation/de/notation/pitches.itely:1529: \accidentalStyle StaffGroup.voice This looks strange. I don't expect double quotes after a dot. Any better representation possibility? Agreed. _All_ of the following will work: \accidentalStyle StaffGroup.voice \accidentalStyle StaffGroup.voice \accidentalStyle StaffGroup.voice whereas everything involving #Staffgroup... will _not_ work (only LilyPond strings autoconvert to symbols). I think I'd go for \accidentalStyle Staffgroup.piano-cautionary myself as then the temptation to employ Scheme strings by accident is smaller, but then it seems inconsistent to use \accidentalStyle piano-cautionary so I'd crank open another convert-ly rule to turn those into \accidentalStyle piano-cautionary as well. Which makes for worse backward-compatibility of scores. What do people prefer to see? As the 2.17 releases appear to be majoring on syntax changes I'd prefer to go for the most intuitive easily-learned syntax rather than backward compatibility. Let's get all the syntax changes incorporated in 2.17, then we can agree an immutable set ready for release 3. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)
On 2012/10/09 08:14:55, t.daniels_treda.co.uk wrote: d...@gnu.org: Tuesday, October 09, 2012 8:36 AM so I'd crank open another convert-ly rule to turn those into \accidentalStyle piano-cautionary as well. Which makes for worse backward-compatibility of scores. What do people prefer to see? As the 2.17 releases appear to be majoring on syntax changes I'd prefer to go for the most intuitive easily-learned syntax rather than backward compatibility. Here is the rub: what we are currently talking about is a choice between several convert-ly rules that all lead to valid programs after this change. Whether you write \override TextSpanner #'(bound-details left stencil-align-dir-y) = #-2 or \override Bottom.TextSpanner #'(bound-details left stencil-align-dir-y) = #-2 or \override #'(Bottom TextSpanner) bound-details.left.stencil-align-dir-y = #-2 it is now all the same to LilyPond. Now it is nice to have found underlying principles making it possible to obliterate fine distinctions and remove the necessity of using Scheme for specifying a grob property path to modify, with mostly cosmetic backward compatibility consequences. But since LilyPond is now able to _read_ a lot of different phrasings of the same material, the question is how we want to be _writing_ this material. I'll likely go for the quoteless \accidentalStyle form generally here. I think I'll prepare a radical convert-ly-only patch on top of this patch series that demonstrates what now valid syntax we _could_ be using/advertising as input if we wanted to. We can get rid of a _lot_ of #' style thingies with this patch series. Let's get all the syntax changes incorporated in 2.17, then we can agree an immutable set ready for release 3. Immutable as we guarantee we will be able to process this rather than we guarantee we will write our scores to have input looking like that? http://codereview.appspot.com/6635050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)
d...@gnu.org: Tuesday, October 09, 2012 9:38 AM Here is the rub: what we are currently talking about is a choice between several convert-ly rules that all lead to valid programs after this change. Whether you write \override TextSpanner #'(bound-details left stencil-align-dir-y) = #-2 or \override Bottom.TextSpanner #'(bound-details left stencil-align-dir-y) = #-2 or \override #'(Bottom TextSpanner) bound-details.left.stencil-align-dir-y = #-2 and presumably even \override Voice.TextSpanner bound-details.left.stencil-align-dir-y = #-2 (which I prefer) it is now all the same to LilyPond. Now it is nice to have found underlying principles making it possible to obliterate fine distinctions and remove the necessity of using Scheme for specifying a grob property path to modify, with mostly cosmetic backward compatibility consequences. But since LilyPond is now able to _read_ a lot of different phrasings of the same material, the question is how we want to be _writing_ this material. Indeed. We need to define a canonical form for the bulk of the manuals, although we should explain the flexibility and available variants once. I'll likely go for the quoteless \accidentalStyle form generally here. Good. I think I'll prepare a radical convert-ly-only patch on top of this patch series that demonstrates what now valid syntax we _could_ be using/advertising as input if we wanted to. It's only right and just that you get first go at suggesting a canonical form, and a patch would be a good way of expressing your preference. (Regexp tutorial, anyone? Although we can always apply the patch and run it on the manuals.) We can get rid of a _lot_ of #' style thingies with this patch series. The more the better. Let's get all the syntax changes incorporated in 2.17, then we can agree an immutable set ready for release 3. Immutable as we guarantee we will be able to process this rather than we guarantee we will write our scores to have input looking like that? I meant the former; the latter would be just an aspiration. As with the documentation, this will need an agreement on the canonical form. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)
On 2012/10/09 10:03:59, t.daniels_treda.co.uk wrote: d...@gnu.org: Tuesday, October 09, 2012 9:38 AM I think I'll prepare a radical convert-ly-only patch on top of this patch series that demonstrates what now valid syntax we _could_ be using/advertising as input if we wanted to. It's only right and just that you get first go at suggesting a canonical form, and a patch would be a good way of expressing your preference. Well, I am a programmer. I know what symbols are and what strings are and can deal with the differences just fine. The main point of such a radical convert-ly-only patch (which is going to convert valid syntax into also valid syntax) is to provide one extreme outlook as a reference point for discussion. The main obstacles will be the need to redocument, to rethink, to reeducate, and to talk with those who have to deal with scores written by others, and with those who teach others about LilyPond. In all of those areas my voice carries less rather than more weight than that of others. Let's get all the syntax changes incorporated in 2.17, then we can agree an immutable set ready for release 3. Immutable as we guarantee we will be able to process this rather than we guarantee we will write our scores to have input looking like that? I meant the former; the latter would be just an aspiration. As with the documentation, this will need an agreement on the canonical form. Perhaps \displayLilyMusic and its underlying primitives at some point of time will need to allow specifying a preferred printing style to use. At least those that use \displayMusic and its ilk for harvesting LilyPond's interpretation of an input file will not be affected. http://codereview.appspot.com/6635050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)
\accidentalStyle StaffGroup.voice This is my preferred form. However, some time ago we decided (more or less) to say e.g. \clef bass In the light of your syntax improvements/simplifications, shouldn't we start to use \clef bass instead, making data in double quotes really user strings only? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)
Werner LEMBERG w...@gnu.org writes: \accidentalStyle StaffGroup.voice This is my preferred form. However, some time ago we decided (more or less) to say e.g. \clef bass In the light of your syntax improvements/simplifications, shouldn't we start to use \clef bass instead, making data in double quotes really user strings only? \clef bass_8 won't work, neither will \clef treble^8, and I see no sensible way to make them work. As long as that is our naming choice, using quotes for clefs is the only way to keep the syntax consistent. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)
LGTM. http://codereview.appspot.com/6635050/diff/7002/ly/music-functions-init.ly File ly/music-functions-init.ly (right): http://codereview.appspot.com/6635050/diff/7002/ly/music-functions-init.ly#newcode105 ly/music-functions-init.ly:105: (ly:input-warning location (_ not a spanner name, `~a') name) Wouldn't `~a' is not a spanner name be more appropriate? http://codereview.appspot.com/6635050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)
http://codereview.appspot.com/6635050/diff/7002/ly/music-functions-init.ly File ly/music-functions-init.ly (right): http://codereview.appspot.com/6635050/diff/7002/ly/music-functions-init.ly#newcode105 ly/music-functions-init.ly:105: (ly:input-warning location (_ not a spanner name, `~a') name) On 2012/10/09 16:44:16, lemzwerg wrote: Wouldn't `~a' is not a spanner name be more appropriate? No idea, I just copied the existing error message. And the corresponding regression test already expects this warning. http://codereview.appspot.com/6635050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)
I'm just skimming the discussion (the patch is big and non-trivial, so i will have problems reviewing it), but i spotted one interesting sentence... On Tue, Oct 9, 2012 at 10:38 AM, d...@gnu.org wrote: We can get rid of a _lot_ of #' style thingies with this patch series. A!!! So this is the patch i've been waiting for for about 5 years now! :D As Trevor said, the more the better. Pity that \clef treble_8 won't work... if you stumble upon an idea for supporting something like this, let us know! best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)
Werner LEMBERG wrote \accidentalStyle StaffGroup.voice This is my preferred form. However, some time ago we decided (more or less) to say e.g. \clef bass In the light of your syntax improvements/simplifications, shouldn't we start to use \clef bass instead, making data in double quotes really user strings only? putting bass in double quotes will disable hiliting the correct way in most editors! Eluze -- View this message in context: http://lilypond.1069038.n5.nabble.com/Make-arguments-like-Context-GrobName-accessible-as-symbol-lists-issue-6635050-tp134433p134518.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)
LGTM, without testing, and without really understanding the change. However, simplifications and generalizations are always a good thing. http://codereview.appspot.com/6635050/diff/1/Documentation/de/notation/pitches.itely File Documentation/de/notation/pitches.itely (right): http://codereview.appspot.com/6635050/diff/1/Documentation/de/notation/pitches.itely#newcode1529 Documentation/de/notation/pitches.itely:1529: \accidentalStyle StaffGroup.voice This looks strange. I don't expect double quotes after a dot. Any better representation possibility? http://codereview.appspot.com/6635050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
