lilypond-user
[Top][All Lists]
Advanced

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

Re: new and context


From: David Kastrup
Subject: Re: new and context
Date: Fri, 07 Dec 2012 11:27:05 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Noeck <address@hidden> writes:

> Am 07.12.2012 07:43, schrieb David Kastrup:
>> Noeck <address@hidden> writes:
>> 
>>> Staff "var" { a4 }
>>> Staff "var" …    or even (?)   \var …
>> 
>> Staff and "var" are valid lyrics.  Most complex syntactic constructs
>> start with a keyword starting with backslash for that reason, or with
>> special characters.
> I rather meant the necessity of \new and \context, so
> \Staff = "var" { a4 }
> \Staff = "var" …    or even (?)   \var …
>
>>> I think it is always better to make the usage of the software easy,
>>> than having to explain a lot in the documentation why this has to be
>>> done in a complex way (even if it is easy compared to the knowledge of
>>> the developers).
>> 
>> "Easy" is not the same as "arbitrary".  Your proposal is not anything
>> like any other LilyPond construct, so how would a user be able to guess
>> and/or remember it?
> In my opinion, less words for a correct syntax can be easier learnt by
> heart.

You'll find that \Staff is being used in context definitions to refer to
a copy of the existing context definition of Staff.  So it is a normal
variable in that scope and can't at the same time be a reserved word
like \new or \context.  Now if we were actually assigning to a context
definition in that manner, the syntax with the backslash would already
be strange.  But that is not what happens.  Instead, the context
definition "Staff" is used as a blueprint for (possibly) creating a new
context, not changing the context definition "Staff" itself.

> And in case it is possible to let LilyPond/the parser take obvious
> decisions, it would be good to let him do. Then the user would not
> have to deal with it. (If there is a valid use case, where one would
> like to write \new Staff = "var" having already declared a staff named
> "var" then the parser couldn't do that).

The unnamed staffs are more important for differentiating between
"take existing" or not.

>> Well, it is a bit like closing your eyes and running in order to find
>> a better way through the woods than the existing one which one
>> considers too winded.  Yes, a small chance, but it is somewhat
>> optimistic to assume that one will get through and that the original
>> pathmakers were just too stupid to see the simpler way.
>> 
>
> :) That was a good description – I will be a bit more quiet with such
> “ideas”.

Nothing wrong with asking.  And it is not like there aren't occasions
where there are valid technical reasons, and still after the developers
can't stand to hear repeated suggestions, they overcome them.

But in this case, the proposal is not really fitted well enough with the
rest of LilyPond to trigger the "a shame that this is not possible in
exactly _this_ way, it makes so much more sense" sensors.

-- 
David Kastrup




reply via email to

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