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/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
