Re: Pedal cautionary after a line break (current status and improvements)

[Paolo Prete]

On Sat, Jun 27, 2020 at 2:25 AM David Rogers <davidandrewrogers@gmail.com>
wrote:

> 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