lilypond-devel
[Top][All Lists]
Advanced

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

Re: Adds dimension stencil command to correct with-dimension (issue 1295


From: Mike Solomon
Subject: Re: Adds dimension stencil command to correct with-dimension (issue 12957047)
Date: Mon, 26 Aug 2013 09:42:27 +0300

On 26 août 2013, at 08:35, address@hidden wrote:

> On 2013/08/26 05:25:42, mike7 wrote:
>> On 26 août 2013, at 08:20, mailto:address@hidden wrote:
> 
>> > Indeed.  Instead of calling stencil-integrate on a "surrogate
> stencil"
>> > or whatever for deriving a skyline, the respective stencil operation
> in
>> > stencil-integrate will just plug in a a "surrogate skyline" directly
>> > specified in the stencil operation and be done.
>> >
>> > Which is less work.
> 
>> What is more work is what I talk about farther down in my previous
>> e-mail.
> 
> So why do you talk about that in the first place?

Because I'd rather spend more time implementing a solid system than less time 
implementing a kludge.  What I'm proposing (making skylines a stencil data 
member) is more work but seems less kludgy than creating a stencil primitive 
containing skylines.

> 
>> It is possible to create a stencil primitive that works something
> like:
> 
>> `(replacement-skylines ,left ,right, ,up ,down original-stencil)
> 
>> but that seems kludgy.
> 
> Less kludgy than the code we are currently reviewing, and that's what
> the current issue is.

Agreed.

> 
>> It would be better and more consistent with currently practices in
>> the code base if stencils carried their own skyline information (as
>> they do their own dimensions), which would require a lot of juggling
>> code around.
> 
> In the context of reviewing this patch, this is a straw man argument.

In the context of figuring out the best way to do things, this is important.  
It would be better to decide what problem we're trying to solve and implement 
it correctly now rather than creating a temporary solution that we do away with 
later.

It seems like stencil expressions should not contain dimensional information.  
Where it does (like, for example, the stencil command 'translate-stencil 
defined in define-stencil-commands.scm), this seems like legacy code that has 
not evolved with LilyPond and is barely used.

So, as long as we're going to solve this problem, we should have a broader 
discussion about how stencils are put together.  I argue that we should not be 
putting dimension information in the stencil expression itself.  If this is the 
case, then a replacement-skyline stencil primitive is not a good idea.  I am 
definitely not going to work on a patch implementing skylines as a stencil data 
member if people don't think it's a good idea, though, as it would take tons of 
time and would represent a major reorganization of things.  However, if this is 
the right way to go about solving the problem, it is better to spend the time 
than create a stencil primitive (replace-skylines) that we are not happy with.

Cheers,
MS


reply via email to

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