lilypond-devel
[Top][All Lists]
Advanced

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

Re: '-signs in vectors - postulated in LM


From: David Kastrup
Subject: Re: '-signs in vectors - postulated in LM
Date: Tue, 04 Dec 2012 10:14:45 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

"Trevor Daniels" <address@hidden> writes:

> David Kastrup wrote Re: '-signs in vectors - postulated in LM
>
>
>> I just noticed that the file
>> Documentation/learning/tweaks.itely generally talks a lot of nonsense
>> about vectors, calling them a "list preceded by '#", which is rather
>> misleading since at no time they are a list, 
>
> I assume you mean the table in
> http://www.lilypond.org/doc/v2.17/Documentation/learning/types-of-properties
>
> The last line uses 'list' in the usual English sense, not the meaning
> in Scheme.  (I know, because I wrote it.)
>
> I see it could be misleading to anyone who knows Scheme, but those are
> not the intended readers of the Learning Manual.  Perhaps it should be
> changed to 'set', as that was the term used earlier in the table.  Or
> maybe drop that term altogether and write
>
> "Three items separated by spaces, enclosed in parentheses and 
> preceded by hash, #."
>
> Would that correct the "lot of nonsense", or is there more?

I'll go through the section and try proposing something
"programmatically correct", and then we'll take it from there.

>> It very much looks like the author of the sections talking about
>> vectors and/or the reviewers were not really familiar with them.
>
> True; and there was no review procedure when that section was
> written (and no helpful expert either :).  Remember, though, this
> manual is to help people new to LilyPond to write /LilyPond/ code
> with the minimum exposure to the underlying technical details.

Sure.  But in that case, we might be better off not talking about
vectors (specifically vector syntax) at all and instead depend on the
predefined all-invisible etc values.  All eight are defined, after all,
and this saves you from remembering which boolean is responsible in
which situation.

> That said, it must not make any inaccurate or potentially
> misleading statements, so let's get this corrected.

Yes, the main motivation for me is that we should try not to make it
harder to learn more.  And getting more things right than strictly
required for mastering one level of usage is definitely helping with
that.

-- 
David Kastrup



reply via email to

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