Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

> > I think it is unfair to put this burden on us developers > for the 2.25.xx series. Fair enough. I was mainly thinking it could be worthwhile for the developers' sake to reduce the number of email threads from users taken by surprise when their code stops working. A fair amount of time seems t

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

Isn't that the reason that the changes documentation is written in the first place...to warn users about upcoming changes? So an extra warning in the email would be redundant, and this warning would also fade into the background? (by the way, I don't think that comparatively a _lot_

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

>> Do you think this isn't prominently enough? If so, how could this >> be improved? > > I think that as with many warnings, the fact that it's always there > leads to it fading into the background for many readers, > particularly as they learn from experience that for *most* code, > *most* of

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

> > Isn't that the reason that the changes documentation is written in the > first place...to warn users about upcoming changes? So an extra warning > in the email would be redundant, and this warning would also fade into > the background? (by the way, I don't think that

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

> > Do you think this isn't prominently enough? If so, how could this be > improved? > I think that as with many warnings, the fact that it's always there leads to it fading into the background for many readers, particularly as they learn from experience that for *most* code, *most* of the time,

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

that users should expect to need > convert-ly. This is in a warning box on page 1 of `changes.pdf`, as is https://lilypond.org/doc/v2.24/Documentation/changes/index.html https://lilypond.org/doc/v2.25/Documentation/changes/index.html Do you think this isn't prominently enough?

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

> > if you have reasonable ideas how such API changes could be > communicated better I am sure people would love to hear them and if > feasible > incorporate them. IMO one relatively simple change would be to add a note to the release announcement email mentioning that users should expect to need

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

On 2025-02-09 06:32, Valentin Petzel wrote: the new property is there to allow for convert-ly to automatically make old things work. I just do not fully understand why it is necessary and could not simply be handled by adding a conversion function, e.g. turing something like `...proportionalNota

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

AFAIK a normal user should see a warning for a deprecated property and an error for an API break. This is not the case: the user here sees a warning for an API break. Fortunately, out of deliberate fussiness, I made sure that my test cases already stop corresponding to warnings rather than just

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

have simply ignored > the warning. the new property is there to allow for convert-ly to automatically make old things work. I just do not fully understand why it is necessary and could not simply be handled by adding a conversion function, e.g. turing something like `...proportionalNotationDura

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

>> proportionalNotationDuration is not deprecated. Its type has been >> changed, therefore the warning about not accepting a moment is correct. > > that's what I was saying. Wouldn't it have been better to treat it > as a deprecated property with an appropriate w

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

that's what I was saying. Wouldn't it have been better to treat it as a deprecated property with an appropriate warning, rather than as an API break with a warning instead of an error? Given that, as Valentin noted, a new property has been introduced that allows code to be compiled wi

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

On 2025-02-08 19:45, Paolo Prete wrote: This is not the case. In fact, the raised warning says: "warning: the property 'proportionalNotationDuration' must be of type 'non-negative exact rational or +inf.0', ignoring invalid value '# proportionalNotationDuration is

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

On 2025-02-08 20:28, Valentin Petzel wrote:> I just don’t get how adding a new property that is not supposed to be used is perferable to simply add the conversion directly to the convert-ly rule. It is difficult -- not simple -- to write perfect conversions. The "AsMoment" properties allow a

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

ing agnostic of the LilyPond version and supports multiple LilyPonds: https://github.com/paopre/Spontini For this reason I asked the question and because of the problem reported in this thread I am forced to add the workaround that Valentin pasted, while I could have left the code as it is and ignored the appropriate warning Cheers, P

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

Hello Saul, > The deprecated > properties provide a way for convert-ly to modify code so it still compiles > without requiring automatic conversions applied to potentially arbitrary > Scheme code. The deprecated syntax is in fact automatically converted. I just don’t get how adding a new propert

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

d with convert-ly, compiling it will print deprecation errors so that users are aware they need to convert the values to exact rationals going forward. The goal being not that users wrap their code in type conversions, but actually update the type used. ...while a proper warning to a deprecated f

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

been considered bad and will be > removed in a future release. > Hello Valentin, I totally agree with you. And I add an observation: if an API is deprecated, it should be clear to the user that it is actually deprecated. This is not the case. In fact, the raised warning says: "warning:

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

