[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

Done it earlier, but missed the right git-cl config, hence no notification auto-generated here. Anyway, it's live at [Rietveld](https://codereview.appspot.com/313240043/#ps21) now. --- ** [issues:#4509] Enhancement: automatically engrave lyric extenders** **Status:** Started **Created:**

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

Sorry for being late to the party. Will do, albeit probably not before the evening. --- ** [issues:#4509] Enhancement: automatically engrave lyric extenders** **Status:** Started **Created:** Sat Jul 18, 2015 03:23 AM UTC by Anonymous **Last Updated:** Sun Feb 05, 2017 12:51 PM UTC **Owner:**

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

Alexander? You appear to own the Rietveld issue. Could you add this patch? --- ** [issues:#4509] Enhancement: automatically engrave lyric extenders** **Status:** Started **Created:** Sat Jul 18, 2015 03:23 AM UTC by Anonymous **Last Updated:** Thu Feb 02, 2017 10:36 AM UTC **Owner:**

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

This appears to be written on top of the existing patches, so it would make sense to put it on Rietveld on the existing review (which I have no write access to). It needs rebasing to current master because of issue 1375. Here would be the rebased patch (minus the whitespace error). --- **

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

"Alexander Kobel" writes: >> [...] if we made minimum-width obey its standard-behavior known from >> elsewhere [...] >> [...] Implementing a proper minimum width would help to solve some >> old issues ... [...] > > You are talking about a `minimum-width` that affects the

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

> [...] if we made minimum-width obey its standard-behavior known from > elsewhere [...] > [...] Implementing a proper minimum width would help to solve some old issues > ... [...] You are talking about a `minimum-width` that affects the horizontal spacing? I can't immediately see great

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

"Knut Petersen" writes: >> Ah, but one thing I thought I should mention: it occured to me if we >> made minimum-width obey its standard-behavior known from elsewhere (ok, >> elsewhere one needs to set some spacing-rods property in addition but >> probably noone will

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

> Ah, but one thing I thought I should mention: it occured to me if we > made minimum-width obey its standard-behavior known from elsewhere (ok, > elsewhere one needs to set some spacing-rods property in addition but > probably noone will notice), we would require no forced-width in > addition.

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

"David Kastrup" writes: > "Knut Petersen" writes: > >> This is a new version of the autoextender patch, based on current >> master. Documentation unchanged. >> >> There is a new boolean property no-auto-extenders. If set true it only >> allows forced

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

"Knut Petersen" writes: > This is a new version of the autoextender patch, based on current > master. Documentation unchanged. > > There is a new boolean property no-auto-extenders. If set true it only > allows forced extenders. > The double-underscore Extender token is

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

This is a new version of the autoextender patch, based on current master. Documentation unchanged. There is a new boolean property no-auto-extenders. If set true it only allows forced extenders. The double-underscore Extender token is revived and generates a forced extender. The result should

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

Hi David, hi Knut, hi all. On 2017-01-31 12:31, David Kastrup wrote: > "David Kastrup" da...@users.sf.net writes: > > "Alexander Kobel" ako...@users.sf.net > writes: > > Forced extenders are required for some manual tweaks

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

"Knut Petersen" writes: > @David: We all know that you were a valuable member of the lilypond > community for a long time. You were missed, and we are glad that you > are back in the pond although we wished you the best for the job you > tried. So don't feel too bad for

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

"David Kastrup" writes: > "Alexander Kobel" writes: > > >> Forced extenders are required for some manual tweaks or, again, >> special purposes such as lone notes before volta repeats, where an >> extender into the second repeat bracket needs to be

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

"Alexander Kobel" writes: > Argh, Ctrl-W ate my posting... Ctrl-Z did not restore it? > AFAICS, with your patch the LyricExtender engraving routines are > called irregardless of the existence of an ExtenderEvent, right? So an > ExtenderEvent doesn't have to appear even

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

Argh, Ctrl-W ate my posting... AFAICS, with your patch the LyricExtender engraving routines are called irregardless of the existence of an ExtenderEvent, right? So an ExtenderEvent doesn't have to appear even internally anymore? Sounds like the cleanest approach to me. Now, please don't get

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

> I wish you would have been in for that discussion a few days earlier, but of > course I know and understand the reasons why you're late to the party (and so > does everybody else, I'm sure). Well, I was busy with work that was a whole lot better paid while leaving me with rather little room

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

You've got mail. I wish you would have been in for that discussion a few days earlier, but of course I know and understand the reasons why you're late to the party (and so does everybody else, I'm sure). We already spent some thought about that; e.g., that's why we decided to keep `__` around

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

In a branch with an upstream, git send-email should work (assuming that a working Email system is set up). Otherwise, git format-patch and sending of all generated files as attachments. And I would not really call what I want to do "improvement": it's more like trying to provide the same kind

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

I guess so. I obviously have a local branch from which I git-cl'ed everything to Rietveld, but I have no write access to any official repo to open a branch. If you have a good suggestion how to hand over that code history entirely, let me know, but it's really nothing more than the diffs there.

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

> I'd like to have a pitch at making this a smoother change without sacrificing > its advantages. @David: I look forward to see your proposals. @pkx166h: I might be stupid, but I vote to give David a chance to present a patchset #10 ... --- ** [issues:#4509] Enhancement: automatically

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

Is there an actual branch to work with? Or is the best bet to check in all review diffs in sequence? --- ** [issues:#4509] Enhancement: automatically engrave lyric extenders** **Status:** Started **Created:** Sat Jul 18, 2015 03:23 AM UTC by Anonymous **Last Updated:** Sun Jan 29, 2017 11:39

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

Whether it is an improvement will likely be subject to debate. Making its input and semantics blend smoother with previous behavior and expectations could make a different with regard to its suitability for inclusion into version 2.20. Partly because it would disrupt people's expectations and

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

No, there's no problem to delay the patch for some time if you want to improve it. --- ** [issues:#4509] Enhancement: automatically engrave lyric extenders** **Status:** Started **Created:** Sat Jul 18, 2015 03:23 AM UTC by Anonymous **Last Updated:** Sun Jan 29, 2017 11:39 AM UTC **Owner:**

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

> I'm sure that you properly studied the patch you are commenting. > For all those who did not: The following lilypond source demonstrates how to > generate only explicitly requested extenders: Well, I think we can agree that we are not going to require everybody who wants to use LilyPond to

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

I'm sure that you properly studied the patch you are commenting. For all those who did not: The following lilypond source demonstrates how to generate only explicitly requested extenders: ~~~ \version "2.19.55" \paper { ragged-right = ##f } noex = { \override LyricExtender.no-extender =

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

Heh, questions that I can actually answer with confidence... ;-) Yes, it's the current state. For the "la" on 4, there actually is no melisma - the corresponding note is only the e''4. (Note that both lyric lines are assigned to the *middle* voice; the first and third staff just contain noise

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

The snippet compiles both with and without the patch correctly, without a warning. If we would remove the ExtenderEvent, it certainly would not work any longer. If you \displayLilyMusic the lyrics in the snippets file, change the first words to "\new Lyrics" and insert the result instead of

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

"Alexander Kobel" writes: > Disclaimer: not at a Lily-equipped PC at the moment. > > Isn't that talking about apples and oranges? IIUC, the tweak as > written in the snippet does not work with the patch because `__` is > not translated to an ExtenderEvent anymore, but to >

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

Disclaimer: not at a Lily-equipped PC at the moment. Isn't that talking about apples and oranges? IIUC, the tweak as written in the snippet does not work with the patch because `__` is not translated to an ExtenderEvent anymore, but to `SCM_UNSPECIFIED`. That's expected, since we purged `__`

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

This is getting silly. I can't be more precise than "returning `SCM_UNSPECIFIED` for `__` causes unrelated followup errors: the parser is not prepared for dealing with SCM_UNSPECIFIED here." and the error output I posted follows up the warning messages with errors like ~~~ lsr643.ly:52:3:

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

Please be more precise. As the output of \displayLilyMusic is broken before and after the patch I don't see the error *introduced *by the patch. I see one error message replaced with a different error message. As long as the input (= the output of \displayLilyMusic) is broken some kind of error

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

The patch introduces a third problem of its own, and the example shows that returning `SCM_UNSPECIFIED` for `__` causes unrelated followup errors: the parser is not prepared for dealing with `SCM_UNSPECIFIED` here. --- ** [issues:#4509] Enhancement: automatically engrave lyric extenders**

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

Well, the same procedure also fails without the patch. Even after fixing \lyrics I get: ~~~ knut@golem:~/lyrichyphen> lilypond 643 GNU LilyPond 2.19.55 Processing `643.ly' Parsing... 643.ly:55:7: error: unexpected post-event Aah- \tweak stencil #(lambda (grob) 643.ly:67:29: error:

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

If I use \displayLilyMusic on the lyrics expression in that LSR, I get ~~~ \lyrics \lyricsto "melody" { Aah-\tweak stencil #(lambda (grob) (let* ((orig (ly:grob-original grob)) (siblings (ly:spanner-broken-into orig))) (if (or (null? siblings) (and (>= (length siblings)

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

s/intercept/uses/ I don't see it as an argument for not depracting the double underscore token, the patch works perfectly with the code in snippet 643: ~~~ (list (make-music 'LyricEvent 'articulations (list (make-music 'ExtenderEvent

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

Uh, that example does not "intercept the ExtenderEvent". It _creates_ an ExtenderEvent, one that would actually _conflict_ with automatically generated events at the same timestep. That's rather an argument for _not_ deprecating `__` but retain it as a manner of _explicitly_ creating a

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

> If a LyricEvent should automatically cause the actions associated with a > LyricExtender, then the solution is to change the respective action of the > engraver for lyric extenders so that it no longer relies on extender events > but works on the LyricEvent s directly. > Yes, we really

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

For the time being, `\displayLilyMusic` is already changed such that the `__` are not printed anymore. So from a user perspective, the issue is remedied. I agree that the existence (and automatic generation) of ExtenderEvents is merely an implementation detail that allows to re-use the existing

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

> For display-lily-tests.ly, the output is expected and could be marked "NOT A > BUG", but it isn't pretty. Since there is no need to enter __ manually > anymore (and it is ignored by the parser), \displayLilyMusic should not emit > it either. I don't think that this is a problem of

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

and, forgot to say, that the reg tests diffs are identical to those attached to this tracker. --- ** [issues:#4509] Enhancement: automatically engrave lyric extenders** **Status:** Started **Created:** Sat Jul 18, 2015 03:23 AM UTC by Anonymous **Last Updated:** Tue Jan 24, 2017 09:28 AM UTC

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

All is expected behaviour. You may note that in lyric-combine.ly not only a missing extender has been added but that a too long extender is shortened to the correct length. --- ** [issues:#4509] Enhancement: automatically engrave lyric extenders** **Status:** Started **Created:** Sat Jul 18,

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

Patch to fix "warning: Not drawing a box with negative dimension, -0.xx by y.yy" problem. --- ** [issues:#4509] Enhancement: automatically engrave lyric extenders** **Status:** Started **Created:** Sat Jul 18, 2015 03:23 AM UTC by Anonymous **Last Updated:** Sat Jan 14, 2017 02:57 PM UTC

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

> Any opinions/suggestions/ideas for > - the collapse-length handling of broken extenders (also w.r.t. the > typography-demo.ly regtests) and > - the efforts required to make extenders behave reasonably before grace notes? A negative width boxes solution is in my private git repository, but I

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

So something like the following output would be ok? GNU LilyPond 2.19.55 Processing `footest.ly' Parsing... footest.ly:34:15: warning: The '__' token is ignored and depracted. Please read "Extenders and hyphens" in section 2.1 of the the notation manual! The end __

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

Warning SGTM. --- ** [issues:#4509] Enhancement: automatically engrave lyric extenders** **Status:** Started **Created:** Sat Jul 18, 2015 03:23 AM UTC by Anonymous **Last Updated:** Fri Jan 13, 2017 11:14 AM UTC **Owner:** Alexander Kobel *Originally created by:* *anonymous *Originally

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

Alexander Kobel wrote Friday, January 13, 2017 11:14 AM > @Knut: `__` should (and will) be removed by convert-ly, so this situation > should not occur unless the user did not follow the convert-ly > recommendation. I agree with Dan that this should not be a concern for us. > > @Dan: As said

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: Ticket 4509 discussion

> Since there is no need to enter __ manually anymore (and it is ignored by the > parser), \displayLilyMusic should not emit it either. This reminds me of a question I raised in the codereview which went unacknowledged as far as I can tell. Why should the parser ignore the double underscore