Am 07.04.2017 um 10:16 schrieb David Kastrup: > Urs Liska <[email protected]> writes: > >> Hi, >> >> I've done a first implementation of an ID based property override, which >> is sort of a complement to the edition-engraver. It's significantly less >> complex than the edition-engraver, has some advantages over it, but also >> significant limitations. >> >> If you want to have a closer look you may inspect the pull request at >> https://github.com/openlilylib/edition-engraver/pull/14. >> >> What it *can* do is apply any property override that could be achieved >> with \once \override or \tweak to grobs addressed by an ID. This means >> it isn't necessary anymore to bother with finding out when and in which >> context the item is. Simply add an ID to it and address it, and there >> you go, completely robust against changes in context and timing. >> >> However, at least at the moment, it can only affect individual grobs' >> properties, so it's not possible to insert switches like regular >> \override's (only \once) or actual elements like breaks, markups or >> marks etc. > If you use \override Grob.id then all grobs get the id until you revert. > Wouldn't that have the desired effect?
No, then I could directly override the property I'd need. The basic idea *is* to be able to easily address specific grobs (regarding the discussions about the edition-engraver where the addressing by measure and moment is so fragile). So the 'id (or whatever property) should be unique. Of course I'm thinking about a system where you don't intersperse the overrides and tweaks with the content, this is why we're looking into external addressing in the first place. Plus, there's an increasing probability of set-ups where the IDs are auto-generated, for example by an importer. The idea behind that is to obtain objects tagged with an ID from outside and being able to affect them with tweaks and overrides without touching the actual LilyPond input. But of course editing isn't always about changing single grobs and inserting \override ... \revert is of course a natural use case. The edition-engraver can do that, and now we have to discuss the best way to integrate the different approaches in a tool that is as consistent as possible. > Of course, this takes away the > possibility to use id for any other purpose or in multiple commands. So > maybe id is not the best idea to use here. OTOH the natural semantic purpose of an "id" is to uniquely identify an object. So if other use cases are disturbed by such a use (e.g. holding additional information like a JSON object, as was discussed recently) then maybe *these* use-cases should consider using a different property? Urs -- [email protected] https://openlilylib.org http://lilypondblog.org _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
