lilypond-devel
[Top][All Lists]
Advanced

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

Re: \compressFullBarRests should be renamed (issue 553750044 by address@


From: v . villenave
Subject: Re: \compressFullBarRests should be renamed (issue 553750044 by address@hidden)
Date: Tue, 24 Mar 2020 15:28:22 -0700

Reviewers: lemzwerg, Trevor Daniels,

Message:
Thanks guys, it means a lot! (Particularly from Trevor, who opened the
tracker page in the first place.)

Since I had both your LGTMs, I’ve pushed my patch onto staging as
http://git.savannah.gnu.org/cgit/lilypond.git/commit/?h=staging&id=83045b846acb4aaadf54373941a915c4c45fb522
(then I realized the review window was technically still open until
tomorrow. Sorry about that.)

I’ve taken into account all your suggestions, with only a couple of
additional comments:

On 2020/03/21 18:27:07, lemzwerg wrote:
> I guess you refer to the `measure-length` property, right?  If this is
correct,
> then you should write `@code{measure-length}` instead.

Hm.  Measure-length was the wording used so far, but it’s really more of
an internal property than something we want to emphasize as
user-exposed; it’s not documented anywhere in the NR other than through
grob-properties.scm (not even a regtest).  So I’d rather rewrite the
sentence as "the length of a measure", which is wordier but a bit
clearer I think.

> why @var?

’coz I keep misreading the CG :-/

On 2020/03/22 11:07:23, Trevor Daniels wrote:
> Thanks for picking this up and taking it over the finishing line,
Valentin.

My pleasure.  Hopefully I’ll be able to contribute a bit more in the
next few weeks… 
I hope you’re well; take good care of yourself… and stay away from
London!

Cheers,
V.

Description:
\compressFullBarRests should be renamed

- Rename \compressFullBarRests to \compressEmptyMeasures
as suggested by Trevor in #4375.

- Document the new command (and explain its difference
with \compressMMRests) by creating a new subsubsec in
NR 1.6.3 "Writing parts".

- Add index entries and links everywhere I can think of,
obviously starting with NR 1.2.2.3 "Full measure rests".

- Add convert rule and update syntax through the doc.

- Clarify the (in)famous progerror
"Multi_measure_rest::get_rods (): I am not spanned!"
since a) the function it refers to has changed anyway
b) its wording’s never been particularly helpful IMO.

- This patch will require po-update and makelsr at
some point (and snippets/new should be checked for
duplicate stuff now that the LSR’s been updated).

Please review this at https://codereview.appspot.com/553750044/

Affected files (+196, -98 lines):
  M Documentation/changes.tely
  M Documentation/de/changes.tely
  M Documentation/de/notation/changing-defaults.itely
  M Documentation/de/notation/rhythms.itely
  M Documentation/de/notation/staff.itely
  M Documentation/fr/changes.tely
  M Documentation/it/changes.tely
  M Documentation/ja/changes.tely
  M Documentation/ja/notation/rhythms.itely
  M Documentation/notation/ancient.itely
  M Documentation/notation/changing-defaults.itely
  M Documentation/notation/rhythms.itely
  M Documentation/notation/staff.itely
  M Documentation/snippets/multi-measure-rest-length-control.ly
  M Documentation/snippets/new/multi-measure-rest-length-control.ly
  A + Documentation/snippets/new/numbering-single-measure-rests.ly
  M Documentation/snippets/numbering-single-measure-rests.ly
  M input/regression/merge-rests-engraver.ly
  M input/regression/merge-rests-magnify-staff.ly
  M input/regression/multi-measure-rest-number-threshold.ly
  M input/regression/rest-hanging-breve.ly
  M lily/multi-measure-rest.cc
  M ly/property-init.ly
  M python/convertrules.py





reply via email to

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