lilypond-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]