[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: \class grob property

From: Urs Liska
Subject: Re: \class grob property
Date: Thu, 17 May 2018 15:52:22 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

Am 17.05.2018 um 15:46 schrieb David Kastrup:
Paul Morris <address@hidden> writes:

On 05/17/2018 09:00 AM, David Kastrup wrote:

Man, I must have slept through this.  "this is already supported in
2.19" is misleading if it's actually only supported _outside_ of 2.19,
namely by chancing upon people in the know in the mailing lists.

The problem with that kind of support is that it's unreliable.  Stuff
might get reimplemented because people cannot find what they are looking
for, and the old code might get removed as bit rot at any point of time.

To actually move it to "supported" state inside of LilyPond, there need
to be regression tests (which also stop bit rot), user-level
documentation and a Changes entry.  That gives a new feature a
reasonable chance of getting tested and consolidated in order to be
useful for more than a single application (often by a single person) in
its region of interest.

Do you feel up to getting that kind of support into LilyPond?
Hi David,  I agree that this deserves to have regression tests,
user-level docs, and a changes entry (to go with its current
documentation in the internals reference).  I'll try to find time to
work on those things in the next weeks.
That would be very appreciated.  Just from the few bits I have read
right now, it appears to me like the purpose, scope, and behavior of
that extension is a whole lot more specific, prescriptive and
predictable in connection with various backends than Urs' proposal.

Not necessarily ;-)
I think the main difference between Paul's and my descriptions is that his basically does *not* talk about use cases and simply describes what is implemented, while I tried to tease out suggestions by giving rather vage descriptions.

However, the examples we've seen from Paul are better than what I had in mind in so far as this property is somewhat generic: it allows the user to generate arbitrary attributes in the XML elements, not only the standardized "id" and "class" ones.

Which does not preclude Urs building some higher-level functionality of
the kind he envisions based on this.

Exactly :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]