> And a really minimal example is the one Thomas already posted:
>
> %%%%%%%%%%%%%%%%%%%
>
> \new Staff <<
>   { s1 s1 }
>   { \compressFullBarRests R1*2 }
> >>
> %%%%%%%%%%%%%%%%%%%

I reject this as a minimal example because it only demonstrates half of
what I demonstrated,  which is that the same music expression exhibits
different behavior in different contexts, with regard to
compressFullBarRests.

This example is thus both incomplete, and not obviously the same problem.

>> Removing anything else would dissolve the framework within which I'm
having the problem.
>
> The point is isolating the exact problem.

Let's put this another way: refactoring a problem into a different problem
is only useful if you are sure that the problems are identical.

The assertion that this globals recipe boils down to a parallel music
expression is insightful.  But, as someone less familiar with these
techniques, that is a dubious assumption for me to make.

Your suggestion boils down to requiring me to reverse engineer something
suggested to me as a best practice on this list, as a precondition for
asking a question about how to use it.

Now,  that strikes me as a particularly  ridiculous suggestion.

> Everybody trying to help you (unless he is already familiar with the
problem) will have to do exactly that: produce a minimal example.

No, the folks I expect might help will be able to eyeball it and not even
need to compile the example.

Especially those who suggested or are familiar with this recipe.

No one is obligated to help me.

If you feel a question is too difficult to solve, please ignore it rather
than flame me.

> And I was trying to assist you in helping yourself. I have also spent
tedious hours creating a minimal example from a complicated multi-file
setup with lots of Scheme code, cropping everything down until I found the
needle in the haystack. There’s nothing for it.

Congratulations on being able to solve all your own problems.

I solve as many of mine as I can, too.

When I get stuck,  I ask a well-curated question.  We may disagree on what
that means, but I  can assure you I am very careful about what I present to
the list.

I agree with the emphasis on minimal.

But not as a fetish, at the expense of clarity.

Identifying the problem clearly in both the code and the pdf, is necessary
to achieve this in my opinion.

> Yours, Simon

Cheers,
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Reply via email to