> …it makes it more complicated to add new nesting levels. You’re absolutely right, I hadn’t thought of that.
Thanks for all you do for LilyPond! Cheers, Nate > On Mar 7, 2022, at 5:58 PM, Jean Abou Samra <[email protected]> wrote: > > Le 07/03/2022 à 23:12, Nate Whetsell a écrit : >> Hi all, >> >> I’m quite new to LilyPond development, so please take this well-salted. >> >>> …I am not sure what the reason was for making \tocItem take a symbol list >>> as first argument in the first place instead of a mere level of nesting >>> depth as an integer: >> For what it’s worth, I’m very much in favor of having \tocItem’s first >> argument be a nesting depth instead of a symbol list. >> >> The only thing I can add is that, in some cases, a (signed) integer >> representing a relative level may be more useful than an absolute nesting >> level. Using relative levels, any positive integer would mean the \tocItem >> would become a child of the previous one, and negative integers would >> decrease the nesting depth: >> >> \tocItem "foo" % Level 0 >> \tocItem 1 "bar" % Level 1, nested in foo >> \tocItem 100 "baz" % Nested in bar >> \tocItem "bla" % Also nested in bar >> \tocItem -1 "spam" % Nested in foo >> >> Where I think this would come in handy is creating a big list of bookmarks >> by \include-ing several files that all have their own \tocItems. As long as >> >> \tocItem 1 "foo" >> >> put "foo" at level 0 when it’s the first \tocItem encountered, then >> >> \tocItem "oof" >> \include "file.ly" % this file contains \tocItem 1 "foo" >> >> would result in oof at level 0 with foo as a child at level 1, but one could >> still compile file.ly on its own to get foo at level 0. >> >> (The idea of a relative bookmark level is from LaTeX’s bookmark package: >> https://ctan.org/pkg/bookmark.) > > > > That is an interesting idea, but unfortunately it makes > it more complicated to add new nesting levels. > > \tocItem "score A" > > \score { big expression taking 4 screens to scroll ... } > > \tocItem "score B" > > If I want to refactor A to split the score in two and add > nested TOC entries, I also have to touch B to specify -1 > (or -n) as a relative level. Also it means you can't reorder > the scores without editing them if there are different nesting > levels at play. I think something like this would be nice, > but under a different form, say, > > myToc = \makeToc > \addToToc \myToc \tocItem "foo" > \addToToc \myToc \tocItem 1 "bar" % level is relative to TOC root > myNestedToc = \makeToc > \addToToc \myToc 1 \myNestedToc % nested myNestedToc at level 1 > \addToToc \myNestedToc \tocItem 1 "baz" % relative to myNestedToc root > > or something like that. Problematic is that this requires > a refactoring of \tocItem because it currently works via > a side effect and not by adding an object somewhere, so for > example this produces TOC items in the order of \tocItem calls: > > \version "2.22.1" > > \markuplist \table-of-contents > > foo = \tocItem \markup foo > baz = \tocItem \markup baz > > { > \baz > c'1^"baz" > \pageBreak > \foo > c'1^"foo" > } > > So, well, I think it's a great idea but it requires somewhat > more thought than I can afford right now. > > Jean
