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