Hello Saul, > I don't want to speak for Dan, but I believe the objective is to get user > code moved over to actually using exact rationals rather than moments for > these properties, not just to allow the use of exact rationals in addition > to moments. This is not what I talked about. My point

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

I don't want to speak for Dan, but I believe the objective is to get user code moved over to actually using exact rationals rather than moments for these properties, not just to allow the use of exact rationals in addition to moments. It's worth pointing out that there were extended discussions on

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

Hello Paolo, > Why has forward compatibility not been ensured for this function? The relevant merge request is this one: https://gitlab.com/lilypond/lilypond/-/merge_requests/2546 As you can see this one also introduces a compatibilty property `proportionalNotationDurationAsMoment` and a conve

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

LilyPond has never guaranteed backward compatibility of its API between versions, except for minor versions of the same stable release. It's usually the case that between any given two versions only a small subset of code requires changes, but you should always assume that when upgrading to a new L

Re: \set Score.proportionalNotationDuration warning on LilyPond 2.25.23

Thanks Valentin, I will definitely use it in my code. But this API change leaves me a bit perplexed. It's the first one I've encountered since LilyPond 2.19.84! For this reason I am crossposting this message with the devel mailing list. Why has forward compatibility not been ensured for this functi

Re: Warning during 'make doc'

> While building the docs, I encounter a number of warnings > > WARNING: The convert command is deprecated in IMv7, use "magick" > instead of "convert" or "magick convert" This is new – and confusing: for example, I have ImageMagick 7.1.0-9 install

Warning during 'make doc'

Hi all, While building the docs, I encounter a number of warnings WARNING: The convert command is deprecated in IMv7, use "magick" instead of "convert" or "magick convert" when in Documentation/out-www/ly-examples/ and Documentation/out-www/pictures/ Do I ha

Re: Backslashes in @warning

Le 22/10/2022 à 16:45, Jean Abou Samra a écrit : I'm going to create an issue for that. https://gitlab.com/lilypond/lilypond/-/issues/6443

Re: Backslashes in @warning

>> We could define a macro `@bscode`, to be used in `@warning` only. Add >> the following to `common-macros.itely` >> >> ``` >> @macro bscode{TEXT} >> @code{\\\TEXT\} >> @end macro >> ``` > > Honestly, if there isn't a way to fix @w

Re: Backslashes in @warning

Le 22/10/2022 à 16:42, Werner LEMBERG a écrit : We could define a macro `@bscode`, to be used in `@warning` only. Add the following to `common-macros.itely` ``` @macro bscode{TEXT} @code{\\\TEXT\} @end macro ``` Honestly, if there isn't a way to fix @warning globally, I think it is si

Re: Backslashes in @warning

We could define a macro `@bscode`, to be used in `@warning` only. Add the following to `common-macros.itely` ``` @macro bscode{TEXT} @code{\\\TEXT\} @end macro ``` and use it as follows. ``` @warning{This is a warning with the @bscode{foo} command.} ``` Honestly, if there isn't a

Re: Backslashes in @warning

lashes in the PDF. We could define a macro `@bscode`, to be used in `@warning` only. Add the following to `common-macros.itely` ``` @macro bscode{TEXT} @code{\\\TEXT\} @end macro ``` and use it as follows. ``` @warning{This is a warning with the @bscode{foo} command.} ``` Werner

Re: Backslashes in @warning

Le 22/10/2022 à 12:02, Jean-Charles Malahieude a écrit : You just have to "escape" it, like in texidocs: @code{\\textMark} et @code{\\textEndMark} I'll prepare a MR later today for text.itely. If I do that, the backslash does appear in HTML, but there are two backslashes in the PDF.

Re: Backslashes in @warning

on of texi2html 1.82. Can this be worked around somehow? I can confirm this problem with a local build; it seems indeed to be a bug in the old texi2html version, which swallows backslashes in `@warning{...@code{...}...}`. Alas, I don't know how to fix it. You just have to "escape"

Re: Backslashes in @warning

1.82. > > Can this be worked around somehow? I can confirm this problem with a local build; it seems indeed to be a bug in the old texi2html version, which swallows backslashes in `@warning{...@code{...}...}`. Alas, I don't know how to fix it. Werner

Backslashes in @warning

