Re: [PATCH] Add `origin-variable` property to music objects assigned to variables
David Kastrup <[email protected]> Mon, 29 Jun 2026 13:44:23 +0200
| Newsgroups | gmane.comp.gnu.lilypond.devel |
|---|---|
| Organization | Organization?!? |
| Message-ID | <[email protected]> |
Aura Kelloniemi <[email protected]> writes: > Hi, > > On 2026-06-28 at 15:58 +0200, David Kastrup <[email protected]> wrote: > > That patch is a really, really, really bad idea since you put your > > property on the _original_ expression that may see other uses. > > Thank you for feedback. I also considered that possibility, but my limitited > testing did not cause problems. I tried: > > vo = \voiceOne > > and after that \vo and \voiceOne still produced different trees. Because in this case \voiceOne already is a copy. In general, LilyPond provides equivalence between #(define xxx ...) and xxx = #... After your change, something like vo = #voiceOne would impact \voiceOne . > > If you wanted to do this responsibly, you'd have to create a copy > > on assignment (defeating the savings from LilyPond's copy-on-use > > contract) or put your property on when _referencing_ a variable. > > You can see how this is done by looking at what happens with the > > 'origin data field when referencing a variable. That is when a > > copy is initiated anyway, and you could tamper with that copy. > > If I manage to implement that, would you think that be eligible for > inclusion in LilyPond? Unlikely. It would come with a permanent cost and no application. > > I am not sure that is really necessary: you could probably in your > > analysis evaluate whether 'origin refers to an input location only > > referencing a variable. > > That is a lot of checking. For each music expression, I'd need to: > > 1) Check if the file is cached in memory. If not, read it into cache. > 2) See if the corresponding point contains a backslash and something that is a > variable name. > > I'm not even sure if this is enough. > > But of course this feature is not necessary for LilyPond's core > operation, and thus I very much understand, if it is considered a > misfeature. It is not a "misfeature" but it comes at non-zero cost even when it is not being used. We have things like profiling/statistics that can be turned on and off and don't incur a cost when not being used. -- David Kastrup