Re: makelsr

[Phil Holmes]

Having trouble with quoting properly here, so selectively editing:

> Why is always \version "2.20.0" inserted? Doing convert-ly manually
> will make for "2.21.0"

No idea at this point - I'd have to look at the input to convert-ly and the 
output from the program, and that's long gone.  I don't think it's a real 
problem though.

> Looking at this diff:

> diff --git a/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
> b/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
> index c1a36ec..900167f 100644
> --- a/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
> +++ b/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly

> Why is the user generated variable partCombineUp/Down changed to a
> lower-case "c"?

Looks like an offshoot of 
https://sourceforge.net/p/testlilyissues/issues/4603/ where the LSR did not 
have its descriptions all updated?

> This a renamed snippet. But anyway, I can't find any snippet in git
> which uses \markuplines.
> Where does it come from?

I'm guessing that if git realises two files are essentially the same, it 
changes one to the other rather than deleting one and creating the other?

--
Phil Holmes


----- Original Message ----- 
From: "Thomas Morley" <address@hidden>
To: "Phil Holmes" <address@hidden>
Cc: "lilypond-devel" <address@hidden>; "Malte Meyn" 
<address@hidden>
Sent: Saturday, December 29, 2018 6:31 PM
Subject: Re: makelsr


Am Sa., 29. Dez. 2018 um 18:40 Uhr schrieb Phil Holmes 
<address@hidden>:
> ----- Original Message -----
> From: "Malte Meyn" <address@hidden>
> To: <address@hidden>
> Sent: Saturday, December 29, 2018 9:29 AM
> Subject: Re: makelsr
>
>
> >
> >
> > Am 28.12.18 um 21:33 schrieb Phil Holmes:
> >> A little late to the party, but I am almost certain that running 
> >> makelsr
> >> to create an LSR patch and then (after testing with at least make, make
> >> doc) and pushing that patch, and then putting up the doc patch for 
> >> review
> >> is a perfectly accestable way to go. I've rather got out of the habit,
> >> but I regularly used to run makelsr, eyeball it carefully (as in the 
> >> CG)
> >> then push it without review. Extra files in the patch won't break the
> >> build, only missing ones.
> >
> > I think that this sounds like the easiest way. That way every single
> > commit ‘make’s without problems, there is no makelsr output in the 
> > review
> > of the then following doc patch and one doesn’t have to mess with
> > different branches. (Ok, I have to admit that I simply didn’t understand
> > exactly how the solution with separate commits and a merge should look
> > like. But it seems as if I’m not the only one.)
> >
> > Could you, Phil, please push such a makelsr run as you described? As 
> > long
> > as I don’t have permission/trust from some of you to do this without
> > review, I’d have to go the ‘long’ Rietveld way.
> >
> > Of course, if there are objections against this way, I’ll try to figure
> > out how exactly the ‘separate-branches-and-merge-commit’ thing works.
>
> Pushed to staging and then patchy-ed to master.
>
> --
> Phil Holmes

Hi Phil,

I did my own experiments with makelsr locally, because I wanted to
become more familiar with it.
In my local testings I stumbled across some possible issues. They are
visible in your patch as well
http://git.savannah.gnu.org/cgit/lilypond.git/commit/?id=00f0ca84dbb015617f8ce36dd13db59bbfef8f11

(1)
Why is always \version "2.20.0" inserted? Doing convert-ly manually
will make for "2.21.0"

(2)
Looking at this diff:

diff --git a/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
b/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
index c1a36ec..900167f 100644
--- a/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
+++ b/Documentation/snippets/two--partcombine-pairs-on-one-staff.ly
@@ -48,7 +48,7 @@ fis b,2 @}
}
}
-partCombineUp =
+partcombineUp =
#(define-music-function (partOne partTwo)
(ly:music? ly:music?)
"Take the music in @var{partOne} and @var{partTwo} and return
@@ -66,7 +66,7 @@ in the output to use upward stems."
> >
#})
-partCombineDown = #
+partcombineDown = #
(define-music-function (partOne partTwo)
(ly:music? ly:music?)
"Take the music in @var{partOne} and @var{partTwo} and return

Why is the user generated variable partCombineUp/Down changed to a
lower-case "c"?
Is the convert-rule insufficient?


(3)
Looking at this diff:

diff --git a/Documentation/snippets/markup-lines.ly
b/Documentation/snippets/markup-list.ly
index 6ff040e..3015055 100644
--- a/Documentation/snippets/markup-lines.ly
+++ b/Documentation/snippets/markup-list.ly
@@ -10,11 +10,11 @@
lsrtags = "text"
texidoc = "
-Text that can spread over pages is entered with the
address@hidden command.
+Text that can spread over pages is entered with the @code{\\markuplist}
+command.
"
- doctitle = "Markup lines"
+ doctitle = "Markup list"
} % begin verbatim
%% updated/modified by P.P.Schneider on Feb. 2014


This a renamed snippet. But anyway, I can't find any snippet in git
which uses \markuplines.
Where does it come from?


Cheers,
 Harm