Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)

[dak]

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
On 2012/10/13 05:16:00, Keith wrote:


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' }


The mailing list discussion pointed out the inconsistency between the
use of dots between tweaks and overrides.  If tweaking of nested
properties is implemented at some point of time, recognizing the
specification of an optional context when at the same time optional
trailing path components might be available is not really feasible.

Several proposals for changing this have been put forward.  Have to
think about this.

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);
On 2012/10/13 05:16:00, Keith wrote:

I don't see now the new syntax avoids the need for a listener -- is

this

clean-up of unused code ?


The new syntax allows a grob specification _with_ context, allowing to
turn a "time-based" footnote into a proper override instead of an event.
 Since the tweak-like interpretation of the "footnote-music" field was
already in place previously, this works just as well.

The disadvantage is that you have to specify the context in case of
things like Staff.TimeSignature, just like you would have to do with any
override.

The advantage is that this is predictably similar to other operations
and does not require you to juggle the Footnote_engraver between
different contexts in order to have it do its job in difficult
circumstances.

So this change of operation is not forced by the new syntax, but rather
facilitated.

Since there is no longer anything generating footnote music events for
any purpose except sticking it into the footnote-music property of
grobs, using a Music data structure at all for storing the footnote data
is pretty arbitrary.  It might be subject to later cleanup, but I wanted
to keep the changes reasonably confined.

This is probably something that is easier to examine in the scope of its
change as a commit in the dev/syntax branch

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)

[k-ohara5a5a]

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)

[dak]

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,   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)

[Eluze]

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

Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)

[Janek Warchoł]

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,   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)

[dak]

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)

[lemzwerg]

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)

[David Kastrup]

Werner LEMBERG  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)

[Werner LEMBERG]

> \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)

[dak]

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)

[Trevor Daniels]

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)

[dak]

On 2012/10/09 08:14:55, t.daniels_treda.co.uk wrote:

: 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)

[Trevor Daniels]

: 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)

[dak]

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

Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)

[lemzwerg]

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