fine. The corresponding Texinfo source is @warning{Older LilyPond versions used the @code{\mark} command for text marks, even though it is primarily intended for rehearsal marks (@pxref{Rehearsal marks}).  The @code{\textMark} and [...] and the definition of @warning in macros.texi is @ifht

Re: Use of ly:expect-warning in regtests

Hello On 02/10/2020 14:34, Michael Käppler wrote: Maybe James can tell us, why running the regtests with 'warning-as-error #t was never realized. I cannot. I was never part of those decisions. Sorry. James

Re: Use of ly:expect-warning in regtests

Am 02.10.2020 um 14:38 schrieb Dan Eble: Mostly they set it to #f: git grep "(ly:set-option 'warning-as-error #f" input/regression/* | wc -l 39 I don't know the history behind that, but it doesn't seem useful. It could be a mistake. I think I got it. At first there

Re: Use of ly:expect-warning in regtests

On Oct 2, 2020, at 08:24, Michael Käppler wrote: > > Other regtests, however, use ly:expect-warning to suppress these > warnings and output a new warning instead, if > the expected warning is missing. ... > Some use ly:expect-warning in combination with ly:set-option >

Use of ly:expect-warning in regtests

Hi all, while fixing the issue Dan brought up (ottavation markups and MIDI output) and looking through the existing regtest ottavation-markups.ly, I noticed that it does output a warning (as intended). Other regtests, however, use ly:expect-warning to suppress these warnings and output a new

Re: GitLab CI: warning about C059-BdIta.otf

Am Mittwoch, den 27.05.2020, 23:52 +0200 schrieb Davide Liessi: > Dear Jonas, > > I noticed in the log of test and documentation builds in GitLab CI the > following message: > > WARNING: build/out/share/lilypond/current/fonts/otf/C059-BdIta.otf: > chmod build/out/share/lilyp

GitLab CI: warning about C059-BdIta.otf

Dear Jonas, I noticed in the log of test and documentation builds in GitLab CI the following message: WARNING: build/out/share/lilypond/current/fonts/otf/C059-BdIta.otf: chmod build/out/share/lilypond/current/fonts/otf/C059-BdIta.otf: no such file or directory (suppressing repeats) Is it

Ghostcript warning about LinLibertine0 during make doc

Hello, While doing some sanity tests this morning building doc (making sure everything works for me for testing with new infrastructure) I spent more time looking at the terminal window than I usually do. During the make doc part where the 'page numbers' all whiz by I noticed occasionally I'

Re: Remove last compiler warning patch

writes: > > > Patch to remove warning in flex generated code. > > > > This patch together with the previous 2 patches I have sent, remove all > compiler warnings while compiling lilypond on my machine (Debian 64 buster). Just so that you don't feel like you a

Remove last compiler warning patch

Patch to remove warning in flex generated code. This patch together with the previous 2 patches I have sent, remove all compiler warnings while compiling lilypond on my machine (Debian 64 buster). Jaap de Wolff >From 9cb9dbf8d91194c13a6331ab482b6bc5b2e3895c Mon Sep 17 00:00:00 2

Re: Annoying 'langdefs.py' warning

Le 26/04/2020 à 09:46, Jonas Hahnfeld a écrit : Am Samstag, den 25.04.2020, 21:53 +0200 schrieb Francisco Vila: El 24/4/20 a las 17:18, Jonas Hahnfeld escribió: However I'm pretty sure that many translations in the latter are dead: As far as I understand we don't translate the docs by putting t

Remove define causing a warning (issue 561790043 by jonas.hahnf...@gmail.com)

LGTM https://codereview.appspot.com/561790043/

Re: Annoying 'langdefs.py' warning

Am Samstag, den 25.04.2020, 21:53 +0200 schrieb Francisco Vila: > El 24/4/20 a las 17:18, Jonas Hahnfeld escribió: > > However I'm pretty sure that many translations in the latter are dead: > > As far as I understand we don't translate the docs by putting the > > strings in Documentation/po, but ra

Re: Annoying 'langdefs.py' warning

El 24/4/20 a las 17:18, Jonas Hahnfeld escribió: However I'm pretty sure that many translations in the latter are dead: As far as I understand we don't translate the docs by putting the strings in Documentation/po, but rather by copying the files and translating them below Documentation/lang. D

Re: Annoying 'langdefs.py' warning

ne that it's now easier > to handle both problems. > > > IIRC langdefs.py complains that we set LANG=C in the build > > process. Not really sure what the correct solution is, could be as > > easy as removing the warning (don't scream at me if not...) > >

