On Sat, Jun 27, 2020 at 2:25 AM David Rogers <davidandrewrog...@gmail.com> wrote:
> Paolo Prete <paolopr...@gmail.com> writes: > > > 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 > > 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
