Re: makelsr

[Thomas Morley]

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