bug-lilypond
[Top][All Lists]
Advanced

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

Re: Issue 1391 in lilypond: Enhancement: warning message when an propert


From: David Kastrup
Subject: Re: Issue 1391 in lilypond: Enhancement: warning message when an property is set in the wrong context
Date: Wed, 10 Nov 2010 12:55:19 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

address@hidden writes:

> Status: Accepted
> Owner: ----
> Labels: Type-Enhancement Priority-Medium Warning
>
> New issue 1391 by v.villenave: Enhancement: warning message when an
> property is set in the wrong context
> http://code.google.com/p/lilypond/issues/detail?id=1391
>
> This feature was suggested by Werner:
> http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00229.html
>
> It would be very helpful to many users that when typing e.g.
>   {
>     ...
>     \override BarLine #'stencil = ##f
>     ...
>   }
>
> instead of (in the appropriate context):
>
>   \override Staff.BarLine #'stencil = ##f
>
> A warning message would be printed, possibly along the lines of
>
>   overriding property `stencil' for grob `BarLine' has no effect in
>   context `Voice'

I would like to state that I consider that a step in the wrong
direction.  If we make Lilypond smart enough to figure out what is
wrong, we should use that smartness for doing the right thing instead of
educating the user.

Lilypond once had subvoices (threads?).  They have been eliminated, as
far as I understand, because they were causing more confusion than good,
and an elemental part of that confusion was that they made it harder to
figure out just what context you wanted to be setting your properties
for.

If we give Lilypond that knowledge, then we should make it pick the
right context itself.

That way, one could, if one wanted, reintroduce subvoice contexts
without changing the meaning of existing valid sources (namely sources
that don't fiddle with non-working properties in the wrong context).

And we _have_ snippets fiddling with typesetting stuff two times, using
transparent parts for each pass, that would work much more elegant with
the equivalent of subvoices.

-- 
David Kastrup




reply via email to

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