Thomas Morley thomasmorle...@gmail.com writes:
2013/9/26 thomasmorle...@gmail.com:
LGTM
https://codereview.appspot.com/13904043/
Let me add:
I started custom-scheme-coding with LilyPond 2.12.3 and found it
_very_ difficult to modify music-arguments those days, whereas
affecting grobs was quite easy.
Well, music objects are typically hierarchical objects whereas grobs
don't contain other grobs (well, apart from some rather fuzzy parent
relations which you usually don't want to touch). So it's natural that
music objects tend to be more complex to manipulate. On the other hand,
that's what a user will want to meddle with first, so it should be as
simple as possible. There's still a lot of potential for that.
Now we have 2.17 and after all your work in this area, modifying music
has become _much_ easier and so it'll continue with this patch.
The sad thing is that this one was pretty low-hanging fruit. I decided
to look for instances of (map ...) instead of (for-each ...) and then
there was some snippet using map that was annoyingly awkwardly coded in
relation to the complexity of what it did.
Simply because the available primitives/APIs worked with different data
representations for no really convincing reason.
I probably should spend a week each month just working _with_ LilyPond
rather than _on_ LilyPond, just so that the right kind of thing is
getting on my nerves enough to make me want to change it.
Simply:
Thanks a lot.
Well, I'd have to thank you even if it only were for the large amount
of work you provide to list readers in order to get LilyPond solve their
problems.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
