https://codereview.appspot.com/308430043/diff/1/python/convertrules.py
File python/convertrules.py (right):
https://codereview.appspot.com/308430043/diff/1/python/convertrules.py#newcode3906
python/convertrules.py:3906: @rule ((2, 19, 49), r"""\override ... .id =
"a-string" ->
Any reason we just
On 2016/09/27 10:06:26, dak wrote:
https://codereview.appspot.com/308430043/diff/1/python/convertrules.py
File python/convertrules.py (right):
https://codereview.appspot.com/308430043/diff/1/python/convertrules.py#newcode3906
python/convertrules.py:3906: @rule ((2, 19, 49), r"""\override ...
Am 27.09.2016 um 20:46 schrieb paulwmor...@gmail.com:
> I considered this, but it's simpler for both code and user if all these
> svg output attributes are in the same alist property rather than split
> across two. Currently the id property is not used for anything else, so
> no need to keep it
On 09/27/2016 02:49 PM, Urs Liska wrote:
We will definitely want to have an 'id property to address elements from
elsewhere in a document, be it spanners or be it edition-engraver mods
or similar additions. Maybe in the context of partial recompilation
features IDs may become handy. So it might
Hi all,
It would be nice if LilyPond supported user-defined grob and context
properties, for use in users' code -- in the spirit of practical
software freedom and to further LilyPond's excellent extensibility. It
would also be handy for prototyping code that might end up in LilyPond.
Harm re
Paul writes:
> Hi all,
>
> It would be nice if LilyPond supported user-defined grob and context
> properties, for use in users' code -- in the spirit of practical
> software freedom and to further LilyPond's excellent extensibility. It
> would also be handy for prototyping code that might end up
Patch Set 2: Improve convert rule, keep id property.
https://codereview.appspot.com/308430043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
