Flaming Hakama by Elaine <ela...@flaminghakama.com> writes: >> ---------- Forwarded message ---------- >> From: David Kastrup <d...@gnu.org> >> To: Dan Eble <d...@faithful.be> >> Cc: lilypond-devel@gnu.org >> Bcc: >> Date: Tue, 21 Jan 2020 22:51:29 +0100 >> Subject: Re: Context paths (and the Edition Engraver) >> Dan Eble <d...@faithful.be> writes: >> >> > On Jan 21, 2020, at 14:37, David Kastrup <d...@gnu.org> 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. > > Just chiming in to agree that this syntax is not very clear. > At least, I find it confusing to see what looks like multiple assignments > (use of =) on the same line. > The = in this case is not being used in this case to define something, but > to identify something that presumably already exists. > > > Is there any hope of having syntax like one of the following? > > StaffGroup("organ").Staff("upper").Voice.SubVoice("2") > StaffGroup["organ"].Staff["upper"].Voice.SubVoice["2"]
Not as much "hope" as "horror". This does not fit at all into current LilyPond syntax. I mean, something like "[" = <>[ "(" = <>( { \new Voice[c'8 d' e'] (g' c''2) } is valid code. Not a good idea at all, but stopping the parser from working with it in order to give it a different meaning would cause a whole lot of wreckage. And what LilyPond can reasonably parse in the context of music functions falls into comparatively narrow classes and requires a lot of planning and magic behind the scenes. -- David Kastrup