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

[David Rogers]

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!)

There's an old joke: When free software is defective, the users 
are entitled to a full refund. :)

--
David Rogers