[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Edge cases in TOC hierarchies
From: |
Nate Whetsell |
Subject: |
Re: Edge cases in TOC hierarchies |
Date: |
Mon, 7 Mar 2022 19:48:23 -0500 |
> …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 <jean@abou-samra.fr> 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