Re: Annoying 'langdefs.py' warning

> It loads its languages from langdefs.py, and therefore outputs the > following unhelpful warning: > > langdefs.py: warning: lilypond-doc gettext domain not found. > > I understand 'therefore' as 'expectedly' here. Well, yes, but it's still anno

Re: Annoying 'langdefs.py' warning

reate-weblinks-itexi.py creates a load of texi macros (of the order of > 1000) similar to: > > (...) > > It loads its languages from langdefs.py, and therefore outputs the > following unhelpful warning: > > langdefs.py: warning: lilypond-doc gettext domain not f

Re: Annoying 'langdefs.py' warning

languages from langdefs.py, and therefore outputs the following unhelpful warning: langdefs.py: warning: lilypond-doc gettext domain not found. % I understand 'therefore' as 'expectedly' here. http://lilypond.org/doc/v2.19/Documentation/contributor/website-buil

Re: Annoying 'langdefs.py' warning

e set LANG=C in the build > process. Not really sure what the correct solution is, could be as > easy as removing the warning (don't scream at me if not...) :-) > [...] If nobody objects, I can probably prepare a patch (obvious > caveat: take care of values used from > stepmake/

Re: Annoying 'langdefs.py' warning

>> [...] Is there a way to suppress them? > > I’ve been annoyed by these for quite some time as well. Is it worth > opening a tracker page? For me, it's not *that* annoying :-) Werner

Re: Annoying 'langdefs.py' warning

Am Donnerstag, den 16.04.2020, 12:14 +0200 schrieb Werner LEMBERG: > Building lilypond you get a bunch of harmless but annoying > > langdefs.py: warning: lilypond-doc gettext domain not found. > > and > > .../podir-targets.make:14: warning: ignoring old recipe for

Re: Annoying 'langdefs.py' warning

Le 19/04/2020 à 16:17, Valentin Villenave a écrit : On 4/16/20, Werner LEMBERG wrote: Building lilypond you get a bunch of harmless but annoying langdefs.py: warning: lilypond-doc gettext domain not found. and .../podir-targets.make:14: warning: ignoring old recipe for target 'po-u

Re: Annoying 'langdefs.py' warning

On 4/16/20, Werner LEMBERG wrote: > Building lilypond you get a bunch of harmless but annoying > langdefs.py: warning: lilypond-doc gettext domain not found. > and > .../podir-targets.make:14: warning: ignoring old recipe for target > 'po-update' > messages. Is

Annoying 'langdefs.py' warning

Building lilypond you get a bunch of harmless but annoying langdefs.py: warning: lilypond-doc gettext domain not found. and .../podir-targets.make:14: warning: ignoring old recipe for target 'po-update' messages. Is there a way to suppress them? Werner

slur-configuration: fix size_t conversion warning (issue 545860043 by hanw...@gmail.com)

LGTM https://codereview.appspot.com/545860043/

Re: Issue 5705: Cast to silence warning in Stem::get_beaming () (issue 565610043 by nine.fierce.ball...@gmail.com)

Reviewers: hanwenn, Message: In the review for the first attempt, David wrote: > It's probably more an academical remark, but a "kosher" way of doing that might > be using scm_to_int (scm_length (...)) instead of scm_ilength (...). etc. I'll make this change because setting a good example is valu

Issue 5705: Cast to silence warning in Stem::get_beaming () (issue 565610043 by nine.fierce.ball...@gmail.com)

LGTM thanks! https://codereview.appspot.com/565610043/diff/559450051/lily/stem.cc File lily/stem.cc (right): https://codereview.appspot.com/565610043/diff/559450051/lily/stem.cc#newcode99 lily/stem.cc:99: // we confident that the list is short? Yes, I'm confident about that. // This list repre

Re: configure: Fix tests for compiler warning flags. (issue 551210043 by lemzw...@googlemail.com)

ture... For example, we could mark is as a hack even more prominently than the 'urg' notice. But maybe you are working on this right now :-) Description: configure: Fix tests for compiler warning flags. `AC_LANG_PROGRAM` ignores compiler warnings. This behaviour made the tests always

configure: Fix tests for compiler warning flags. (issue 551210043 by lemzw...@googlemail.com)

