Allow quoted strings as Scheme arguments to markup commands

Allow quoted strings as Scheme arguments to markup commands

After issue 5113, quoted strings and non-quoted strings are
distinguished in the lexer.  This makes it feasible for Scheme-type
arguments of markup commands to accept quoted strings.  Unquoted
strings (token SYMBOL in the lexer) remain out of consideration since
it would be hard to explain why 0.0 is acceptable as a string?
argument but not as number? : in markup mode, most character sequences
end up as "SYMBOL" by default in order to allow typesetting of text
blocks.


Also contains commit:

Add convert-ly rule for markup command arg #" -> "

[dak, 2017-10-05 11:17:14]

(Re-)run scripts/auxiliar/update-with-convert-ly.sh

[Malte Meyn, 2017-10-06 21:37:48]

https://codereview.appspot.com/331820043/diff/20001/python/convertrules.py
File python/convertrules.py (right):

https://codereview.appspot.com/331820043/diff/20001/python/convertrules.py#ne...
python/convertrules.py:3963: str = re.sub
(r'(\\(?:justify-string|musicglyph|harp-pedal|simple|postscript'
Isn’t this list of markup commands with string arguments far from complete? What
about wordwrap-string, eps-file, with-url, lookup, verbatim-file,
wordwrap-string-internal, and the accordion commands discant, freeBass, stdBass,
stdBassIV, stdBassV, and stdBassVI?

[dak, 2017-10-06 22:00:07]

https://codereview.appspot.com/331820043/diff/20001/python/convertrules.py
File python/convertrules.py (right):

https://codereview.appspot.com/331820043/diff/20001/python/convertrules.py#ne...
python/convertrules.py:3963: str = re.sub
(r'(\\(?:justify-string|musicglyph|harp-pedal|simple|postscript'
On 2017/10/06 21:37:47, Malte Meyn wrote:
> Isn’t this list of markup commands with string arguments far from complete?

Likely.  It was cooked up on the basis of a git grep call, I think

    git grep '\\markup.*#"'


> What
> about wordwrap-string, eps-file, with-url, lookup, verbatim-file,
> wordwrap-string-internal, and the accordion commands discant, freeBass,
stdBass,
> stdBassIV, stdBassV, and stdBassVI?

Some of them certainly are good candidates, as long as their _first_(!) argument
is the string argument.  Otherwise, the convert-ly expression becomes a lot more
tricky.

[Malte Meyn, 2017-10-06 22:14:27]

On 2017/10/06 22:00:07, dak wrote:
> > What
> > about wordwrap-string, eps-file, with-url, lookup, verbatim-file,
> > wordwrap-string-internal, and the accordion commands discant, freeBass,
> stdBass,
> > stdBassIV, stdBassV, and stdBassVI?
> 
> Some of them certainly are good candidates, as long as their _first_(!)
argument
> is the string argument.  Otherwise, the convert-ly expression becomes a lot
more
> tricky.

Hm, that’s correct, but only two of these candidates don’t have the string as
their first argument:

1. \epsfile starts with two numbers (\epsfile #X #20 #"myfile.eps")
2. \wordwrap-string-internal starts with a boolean (\wordwrap-string-internal
##t #"This is my string")

[thomasmorley651, 2017-10-06 22:28:38]

On 2017/10/06 22:00:07, dak wrote:
> https://codereview.appspot.com/331820043/diff/20001/python/convertrules.py
> File python/convertrules.py (right):
> 
>
https://codereview.appspot.com/331820043/diff/20001/python/convertrules.py#ne...
> python/convertrules.py:3963: str = re.sub
> (r'(\\(?:justify-string|musicglyph|harp-pedal|simple|postscript'
> On 2017/10/06 21:37:47, Malte Meyn wrote:
> > Isn’t this list of markup commands with string arguments far from complete?
> 
> Likely.  It was cooked up on the basis of a git grep call, I think
> 
>     git grep '\\markup.*#"'
> 
> 
> > What
> > about wordwrap-string, eps-file, with-url, lookup, verbatim-file,
> > wordwrap-string-internal, and the accordion commands discant, freeBass,
> stdBass,
> > stdBassIV, stdBassV, and stdBassVI?
> 
> Some of them certainly are good candidates, as long as their _first_(!)
argument
> is the string argument.  Otherwise, the convert-ly expression becomes a lot
more
> tricky.

One could probably do something at the lines of:
(pretty-print
  (sort
    (map car
      (filter
        (lambda (x)
          (let* ((predicates (markup-command-signature (cdr x))))
            (and predicates
                 (pair? predicates)
               (eq?
                 (procedure-name string?)
                 (car (map procedure-name predicates))))))
        (ly:module->alist (resolve-module '(lily)))))
    symbol<?))

->
 (fret-diagram-markup
  fret-diagram-terse-markup
  harp-pedal-markup
  justify-string-markup
  lookup-markup
  musicglyph-markup
  postscript-markup
  rest-markup
  simple-markup
  tied-lyric-markup
  verbatim-file-markup
  with-url-markup
  wordwrap-string-markup)

[dak, 2017-10-07 08:05:20]

On 2017/10/06 22:28:38, thomasmorley651 wrote:
 
> One could probably do something at the lines of:

Accordion registers missing.  Should we consider them a separate name space?

> (pretty-print
>   (sort
>     (map car
>       (filter
>         (lambda (x)
>           (let* ((predicates (markup-command-signature (cdr x))))
>             (and predicates
>                  (pair? predicates)
>                (eq?
>                  (procedure-name string?)
>                  (car (map procedure-name predicates))))))

Seriously?

For one thing, (car (map procedure-name predicates)) is costly, calculating all
names and throwing away all but the first one.  You could have written
(procedure-name (car predicates)) instead.  For another, why not just compare
(eq? string? (car predicates)) instead of trying to look up the name?  It isn't
needed, is it?  I mean, ok ok, this is a run-once piece of code.

>         (ly:module->alist (resolve-module '(lily)))))
>     symbol<?))
> 
> ->
>  (fret-diagram-markup
>   fret-diagram-terse-markup
>   harp-pedal-markup
>   justify-string-markup
>   lookup-markup
>   musicglyph-markup
>   postscript-markup
>   rest-markup
>   simple-markup
>   tied-lyric-markup
>   verbatim-file-markup
>   with-url-markup
>   wordwrap-string-markup)

Well, yeah.  That looks like a reasonable list.  I think I'll leave out
rest-markup here since there is some impetus to change it akin to \note and it's
not clear how this will go yet.  And \rest can occur outside of markup, so the
#" is a pretty obvious marker that we are dealing with the markup.

[dak, 2017-10-07 08:52:45]

Additional convert-ly rules

[Malte Meyn, 2017-10-07 10:11:58]

https://codereview.appspot.com/331820043/diff/40001/Documentation/snippets/th...
File Documentation/snippets/three-sided-box.ly (right):

https://codereview.appspot.com/331820043/diff/40001/Documentation/snippets/th...
Documentation/snippets/three-sided-box.ly:7: %% Note: this file works from
version 2.18.0
I don’t know anything about snippets but this seems odd. And I noticed that some
other snippets which have been updated (like f. e. breathing-signs.ly) don’t
have this note at all. Is it needed for LSR?

[dak, 2017-10-07 10:47:21]

https://codereview.appspot.com/331820043/diff/40001/Documentation/snippets/th...
File Documentation/snippets/three-sided-box.ly (right):

https://codereview.appspot.com/331820043/diff/40001/Documentation/snippets/th...
Documentation/snippets/three-sided-box.ly:7: %% Note: this file works from
version 2.18.0
On 2017/10/07 10:11:58, Malte Meyn wrote:
> I don’t know anything about snippets but this seems odd. And I noticed that
some
> other snippets which have been updated (like f. e. breathing-signs.ly) don’t
> have this note at all. Is it needed for LSR?

Ah, I thought nobody'd notice (I forgot to run makelsr.py) and did not bother to
reupload.  Looks like I was wrong.

The comment is autogenerated when a file is produced from
Documentation/snippets/new which most files aren't.

[dak, 2017-10-07 10:48:14]

Run makelsr.py for fixing a few \version statements

[dak, 2017-10-07 10:49:56]

On 2017/10/07 10:48:14, dak wrote:
> Run makelsr.py for fixing a few \version statements

Oops.  Actually I also fixed up the docs in scm/accreg.scm .