David Kastrup <d...@gnu.org> writes: > Reinhold Kainhofer <reinh...@kainhofer.com> writes: > >> Am Samstag, 8. Mai 2010, um 14:28:18 schrieb Werner LEMBERG: >>> > So how about the ultimate tweak: using a separate engraver? We >>> > can't have overlapping slurs with a single engraver, for example. >> >> Actually, by extending the engraver a little bit it should be >> possible. I have had that on my list for quite some time... > > That's the same for glissandi. But there is not much of a point > extending every engraver a bit and making its code more complex if the > same can be done with a more or less universally working approach for > all spanning engravers.
There are two different issues here to address/kill. Issue 1 is making spanning engravers (or engravers that can do just one job between the start and the end of the moment) work for multiple parallel tasks. Issue 2 is being able to deal with those parallel life times properly: letting programmed tasks and user tasks make sure that the intended instance of an engraver is addressed for a specific task. Some of the lack of enthusiasm for dealing with issue 1 may be explained by the necessity of addressing issue 2. For example, we don't have nested slurs, but then what to make of <c( d( e(> <d) e) f)> This particular one does not want to get a solution in terms of nesting, but likely first in, first out. Unless it doesn't... So the solution would be to use "selectors". A selector basically just sets a sorting criterion, and applies to a single "entity". If we apply it like a \tweak, we'd write: <c( d...@1( e...@2(> <d) e...@1) f...@2)> Syntactically, postfixing might look nicer. <c( d(@1 e(@2> <d) e)@1 f)@2> That's assuming @ as a shorthand. Maybe a case for GLISS, though upwards-compatible. If the syntax is too contentious or the decision should be postponed, \select 1 might be used, which may at first be the same as \tweak #'selector #1. The selector itself would, in input syntax, likely be symbol or number and be compared with eq? or at most eqv?. That makes it reasonably easy to create unique selectors programmatically (like the appoggiatura code creating its own ties internally, currently in conflict with user ties). A selector basically has the effect of routing the translator interface to a separate engraver instance (where supported by the engraver, otherwise it will be ignored). But all without changing the context. Programmatically, I was intending to do something like a template type Engraverfactory<GlissandoEngraver> NewGlissandoEngraver; for definining an Engraver acting on selections. That would make it quite easy to quickly test the concept on various engravers. I am not sure that this is the best permanent solution, however, since it is somewhat lacking in transparency. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
