Re: Simplify the NullVoice context (issue 117050043 by address@hidden)

[dak]

"Keith OHara" <address@hidden> writes:

> On Sun, 07 Sep 2014 01:21:58 -0700, <address@hidden> wrote:

> > But messing up the basic grob definition by fetching internals and
> > meddling through them locally: no.

> Well, you say "messing up the basic grob definition"
> I say "reading the basic definition, and making a local modified copy"

Which is cute but does not take into account that the definition has
been assembled by specific functions in a manner ensuring that it is
self-consistent, and that has dependencies with regard to the
consistency of other grob elements.

That's the "You need another door?  Just smash a window and climb
through" approach.  Whether or not a particular window might indeed have
been the best place for a patio door, that's not a "solution" that has a
place in our code base.

> I'll try some other way of telling Accidental_engraver to ignore
NullVoice.  I'm trying to let people move NullVoice to Staff without
reintroducing the known issue of the cancellation accidentals in
>   \new Staff <<
>     \new NullVoice {cis dis es fis}
>     \new Voice {r4 c d e } >>

Again: I would strongly suggest that you backpedal and consider the
question "what was my first approach which did not work, for
reasons?".

And then we see what it would take to address the reasons.  Even if we
assume that messing up our codebase like that is perfectly fine, you
will not be the last person to encounter a similar problem.  And when
another person encounters a similar problem, our answer better not be
"oh, LilyPond cannot deal with that, but if you dig up its internals
and squeeze something different in, it might or might not do the
trick.  At least until the next version with changed internals."

That is: when solving a problem, we should strive to have it spawn new
solutions, not new problems.


https://codereview.appspot.com/117050043/