[prev in list] [next in list] [prev in thread] [next in thread]
List: lilypond-user
Subject: Re: How to submit a feature request (issue)
From: Jean Abou Samra <jean () abou-samra ! fr>
Date: 2023-06-30 22:47:56
Message-ID: ef2946dd57e60d47a4a0bceedbd54eb61479f4ad.camel () abou-samra ! fr
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Le vendredi 30 juin 2023 à 15:36 -0700, Stu McKenzie a écrit :
>
> I'm not sure how to submit a feature request issue.
>
> I'd like to request the following change to the LilyPond parser:
>
> One feature that would be useful is for the LilyPond parser to output
> the following version numbers:
> The LilyPond version, e.g. 2.24.1;
> The source file "\version", e.g. 2.22.0.
>
> If one changes the version number to a number greater than the current
> version, the output is:
> Parsing...
> error: program too old: 2.24.1 (file requires: 2.25.0)
>
> This shows that the parser is checking the versions, so to output the
> version numbers shouldn't require much additional coding.
>
> If the versions are always output, this would serve as confirmation that
> a source file is up to date, and also remind users if convert-ly has, or
> hasn't, been performed on a source file.
>
> Perhaps this could be extended to check versions of any files included
> by the source file (this may be a bit too complicated!).
>
> Would those more familiar with bug and issue reporting guide me as to
> whether or not this is worth pursuing, and if so, how to proceed?
In principle, feature requests should be sent to the bug-lilypond list
(see https://lilypond.org/bug-reports.html ; while those are the guidelines for
bug reports, they apply to feature requests too, maybe we ought to clarify
that...). It can be discussed on the list if it's not clear that it would be an
enhancement, and if/when it's clear, someone adds it to the GitLab issue
tracker. But since you've already sent this, let's discuss it here.
First, the log already includes the LilyPond version number. In a terminal, it
reads
GNU LilyPond 2.25.4 (running Guile 2.2)
Processing `test.ly'
...
and in Frescobaldi:
Starting lilypond 2.24.1 [Untitled]...
...
We could easily output the file version, but I'm not sure this would really
bring value, given that it's stated very visibly with \version at the top of the
file... ?
(Personally, I wish Frescobaldi automatically proposed to run convert-ly when
running a newer LilyPond version on an older file.)
Best,
Jean
[Attachment #5 (text/html)]
<html><head><style>pre,code,address {
margin: 0px;
}
h1,h2,h3,h4,h5,h6 {
margin-top: 0.2em;
margin-bottom: 0.2em;
}
ol,ul {
margin-top: 0em;
margin-bottom: 0em;
}
blockquote {
margin-top: 0em;
margin-bottom: 0em;
}
</style></head><body><div>Le vendredi 30 juin 2023 Ã 15:36 -0700, Stu McKenzie a \
écrit :</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px \
#729fcf solid;padding-left:1ex"><div><br></div><div>I'm not sure how to submit a \
feature request issue.<br></div><div><br></div><div>I'd like to request the following \
change to the LilyPond parser:<br></div><div><br></div><div>One feature that would be \
useful is for the LilyPond parser to output <br></div><div>the following version \
numbers:<br></div><div>The LilyPond version, e.g. 2.24.1;<br></div><div>The source \
file "\version", e.g. 2.22.0.<br></div><div><br></div><div>If one changes the version \
number to a number greater than the current <br></div><div>version, the output \
is:<br></div><div>Parsing...<br></div><div>error: program too old: 2.24.1 (file \
requires: 2.25.0)<br></div><div><br></div><div>This shows that the parser is checking \
the versions, so to output the <br></div><div>version numbers shouldn't require much \
additional coding.<br></div><div><br></div><div>If the versions are always output, \
this would serve as confirmation that <br></div><div>a source file is up to date, and \
also remind users if convert-ly has, or <br></div><div>hasn't, been performed on a \
source file.<br></div><div><br></div><div>Perhaps this could be extended to check \
versions of any files included <br></div><div>by the source file (this may be a bit \
too complicated!).<br></div><div><br></div><div>Would those more familiar with bug \
and issue reporting guide me as to <br></div><div>whether or not this is worth \
pursuing, and if so, how to \
proceed?</div></blockquote><div><br></div><div><br></div><div>In principle, feature \
requests should be sent to the bug-lilypond list (see <a \
href="https://lilypond.org/bug-reports.html">https://lilypond.org/bug-reports.html</a> ; \
while those are the guidelines for bug reports, they apply to feature requests too, \
maybe we ought to clarify that...). It can be discussed on the list if it's not clear \
that it would be an enhancement, and if/when it's clear, someone adds it to the \
GitLab issue tracker. But since you've already sent this, let's discuss it \
here.</div><div><br></div><div>First, the log already includes the LilyPond version \
number. In a terminal, it reads</div><div><br></div><div>GNU LilyPond 2.25.4 (running \
Guile 2.2)</div><div>Processing `test.ly'</div><div>...</div><div><br></div><div>and \
in Frescobaldi:</div><div><br></div><div>Starting lilypond 2.24.1 \
[Untitled]...</div><div>...</div><div><br></div><div>We could easily output the file \
version, but I'm not sure this would really bring value, given that it's stated very \
visibly with \version at the top of the file... \
?</div><div><br></div><div>(Personally, I wish Frescobaldi automatically proposed to \
run convert-ly when running a newer LilyPond version on an older \
file.)</div><div><br></div><div>Best,</div><div>Jean</div><div><br></div><div><span></span></div></body></html>
["signature.asc" (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic