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<jp.vo...@gmx.de> 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.
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