I don't think we should go this hacky way. For Clang I'm already fixing this issue with https://sourceforge.net/p/testlilyissues/issues/5608/ (Especially the confdefs.h should be fixed correctly, by untangling AutoConf and StepMake and not define the macro twice in the first place.) https://code

Re: Issue 5588: fix color-profile warning in output-distance (issue 545100043 by nine.fierce.ball...@gmail.com)

LGTM https://codereview.appspot.com/545100043/

Re: Issue 5588: fix color-profile warning in output-distance (issue 545100043 by nine.fierce.ball...@gmail.com)

LGTM https://codereview.appspot.com/545100043/diff/545110043/scripts/build/output-distance.py File scripts/build/output-distance.py (right): https://codereview.appspot.com/545100043/diff/545110043/scripts/build/output-distance.py#newcode100 scripts/build/output-distance.py:100: system ('convert

Issue 5588: fix color-profile warning in output-distance (issue 545100043 by nine.fierce.ball...@gmail.com)

Reviewers: , Description: https://sourceforge.net/p/testlilyissues/issues/5588/ The warning is "RGB color space not permitted on grayscale PNG" and the solution is to strip the profile from the image. Please review this at https://codereview.appspot.com/545100043/ Affected files (+4

Re: make distclean now posts warning since commit b7532cf6e6d9

e 2>&1 | tee make_output.txt And I conclude from the following that those warnings were there before. They’re probably more noticeable now that the output isn’t so profuse. $ grep "overriding recipe" make_output.txt /home/user/lilypond-src/./input/regression/lilypond-

make distclean now posts warning since commit b7532cf6e6d9

1 I get the following messages - that I never used to get - when I run a make distclean --snip-- GNUmakefile:22: warning: overriding recipe for target 'local-test' ../../../make/lysdoc-targets.make:12: warning: ignoring old recipe for target 'local-test' GNUmakefile:25: w

Add warning message for unknown code in fret-diagram-verbose (issue 570540043 by carl.d.soren...@gmail.com)

https://codereview.appspot.com/570540043/diff/548530043/scm/fret-diagrams.scm File scm/fret-diagrams.scm (right): https://codereview.appspot.com/570540043/diff/548530043/scm/fret-diagrams.scm#newcode267 scm/fret-diagrams.scm:267: (symbol->string my-code symbol->string relies on my-code bei

Re: Issue 5485: avoid -Wsequence-point warning (issue 351880043 by lilyp...@maltemeyn.de)

On 2019/02/28 14:22:35, Malte Meyn wrote: Make it (nearly) as efficient as it was before. “nearly” because (!line_breakable || !page_breakable) might need only the line_breakable lookup. But I thought we have enough “if”s here already … https://codereview.appspot.com/351880043/ ___

Re: Issue 5485: avoid -Wsequence-point warning (issue 351880043 by lilyp...@maltemeyn.de)

https://codereview.appspot.com/351880043/diff/20001/lily/page-turn-page-breaking.cc File lily/page-turn-page-breaking.cc (right): https://codereview.appspot.com/351880043/diff/20001/lily/page-turn-page-breaking.cc#newcode37 lily/page-turn-page-breaking.cc:37: bool page_breakable = scm_is_symbol

Re: Issue 5485: avoid -Wsequence-point warning (issue 351880043 by lilyp...@maltemeyn.de)

Greetings Malte, nice catch! I’d been struggling with it for a while. I believe that’s the last GCC warning we had (other than -Wconversion warnings, of which there still are many). V. https://codereview.appspot.com/351880043/ ___ lilypond-devel

Re: Octave check warning

Or even: warning: octave check failed; expected: "a", found: "a," or warning: octave check failed; expected "a" found "a," which are at least consistent. But I have to say that it has never worried me. -- Sent from: http://lilypo

Octave check warning

Hello, here’s a kind of pet peeve of mine: With a warning like warning: octave check failed; expected "a", found: "a," I always have to look twice what the difference between the two is. It might be easier to read as warning: octave check failed; expected "a"

Improve warning for unattached post-event(s) (issue 328630043 by d...@gnu.org)

I'm not capable to review parser-code. But from description: LGTM https://codereview.appspot.com/328630043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: warning: compressing over-full page by 12.4 staff-spaces

