lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 3925: lilypond -d leads to weird output (issue 104720047)


From: dak
Subject: Re: Issue 3925: lilypond -d leads to weird output (issue 104720047)
Date: Mon, 02 Jun 2014 07:42:02 +0000

On 2014/06/01 22:00:17, lemzwerg wrote:
OK, I have admittedly not looked at lilypond's help message.

The help message does not use quoting.  It uses block formatting, and
"-d, --define-var" is formatted as one block.

I agree that it is
useful to harmonize quoting - given that

   '-f, --foo'

is not correct, I vote for *not* using any quotes, as is done e.g.
with the
output of `grep --help'.  In lilypond's info manual, it should also be
done as
in grep's info manual.

This issue is not a documentation reformatting issue.  It fixes the
command line error message bug.  If you want to file a documentation
enhancement request (which would touch quite a bit more code and
ultimately all translations), feel free to do so.

However, the current option formatting in the manual has been the result
of various issues and discussions already.  The quotes are not actually
generated explicitly, but are in the info manual incidentally because of
the formatting

    @table @code

    @item -d, address@hidden@var{val}
[...]

In the web version, we have
<URL:http://lilypond.org/doc/v2.18/Documentation/usage/command_002dline-usage#basic-command-line-options-for-lilypond>
namely no quote characters but a font change.

We are talking here, in this issue, about an error message putting quote
marks around the option and its variant in question.

I am not going to engage in bike shedding in this issue.  Either it goes
in as `-d, --define-default' as the minimal sanity change I added on top
of the bug fix, or it goes in without the sanity fix as `-d,
`--define-default'' as the original code would do.  I'd also be willing
to entertain `-d', `--define-default' as a best guess that it was rather
this which was intended by the original code, but since this is the
target of a to_string call, it would mean that this call can output one
_or_ two comma-separated quoted items, making it harder to pick the
right grammar for embedding the output.

In the light of that, I prefer erring on the safe side and returning, as
previously, a single quoted item, just removing the insane inner quote.

I repeat: this is a bug fix issue, not a reformatting issue.  Before
engaging in any endless discussion, I will rather keep this at `-d,
`--define-default'' and let someone who cares to do the work and
discussion do the respective issue.

https://codereview.appspot.com/104720047/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]