Re: [PATCH] Add `origin-variable` property to music objects assigned to variables

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.

 > 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?

 > 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.

-- 
Aura