lilypond-devel
[Top][All Lists]
Advanced

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

Re: Context paths (and the Edition Engraver)


From: David Kastrup
Subject: Re: Context paths (and the Edition Engraver)
Date: Tue, 21 Jan 2020 22:51:29 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Dan Eble <address@hidden> writes:

> On Jan 21, 2020, at 14:37, David Kastrup <address@hidden> wrote:
>> 
>> StaffGroup = "organ" . Staff = "upper" . Voice . SubVoice = 2
>
> OK.  It would be an understandable growth on the current face of LilyPond. :)
>
> Questions follow, but I'm not asking you to spend time investigating.
>
> Do you think we could achieve making the quotes optional for some
> simple IDs, and making the whitespace optional?
>
>     StaffGroup=organ.Staff=upper.Voice.SubVoice=2

It would all be optional (except in \lyricsmode or \markup) but I am
skeptical that it would make for a great convention.

> In a situation where the user didn't care to constrain the context
> types, do you think could they be omitted, or would we have to invent
> a placeholder?
>
>     =organ.=upper..=2
>     X=organ.X=upper.X.X=2

I don't think that this would be a reasonable syntax.

> Maybe--MAYBE--I'm not yet advocating it, but maybe we could allow some
> ambiguity when there is no equal sign, and define how LilyPond
> resolves it; like if it is a context type then it is used as the
> context type, otherwise it is used as an ID, which would allow things
> like this:
>
>     organ.upper.Voice.2

Picking this apart correctly would require knowing from the layout
definition which identifiers correspond to contexts.  That's nothing you
can do at music function execution time.  So you could check this path
for reasonability only at a rather late point of time.

Really looks too wishywashy to me to constitute a good idea.

>> Does this give us a hook into making \set, \override and/or \tempo a
>> music function in the long run?  Less than sure about that.
>> Particularly \tempo appears rather tricky.
>
> If I ever knew enough about the implementation of those to answer,
> I've forgotten it.

Hardwired in the parser.

-- 
David Kastrup



reply via email to

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