Re: Allowable values for output-attributes.id

On Sun, 2026-08-23 at 19:52 +0200, David Kastrup wrote:
> Richard Shann <[email protected]> writes:
> 
> > Denemo has a version of Graham Percival's live-score.ily to
> > annotate
> > LilyPond's SVG output with line and column information for each
> > note
> > and rest in a score. With LilyPond version 2.26 this is not working
> > -
> > the SVG output contains <g id=""> instead of the line and column
> > information e.g. <g id="Note-12-10">. In the documentation it says
> > output-attributes.id can be set to symbols - in this case it is set
> > to
> > a procedure expecting a grob argument. It's not clear if that is an
> > acceptable value, but appears to have worked for the last ten
> > years.
> > This is the procedure definition and the override that is used 
> 
> Search turns up issue 4974, supposedly done with a convert-ly rule. 
> Can
> you figure out more of the problem from there?

I confess I found it difficult starting from lilypond.org to find a
place to search for issue 4974, but I did get somewhere with a general
internet search which indicated that it was responsible for changes
long ago (as I understand it, introducing the code to allow setting the
id).
Searching the changes to the svg output code I saw this in 2.24:

(define (start-group-node attributes)
  (define attributes-string
    (string-concatenate
     (map (lambda (item)
            (ly:format " ~a=\"~a\"" (car item) (cdr item)))
          ;; Due to the way nested grob properties work, we may see
duplicate keys.
          (uniqued-alist attributes hashq assq))))
  (string-append "<g" attributes-string ">\n"))

which had changed in 2.26 bu dropping that comment and replacing
(uniqued-alist attributes hashq assq) with just attributes. I'm very
hazy here, but would that mean that if attributes had two entries for
id, one being just "", then that might get used? How would one track
down the thinking that caused that change in the source code?

Richard Shann