Re: duration and pitch in a function

[Jan-Peter Voigt]

Hello David,
thank you for this detailed answer!
Well, I don't agree in doing an awkward thing, using 2.14. But I 
probably should not name shortcuts extensions.
When I am working on a collection of pieces to be printed, I am using 
current *stable* version. While I'm working on them, I sometimes have to 
repeat a special override or markup. So I create a little music-function 
or markup-command to save typing. And sometimes those little shortcuts 
grow to be an extension I use day by day. I still use the current 
*stable* version - if there is a wrong note, I still want to be able to 
correct that and compile the file three months later without 
lilypond-version-issues.
But you are absolutely right, saying that creating or developing new 
features should be done in a development environment. And the changes 
you named are again great improvements of the sharp knife lilypond!
I just downloaded 2.15.21, to see what happens with my work and what 
needs to be done for that.
...
There are a couple of things to be done manually. This is not a problem, 
but I prefer doing that once for a stable release on all my important 
files.
And I still want to use my recent shortcuts/macros/whatever-you-call-them.

But I am going to take care of this version question, when I am 
answering on the list. Your hint with the ly:duration?-argument is 
important.
@Paolo: you should use current devel-version and look at the docs for 
that. There are a lot improvements in creating music-functions for your 
purpose.

I sometimes did a user-devel-mashup ... I shouldn't disturb development 
with issues of the stable version. Sorry for that, list-members!

Cheers,
Jan-Peter

Am 11.12.2011 11:38, schrieb David Kastrup:
> Jan-Peter Voigt<address@hidden>  writes:
>
> > Thanks for that hint! I will keep that in mind for future development.
> > I actually use 2.14 for my allday work and create my extensions
> > according to that syntax, because I want to be able to produce sheets
> > day by day without stumbling over suprisingly upcoming changes.
> > I know, I should have a devel (2.15 ... 2.17 ...) on my machine to be
> > prepared for the next release.
> > Paolo's excercise would be solved differently by me: I would use a
> > ly:music? argument and copy and augment that. And I hope, ly:music?
> > arguments will not be broken in future releases ;-)
> They will.  My preferred newspeak for that is "they will be unbroken",
> namely become much more consistent and versatile.  But that means that
> there _will_ be changes in semantics for cases that are quite cumbersome
> to do currently.
>
> I manage to get my syntax changes through with very little collateral
> damage, and convert-ly covers by far the largest portion of it.  I don't
> do disruptive changes without good reason, and not without convert-ly
> rules where applicable, and as a rule, none of them gets backed out
> again once it is in.  So there are no "surprisingly upcoming changes"
> that you can avoid in the long run by sticking with 2.14, and there is
> very little backpedaling in development.
>
> There has been quite a bit of heat spent on the developer lists to
> arrive at semi-automatic procedures that make reasonably sure that the
> current development master is kept in working state.
>
> I can take credit for that only so far as those procedures were partly
> created to withstand the strain from my flow of patches (and
> particularly the strain from my accompanying abuse when it got
> disrupted).  But the results naturally made it easier for everyone to
> contribute exciting and numerous improvements while minimizing
> disturbances on the development versions' quality.
>
> Personally I would not "create my extensions according to 2.14 syntax"
> because that is so awkward.
>
> If you do
>
> git diff release/2.14.2-1..origin lily/lily-lexer.cc
>
> you'll notice that \grobdescriptions, \key, \mark, \once, \partial,
> \relative, \skip, \time, \times, \transpose all have disappeared from
> the lexer.
>
> All of those are now music functions instead of being hardwired in the
> syntax.  And that means that your own personal extensions could also
> provide comparable functionality with comparable syntax.