Paolo Prete <paolopr976@gmail.com> writes:
> On Thu, Jun 25, 2020 at 6:00 PM Jean Abou Samra
> <jean@abou-samra.fr>
> wrote:
>
> So, in order to produce a concrete result, at least the
> point
> 2) should be accepted / understood. This is what I tried
> to
> do, but the thread seems to go in the opposite way. This
> is
> why I think that opening a ticket would be unuseful for
> now
> and I did not open it. But if you think it could be
> useful,
> be free (of course) to open it ...
>
>
> This is precisely the heart of the question. LilyPond
> development
> is
> (mostly) not driven by the importance of issues but rather
> by
> pleasure and
> interest. Which means that you just need one person willing
> to
> spend time on
> piano pedals − and skilled enough for that − regardless of
> the
> issue's
> weight. That can happen now, or in months or in years, who
> knows.
> In the
> most extreme cases, issues can be resolved a decade after
> they
> were
> reported. Look at the one David Stephen Grant fixed just two
> weeks ago:
>
> https://gitlab.com/lilypond/lilypond/-/issues/1722
> https://gitlab.com/lilypond/lilypond/-/merge_requests/119
>
> This is why issues are so essential. They help organize work
> on a
> long time frame.
>
> By the way, the Type::Enhancement label expresses no
> judgement
> about wether the
> issue is a major one. It's to be understood as opposed to
> Type::Defect: this ticket
> is about an enhancement because the current output is
> consistent
> and there is
> no crash.
>
> I opened https://gitlab.com/lilypond/lilypond/-/issues/6005
> .
>
>
> I would not proceed in this way.
> The lack of a cautionary pedal on a bracket could be seen as an
> enhancement only in a self-referential context, which doesn't
> make
> sense to me. A proper way to proceed is to check what modern
> professional engravers do with it, and check as a consequence if
> Lilypond is coherent with them (-> common practice)
> AFAIK nobody uses a bracket without a starting word in
> professional
> engraving, it would have too many bad side effects. And opening
> an
> issue as an enhancement IMHO will weaken the urgency of fixing
> this.
>
> Best,
>
> P
Certainly you're right that it's an "enhancement" only in a
self-referential context. But that was already the meaning of
Jean's message; when you decide to use *any* complex software
that's developed by volunteers, you must accept that this same
self-referential point of view is going to prevail. It's just part
of the way humans are. The main exception is when someone is
bothered by an irritating defect that he cares about, in some
software that he cares about; he refuses to accept that the
situation might stay this way, and finally he gets so impatient or
angry that he learns the necessary programming language and fixes
the problem himself. (Who knows? That example might be you!)
I understand what you write.
But, as said before, doing the hack "fake pedal with a sustain spanner + hidden real pedal" solves all for me.
I already have accepted that the situation will stay in this way, and this is absolutely no problem for me. Really.
I have worked on open source projects since so many years that I consider even too much what we already have with Lilypond.
Best,
P