Changes.tely - reorganize entries for 2.20 release

Changes.tely - reorganize entries for 2.20 release

Issue 5176

Documents all changes to LilyPond
since 2.18. The list is organized
as per the Notation Reference in
terms of sections and subsections.

[pkx166h, 2017-09-05 06:53:05]

Hello people.

The summary should be self-explanatory but at this stage of the patch it is just
'organizational' - I'll try to improve any entries once the order has been
approved as this will make reviewing easier.

I have used
@subheading
@strong

For section/subsection headings to keep the numbering out of the HTML and PDFs,
as I think that is not appropriate for the changes, but because of the
idiosyncrasies of texinfo I cannot create @menus without resorting to sections
that look odd for the changes list.

I am unsure, however, on the 'last' section which I have tentatively listed as
'New for Internal interfaces and functions', in both if the name of the section
is appropriate and what I have left in that section is in the 'right' place for
this list.

Bear in mind that while a change to some 'scheme' function or 'assoc list'
property (or whatever they are) might improve some aspect of the output, from a
general user's point of view they will probably be gobbledygook - speaking as
one of those general users - which is why I have left them in this last section,
at least for now.

Once the order has been reasonably approved, I'll start to make edits to the
text where appropriate and include some more @lilypond examples.

Thank you.

[pkx166h, 2017-09-17 21:04:55]

rebased with stable/2.20 (instead of current master)

[pkx166h, 2017-09-20 20:18:44]

more improvements to existing examples and descriptions - more work still to do

[pkx166h, 2017-09-20 20:30:59]

more improvements to existing examples and descriptions - more work still to do

[pkx166h, 2017-09-30 20:13:49]

author	James Lowe <pkx166h@gmail.com>	
	Sat, 30 Sep 2017 19:47:14 +0100 (19:47 +0100)
committer	James Lowe <pkx166h@gmail.com>	
	Sat, 30 Sep 2017 19:47:14 +0100 (19:47 +0100)
commit	035069ca1a11f32d5fe66de381220c6162b95240

[dak, 2017-10-01 10:57:31]

https://codereview.appspot.com/326400043/diff/60001/Documentation/changes.tely
File Documentation/changes.tely (right):

https://codereview.appspot.com/326400043/diff/60001/Documentation/changes.tel...
Documentation/changes.tely:67: hyphenated;
A few remarks after the fact (sorry for that): we are talking only about long
English pitch names here, so it is more like "In English notename language,
pitch names containing @samp{sharp} or @samp{flat} now need to be hyphenated."

Then generally you appear to use a semicolon instead of a colon before examples;
I don't think that improves readability and it doesn't match our style
elsewhere.

There are lots of whitespace errors as well (spaces before end of line).

Try

    git log --check origin/stable/2.20

for an exhaustive list of newly introduced (according to git diff which might
consider a lot of material actually moved around as if it were new) problems.

[pkx166h, 2017-10-01 17:11:41]

On 2017/10/01 10:57:31, dak wrote:
> https://codereview.appspot.com/326400043/diff/60001/Documentation/changes.tely
> File Documentation/changes.tely (right):
> 
>
https://codereview.appspot.com/326400043/diff/60001/Documentation/changes.tel...
> Documentation/changes.tely:67: hyphenated;
> A few remarks after the fact (sorry for that): we are talking only about long
> English pitch names here, so it is more like "In English notename language,
> pitch names containing @samp{sharp} or @samp{flat} now need to be hyphenated."
> 
> Then generally you appear to use a semicolon instead of a colon before
examples;
> I don't think that improves readability and it doesn't match our style
> elsewhere.
> 
> There are lots of whitespace errors as well (spaces before end of line).

Oh. Sorry.

> 
> Try
> 
>     git log --check origin/stable/2.20
> 
> for an exhaustive list of newly introduced (according to git diff which might
> consider a lot of material actually moved around as if it were new) problems.

If you want, you can remove this commit and I will go back and check/fix all the
whitespace errors and recommit it.

I don't recall complaints from git about whitespace when I applied the patch to
my local copy of stable nor did I notice any excessive whitespace chars in my
editor (I use Geany).

I have closed this issue (after I commited) so I can redo a new issue, it's not
a huge deal for me.

James

[dak, 2017-10-01 17:17:32]

On 2017/10/01 17:11:41, pkx166h wrote:
> On 2017/10/01 10:57:31, dak wrote:
> >
https://codereview.appspot.com/326400043/diff/60001/Documentation/changes.tely
> > File Documentation/changes.tely (right):
> > 
> >
>
https://codereview.appspot.com/326400043/diff/60001/Documentation/changes.tel...
> > Documentation/changes.tely:67: hyphenated;
> > A few remarks after the fact (sorry for that): we are talking only about
long
> > English pitch names here, so it is more like "In English notename language,
> > pitch names containing @samp{sharp} or @samp{flat} now need to be
hyphenated."
> > 
> > Then generally you appear to use a semicolon instead of a colon before
> examples;
> > I don't think that improves readability and it doesn't match our style
> > elsewhere.
> > 
> > There are lots of whitespace errors as well (spaces before end of line).
> 
> Oh. Sorry.
> 
> > 
> > Try
> > 
> >     git log --check origin/stable/2.20
> > 
> > for an exhaustive list of newly introduced (according to git diff which
might
> > consider a lot of material actually moved around as if it were new)
problems.
> 
> If you want, you can remove this commit and I will go back and check/fix all
the
> whitespace errors and recommit it.

No, we don't remove commits from master.  That's a recipe for disaster.  Just
make some followup commit.  The whitespace alone would not need a review I
guess.

> I don't recall complaints from git about whitespace when I applied the patch
to
> my local copy of stable

Git does not as such complain about whitespace: after all, it is a legit part of
files and Git has no way to guess when it is unwanted.

> nor did I notice any excessive whitespace chars in my
> editor (I use Geany).

No idea whether it gives indication unless asked.

> I have closed this issue (after I commited) so I can redo a new issue, it's
not
> a huge deal for me.

If you go for a review, that's the clean path.  One can reopen an issue, but
that's making things a lot muddier since there already are committed changes in
master.