Lilypond] Sent: Wednesday, February 8, 2017 6:27 PM To: oldsap Subject: Re: warning: compressing over-full page by 12.4 staff-spaces Hi, first on a technical note: Many do not use the Nabble interface and they can’t see to which old thread you are replying. It’s more helpful to just open a

Re: warning: compressing over-full page by 12.4 staff-spaces

Hi, first on a technical note: Many do not use the Nabble interface and they can’t see to which old thread you are replying. It’s more helpful to just open a new one. On 08.02.2017 19:22, oldsap wrote: I see this problem as well. The log message is: warning: compressing over-full page by

Re: warning: compressing over-full page by 12.4 staff-spaces

I see this problem as well. The log message is: warning: compressing over-full page by 31.9 staff-spaces warning: page 5 has been compressed This generates one system at the top of page 5 with signs of compression in the lowest staff, then leaves a huge empty space, then a highly compressed

Fix the warning message for OTC fonts (issue 300650043 by truer...@gmail.com)

LGTM https://codereview.appspot.com/300650043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Protected_scm warning: returning reference to temporary

On Jun 13, 2016, at 18:37 , David Kastrup wrote: > > Anyway, I'll push a fix. Can you check again in 5 minutes? No more warnings from protected-scm. Thanks, — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman

Re: Protected_scm warning: returning reference to temporary

Dan Eble writes: > I noticed these errors building staging in lilydev 3.0: > >> /home/dan/lilypond-git/lily/protected-scm.cc: In member function >> 'Protected_scm::operator scm_unused_struct* const&() const': >> /home/dan/lilypond-git/lily/protected-scm.cc:

Protected_scm warning: returning reference to temporary

I noticed these errors building staging in lilydev 3.0: > /home/dan/lilypond-git/lily/protected-scm.cc: In member function > 'Protected_scm::operator scm_unused_struct* const&() const': > /home/dan/lilypond-git/lily/protected-scm.cc:75:56: warning: returning > referenc

Re: Doc Issue 4350: \compressFullBarRests needs a warning (issue 227470043 by tdanielsmu...@googlemail.com)

ve showing how a score and parts was built up. So it would have required a rather more invasive change. Instead, I gave the reference to the section in the NR which does indeed give several examples of consecutive MM rests. Description: Doc Issue 4350: \compressFullBarRests needs a warn

Doc Issue 4350: \compressFullBarRests needs a warning (issue 227470043 by tdanielsmu...@googlemail.com)

Otherwise, LGTM https://codereview.appspot.com/227470043/diff/1/Documentation/learning/fundamental.itely File Documentation/learning/fundamental.itely (right): https://codereview.appspot.com/227470043/diff/1/Documentation/learning/fundamental.itely#newcode3193 Documentation/learning/fundamental

Doc: Issue 4309: Clarify the warning about bare durations (issue 203640043 by tdanielsmu...@googlemail.com)

Reviewers: , Message: Pushed to staging as 67e08daacdeb384724e18a31597d9d828ac40f51 Closing ... Description: Doc: Issue 4309: Clarify the warning about bare durations Please review this at https://codereview.appspot.com/203640043/ Affected files (+4, -4 lines): M Documentation/learning

Re: warning: compressing over-full page by 12.4 staff-spaces

Urs Liska writes: > Am 14.11.2014 17:20, schrieb David Kastrup: >> What's up with >> >> warning: compressing over-full page by 12.4 staff-spaces >> >> here? There is more than enough space to put one system more to the >> next page, and 12 staff

Re: warning: compressing over-full page by 12.4 staff-spaces

Am 14.11.2014 17:20, schrieb David Kastrup: What's up with warning: compressing over-full page by 12.4 staff-spaces here? There is more than enough space to put one system more to the next page, and 12 staff spaces? Page breaks are supposed to be done with full skylines, aren&#

warning: compressing over-full page by 12.4 staff-spaces

What's up with warning: compressing over-full page by 12.4 staff-spaces here? There is more than enough space to put one system more to the next page, and 12 staff spaces? Page breaks are supposed to be done with full skylines, aren't they? Sorry for the entirely non-minimal ex

Re: Doc: Issue 3324: Add explanation of clashing note columns warning (issue 154640043 by tdanielsmu...@googlemail.com)

On Thu, 23 Oct 2014 02:43:56 -0700, wrote: On 2014/10/22 05:58:54, Keith wrote: I have been thinking that when the user gives explicit \voiceOne or \shiftOn to the voices, Lily should set those voices at the shifts requested, even if two voices have the same shift I had forgotten that I a

