On 26 août 2013, at 08:35, d...@gnu.org wrote: > On 2013/08/26 05:25:42, mike7 wrote: >> On 26 août 2013, at 08:20, mailto:d...@gnu.org 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
