Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

Joram Berger wrote > Will it also look good for custom key signatures? Hi Joram, Well, in your example, there will be no difference between the old and new coding: The first two naturals with full overlap get a maximum extra padding of 0.3, the second and third naturals are (vertically) so far

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

Will it also look good for custom key signatures? \relative { \set Staff.keyAlterations = #`((6 . ,FLAT) (5 . ,FLAT) (3 . ,SHARP)) c'4 d e fis aes4 bes c2 \key c \major c } Best, Joram

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

On 2018/04/24 21:49:37, Carl wrote: On 2018/04/24 18:43:45, Be-3 wrote: > The intervals are just *approximating* the outlines of a run-of-the mill > natural glyph. I even played around with the concept using squared paper. > This approach more or less relies on the fact that the

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

On 2018/04/24 18:43:45, Be-3 wrote: The intervals are just *approximating* the outlines of a run-of-the mill natural glyph. I even played around with the concept using squared paper. This approach more or less relies on the fact that the square/parallelogram part of a natural glyph will

Re: parser.yy / grammar

Am 24.04.2018 um 21:16 schrieb David Kastrup: \version "2.21.0" \score{ { c'2 } \addlyrics { Hi there } \layout {}} \score{ { c'2 } \addlyrics \displayLilyMusic { Hi there } \layout {}} \score{ { c'2 } \addlyrics { \displayLilyMusic { Hi there } }

Re: parser.yy / grammar

Knut Petersen writes: > Hi David! >> \addlyrics \displayLilyMusic { Hi there! } >> >> would not work with your proposed patch while >> >> \addlyrics { Hi there! } >> >> does. There is no conceivable reason for the user why this should be >> so. > > Really?

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

On 2018/04/24 17:59:31, Carl wrote: LGTM. I am just a *little* bit concerned about having the dimensions of the Emmentaler natural glyph hardcoded in the source, but we already have magic numbers reflecting the characteristics of the Emmentaler glyphs. Maybe it would be good to put a

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

LGTM. I am just a *little* bit concerned about having the dimensions of the Emmentaler natural glyph hardcoded in the source, but we already have magic numbers reflecting the characteristics of the Emmentaler glyphs. Maybe it would be good to put a FIXME in recognizing this fact. Or maybe we

issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

Reviewers: , Message: Please review... Thanks, Torsten PS: no new regression test needed, there are loads of key cancellations in the existing regression tests. Description: issue 5312: Key cancellation glyph position inconsistent file lily/key-signature-interface.cc Using two intervals

Re: parser.yy / grammar

Hi David! \addlyrics \displayLilyMusic { Hi there! } would not work with your proposed patch while \addlyrics { Hi there! } does. There is no conceivable reason for the user why this should be so. Really? \displayLilyMusic after \addlyrics breaks the syntax rules. So let's have a look at

Re: parser.yy / grammar

Knut Petersen writes: > Am 24.04.2018 um 13:46 schrieb David Kastrup: >> >> parser.yy is actually quite explicit here: >> >> // We must not have lookahead tokens parsed in lyric mode. In order >> // to save confusion, we take almost the same set as permitted with >>

Re: parser.yy / grammar

Am 24.04.2018 um 13:46 schrieb David Kastrup: parser.yy is actually quite explicit here: // We must not have lookahead tokens parsed in lyric mode. In order // to save confusion, we take almost the same set as permitted with // \lyricmode and/or \lyrics. However, music identifiers are also

Re: parser.yy / grammar

Knut Petersen writes: > Hi everybody! > > Is there a reason not to allow MUSIC_FUNCTIONs whenever > MUSIC_IDENTIFIERs are allowed? Yes. > One example is \addlyrics. It only accepts grouped_music_lists and > MUSIC_IDENTIFIERs ... Intentionally so. \addlyrics is a

Re: \unfoldRepeats type none

Knut Petersen writes: > Am 23.04.2018 um 14:21 schrieb David Kastrup: >> >> Huh. I'd rather have #f stand for the default, and '() for none. That >> seems like a saner interface since an empty list carries obvious >> meaning. >> >> Not backwards-compatible but I

PATCHES - Countdown for April 24th

Hello, Here is the current patch countdown list. The next countdown will be on April 27th. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Push: 5308 Context code maintenance - Dan Eble

Re: parser.yy / grammar

Is there a reason not to allow MUSIC_FUNCTIONs whenever MUSIC_IDENTIFIERs are allowed? One example is \addlyrics. It only accepts grouped_music_lists and MUSIC_IDENTIFIERs ... I think this patch would be enough ... Knut >From bd9ac344b02eb908d9536e3679050e0b7eca3ab9 Mon Sep 17 00:00:00

parser.yy / grammar

Hi everybody! Is there a reason not to allow MUSIC_FUNCTIONs whenever MUSIC_IDENTIFIERs are allowed? One example is \addlyrics. It only accepts grouped_music_lists and MUSIC_IDENTIFIERs ... Knut ___ lilypond-devel mailing list

Re: \unfoldRepeats type none

Am 23.04.2018 um 14:21 schrieb David Kastrup: Huh. I'd rather have #f stand for the default, and '() for none. That seems like a saner interface since an empty list carries obvious meaning. Not backwards-compatible but I think this one has not been released in a stable release yet. But it