Re: Adds incipit section to NR (issue 108270043 by address@hidden)

[dak]

On 2014/08/21 10:21:18, mail_philholmes.net wrote:

> There's nothing wrong in changing a poor default to a good one, and
then
> allowing the user to restore the poor one.

But you are not "changing a poor default to a good one".  You are
overriding locally, as the default of a single command, what you
perceive as a poor overall default.  If the default is poor, changing
it is reasonably.  Scattering different defaults everywhere where
someone adds code isn't.

Please note that if the incipit command changes some _entirely_
_unrelated_ default, then the description of the incipit would need to
include "as one side effect, the alignment of the instrument name is
changed from its default of #CENTER to #RIGHT because #CENTER looks
ugly anyway."  Not in relation to incipits, but anyway.

> > I would prefer to get stuff as correct and complete at the first go
as
> > we can manage.  Of course, once you throw up your hands in disgust,
the
> > work we can hope to get achieved from one author in one go is over.
And
> > naturally, there is not much of a point to exhaust your enthusiasm
for
> > LilyPond over a single issue.  I'd still be glad if we could get the
> > code and documentation at least to a state where we don't need to
touch
> > the translatable part in the NR (example use and description) any
more
> > for a large variation of different applications, even if it will
fall to
> > my lot to do further work on the \incipit definition in
property-init.ly
> > itself in order to have it work in more situations.
> >
> >
> > https://codereview.appspot.com/108270043/

> As I explained above, I believe in a kind of "push and show"
> approach.

It's not just "push and show".  It is "push and show and document and
translate, and if subsequently any defaults are changed, write and
maintain respective convert-ly rules".

I spend easily 75% of my time on analyzing and fixing "push and show"
work that went wrong and that people now _expect_ to be available.
Just right now I had to completely reimplement nested overrides,
something that was implemented on a "push and show" basis because the
assumptions underlying the original implementation were simply broken
and nobody could be bothered getting or proving the details workable
before dumping some half-working code into LilyPond.

At the current point of time, we have diverging Midi features that
cannot work at the same time.

In this case, you override some defaults in a fixed manner because you
don't like the defaults of LilyPond and the code did not provide a
convenient way to override the defaults.

So I propose a way allowing it to override the respective defaults in
a convenient manner that would warrant getting put in there and
_utilized_ and documented in order to get the result you consider
better and show the users how they can arrive there themselves, and
you basically go at me with a knife.

It's not like I ask you to toil for hours.  I spelled out all the
details of code explicitly, and I can naturally also provide a patch
which is not more than a few lines.  What I cannot do is rewrite the
documentation section as if it were written by you, and that is what
this issue is actually about.

> I am severely discouraged by continual "this is wrong, no it's not"
> bickering.  I (as you may note today) can recover my enthusiasm
> despite this, but I find it wearing, as I know others do.  I believe
> we need to work from a standpoint that we accept the view of the
> creator of the patch unless there is _proof_ that what is being
> proposed is wrong in terms of code quality or other damage to the
> code base.  The two you cited above (missing indent, missing
> incipit) are examples of proof that there is something wrong

They are examples of problems in the incipit code.  _Those_ actually
are no showstoppers since fixing them does not create additional
documentation or translation or convert-ly or other followup work.
All of those should be fixable.  The one with the non-appearing
incipit will likely require a code change (I suspect that a code
shortcut has to be removed somewhere) to avoid documenting an
implementation quirk.  At any rate, _those_ problems do not affect the
_design_ of the code and the design of the user interface and its
documentation.  In contrast, diverging defaults and the inability to
predict and/or override them _do_ affect the user interface and its
documentation.

> and I will work to get rid of them.  "I think the instrument name
> should be on the left" is not.

The current default is #CENTER, by the way.

You put quote marks around that sentence as if I uttered it.  I never
did.  And I never claimed that I think the instrument name should be
on the left.  What I stated is that since the start of an incipit is
not in any graphically relevant manner different from the start of a
regular staff, there is no reason to tamper with the default
instrument alignment as part of the incipit code, whatever the default
may happen to be.

"But it looks ugly to me" is a perfectly valid reason for providing a
documented and easily accessible way of overriding it, like we do for
the default InstrumentName grob too.  It may also provide part of a
reason of eventually changing our overall default instrument name
aligment.

And once issue 766 is tackled in some manner, we better make sure that
our implementation of \incipit eventually cooperates with that
solution.  Defining how that cooperation is supposed to look becomes
harder when \incipit chooses to implement independent behavior.


https://codereview.appspot.com/108270043/