On Thu, Jun 25, 2020 at 6:00 PM Jean Abou Samra <j...@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