Re: Doc: Issue 3324: Add explanation of clashing note columns warning (issue 154640043 by tdanielsmu...@googlemail.com)

entioned in the LM and NR. Description: Doc: Issue 3324: Add explanation of clashing note columns warning Please review this at https://codereview.appspot.com/154640043/ Affected files (+37, -0 lines): M Documentation/usage/running.itely Index: Documentation/usage/running.itely diff --

Doc: Issue 3324: Add explanation of clashing note columns warning (issue 154640043 by tdanielsmu...@googlemail.com)

LGTM Just for your interest, I have been thinking that when the user gives explicit \voiceOne or \shiftOn to the voices, Lily should set those voices at the shifts requested, even if two voices have the same shift Currently users are required to set 'ig

Re: Let \time in mid-measure work without warning in some cases (issue 143450043 by nine.fierce.ball...@gmail.com)

Now a warning is only issued when there is an event for the time change. This is the final draft, I hope. https://codereview.appspot.com/143450043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond

Re: Let \time in mid-measure work without warning in some cases (issue 143450043 by nine.fierce.ball...@gmail.com)

On 2014/09/28 06:49:08, dak wrote: On 2014/09/28 06:33:12, dak wrote: > Uh, to answer your question: easy way: probably not really. But if you make an > extra issue "Make \tweak work on \time", your current code will magically create > the warning pointing to the sour

Re: Let \time in mid-measure work without warning in some cases (issue 143450043 by nine.fierce.ball...@gmail.com)

On 2014/09/28 06:33:12, dak wrote: Uh, to answer your question: easy way: probably not really. But if you make an extra issue "Make \tweak work on \time", your current code will magically create the warning pointing to the source as a side effect. Tell you what: that change i

Re: Let \time in mid-measure work without warning in some cases (issue 143450043 by nine.fierce.ball...@gmail.com)

d...@gnu.org writes: > You don't have the cause argument of time_signature_ available, however, > since the Time_signature_engraver answers to events. Argh! ... since the Time_signature_engraver does _not_ answer to events but to property changes. > https://codereview.appspot.com/143450043/ --

Re: Let \time in mid-measure work without warning in some cases (issue 143450043 by nine.fierce.ball...@gmail.com)

) && scm_is_true (partialBusy))) if (!to_boolean (get_property ("partialBusy"))) is the standard way we check for boolean properties. https://codereview.appspot.com/143450043/diff/60001/lily/time-signature-engraver.cc#newcode104 lily/time-signature-engraver.cc:104: time_signa

Re: Let \time in mid-measure work without warning in some cases (issue 143450043 by nine.fierce.ball...@gmail.com)

Now there is a warning if \time is used mid-measure without \partial. Order is not important. I have no more changes planned except to respond to whatever feedback you provide. I added a boolean context property. I experimented with special values for existing properties, but found nothing as

Re: Let \time in mid-measure work without warning in some cases (issue 143450043 by nine.fierce.ball...@gmail.com)

immediately) resets this flag. I don't see a good reliable way of cranking out a warning without prescribing a particular order of \partial and \time. https://codereview.appspot.com/143450043/diff/40001/Documentation/notation/rhythms.itely File Documentation/notation/rhythms.itely (right):

Re: Let \time in mid-measure work without warning in some cases (issue 143450043 by nine.fierce.ball...@gmail.com)

David, what do you think about adding a context property which \time sets when it is called in mid-measure, which \partial resets, and about which bar checks warn if it is set? https://codereview.appspot.com/143450043/diff/40001/Documentation/notation/rhythms.itely File Documentation/notation/rh

Re: Let \time in mid-measure work without warning in some cases (issue 143450043 by nine.fierce.ball...@gmail.com)

Documentation changes are ready for review. I didn't think much needed to be said. I also fixed up some inconsistencies in the index terms. https://codereview.appspot.com/143450043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists

Re: Let \time in mid-measure work without warning in some cases (issue 143450043 by nine.fierce.ball...@gmail.com)

whether the \partial is before or after the \time. So the start of the piece is no exception. So it's rather "Time signature changes not followed by a complete measure should be accompanied by a corresponding \partial". In experimenting around, I found that the (warning

  1   2   3   4   >