[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Context paths (and the Edition Engraver)

From: Jan-Peter Voigt
Subject: Re: Context paths (and the Edition Engraver)
Date: Wed, 22 Jan 2020 13:40:40 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

Am 21.01.20 um 18:50 schrieb Dan Eble:
> On Jan 21, 2020, at 11:31, Jan-Peter Voigt <address@hidden> wrote:
>> I'd like that, though it would be a quite invasive change.
>> And if we stay with the string for the context id and then use
>> lists/paths in the \context statement like
>> \new Staff = "choir" << \new Voice = "soprano" …
>> and then use
>> \context Voice = choir.soprano
>> it would be inconsistent with \new <Context> = "…"
>> I will write down some more text about this topic later.
> I see similarities with languages like CSS and XPATH select nodes in a DOM.  
> Notation borrowed directly from them will not integrate well into LilyPond, 
> but it might be fruitful to ask how we could modify expressions like these to 
> fit in.
>     %% find the voice in the example quoted above, very specifically
>     \context Staff#choir > Voice#soprano { … }         % CSS
>     \context Staff[@id=choir]/Voice[@id=soprano] { … } % XPATH
>     %% ditto, but using context type only
>     \context Staff > Voice { … }                       % CSS
>     \context Staff/Voice { … }                         % XPATH
>     %% ditto, but using ID only
>     \context #choir > #soprano { … }                   % CSS
>     \context [@id=choir]/[@id=soprano] { … }           % XPATH
>     %% find the context where the rehearsalMark property is defined
>     \context [rehearsalMark] { … }                     % CSS
>     \context [@rehearsalMark] { … }                    % XPATH
> Dan

I am amazed what kind of discussion is raised on this topic :)

I'd suggest alternative commands to create something like an
XQuery/CSS/whatever functionality. Elsewhere in this thread David (K)
answered to syntax ideas that would break the current model.

To have the possibility to address contexts *like* in CSS has some
appeal. But IMHO it shouldn't disturb the current input scheme. So
alternate commands might help here.
Perhaps *like*:


... or ...

\getContext \thisContext."..".otherContextsName

*don't know if implementing \thisContext is trivial*

The idea that an ID of a context is a list and not a string does attract
me, but I see a major change that has to be done very carefully.

If the ID is a string (or symbol) the path can be easily constructed
with ly:context-parent.
Something like:
\version "2.19.83"

logContextPath = \applyContext
#(lambda (context)
   (define (context-path context)
     (let ((parent (ly:context-parent context)))
       (if (ly:context? parent)
           `(,@(context-path parent) ,(ly:context-id context))
           (list (ly:context-id context)))
   (ly:message "context path: ~A" (context-path context)))

\new Score = "mymusic" {
  \new StaffGroup = "choir" <<
    \new Staff = "soprano" <<
      { c''4 \logContextPath } \\
      { g'4 \logContextPath }

Just some thoughts.

I hope to be able to write some more text about it soon.
But I have another task that will take up a lot of my time in the coming
weeks. You are welcome to ask me questions which I will try to answer.
But I will not be able to be active for the next weeks.


reply via email to

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