Feature request: Fix cascading error messages
I have a request concerning Lilypond that has bothered me for a while, but which I haven't seen any one else complain about. It is the cascade of error messages you get when you leave out a right-brace or some other symbol. Maybe this could be added as an option to lilypond? lilypond --cascade-level=N file.ly which, for any given line, prints the first N error messages, and after that a message saying that further error messages have been suppressed. A default value for N might be 3 or 4. What does everyone think? --- Christopher Heckman
Re: Feature request: Fix cascading error messages
On Mon, Mar 28, 2022 at 4:58 PM David Kastrup wrote: > > Christopher Heckman writes: > > > I have a request concerning Lilypond that has bothered me for a while, > > but which I haven't seen any one else complain about. It is the > > cascade of error messages you get when you leave out a right-brace or > > some other symbol. > > > > Maybe this could be added as an option to lilypond? > > > > lilypond --cascade-level=N file.ly > > > > which, for any given line, prints the first N error messages, and > > after that a message saying that further error messages have been > > suppressed. A default value for N might be 3 or 4. > > > > What does everyone think? > > The problems from followup errors do not magically disappear because > they are not reported. The only thing that would make sense is better > error recovery (which is pretty hard but can partly be achieved by > inserting "error" productions matching typical error scenarios into the > grammar: that causes a more targeted recovery and is arguably > underutilised in LilyPond's grammar) but not pretending to be fine. > I'm not saying that LilyPond should say that everything is fine, just that it not report every single error for a line. If you have 8 or 9 errors on one line, there's something wrong a basic level. For instance, suppose I misspell markuplist on line 94. The next few errors look like SyntacticStructuresInMusic.ly:94:1: error: unknown escaped string: `\markuplst' \markuplst { SyntacticStructuresInMusic.ly:94:12: error: syntax error, unexpected '{', expecting '.' or '=' \markuplst { SyntacticStructuresInMusic.ly:100:1: error: unknown escaped string: `\new-chapter' \new-chapter { Chapter 1. The Basic Syntactic Structure } SyntacticStructuresInMusic.ly:100:1: error: string outside of text script or \lyricmode \new-chapter { Chapter 1. The Basic Syntactic Structure } SyntacticStructuresInMusic.ly:100:16: error: not a note name: Chapter \new-chapter { Chapter 1. The Basic Syntactic Structure } SyntacticStructuresInMusic.ly:100:27: error: not a note name: The \new-chapter { Chapter 1. The Basic Syntactic Structure } SyntacticStructuresInMusic.ly:100:31: error: not a note name: Basic \new-chapter { Chapter 1. The Basic Syntactic Structure } SyntacticStructuresInMusic.ly:100:37: error: not a note name: Syntactic \new-chapter { Chapter 1. The Basic Syntactic Structure } SyntacticStructuresInMusic.ly:100:47: error: not a note name: Structure \new-chapter { Chapter 1. The Basic Syntactic Structure } SyntacticStructuresInMusic.ly:102:1: error: unknown escaped string: `\flushpar' \flushpar { SyntacticStructuresInMusic.ly:102:1: error: string outside of text script or \lyricmode --- (If you're upset that this is looks illegible in an email, then you understand my point; it doesn't look much nicer in a Terminal set to 108 characters wide.) What I'm saying is that the errors for line 100 should look like the following instead (when N = 4) --- SyntacticStructuresInMusic.ly:100:1: error: unknown escaped string: `\new-chapter' \new-chapter { Chapter 1. The Basic Syntactic Structure } SyntacticStructuresInMusic.ly:100:1: error: string outside of text script or \lyricmode \new-chapter { Chapter 1. The Basic Syntactic Structure } SyntacticStructuresInMusic.ly:100:16: error: not a note name: Chapter \new-chapter { Chapter 1. The Basic Syntactic Structure } SyntacticStructuresInMusic.ly:100:27: error: not a note name: The \new-chapter { Chapter 1. The Basic Syntactic Structure } Warning: Lilypond has possibly suppressed further error messages for line 100. SyntacticStructuresInMusic.ly:102:1: error: unknown escaped string: `\flushpar' \flushpar { --- and so on. > The problem with the followup errors is that there is no way that > LilyPond can actually be sure that they are followup errors. > True, but if you have a cascade of errors on a particular line, you definitely need to fix what's causing the cascade. Once you've done this, and you re-run Lilypond, it will now report only the errors that aren't followups. --- Christopher Heckman > Good heuristics for error recovery productions in the grammar are tricky > to do, and since they are only relevant for erroneous input, they tend > not to be assigned a high priority. > > On the other hand, I found excellent error recovery to be of high > importance when the normal workflow was sucking a stack of punch cards > through the reader and then checking your output shelf hours later for a > stack of line printer paper with the resul
Re: percent repeats (bug?)
In a post/email sent out several months ago, Randy brought up some issues about percent repeats over more than two measures. He cited two issues, related to where the percent sign is placed and what it looks like. I would like to add a third: line breaks aren't allowed in the middle of a \repeat percent. I discovered this when trying to set up a 4-bar repetition of a bass riff. A smaller example is: \score {<< \new TabStaff { \repeat percent 5 { \repeat unfold 16 { c4 } } } \lyrics { \repeat unfold 20 "a very long bit of lyrics indeed!"1 } >> } (Incidentally, I have tried to put a line break in the appropriate place, using the LSR and the manuals but gotten nowhere. A fix would be nice to have.) --- Christopher Carl Heckman ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Making a Hairpin end close to the end of a Score
I stumbled on this hack, and it doesn't appear to be anywhere online. As is, you can't have a hairpin run until the very end of a score; it will stop before the last note. You also can't add \! to a \bar; Lilypond complains that it is not a musical event. The idea is to use \afterGrace, with an invisible grace note. \absolute { c'2\> \afterGrace d' { s16\! } | } MIDI translates this as you would expect, without an extra note at the end. However, this will not work if the hairpin starts on the last printed note. --- Christopher Heckman ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Making a Hairpin end close to the end of a Score
On Fri, Nov 4, 2016 at 9:36 AM, Simon Albrecht wrote: > On 04.11.2016 09:11, Christopher Heckman wrote: >> >> On Tue, Nov 1, 2016 at 3:08 PM, Simon Albrecht >> wrote: >>> >>> Hi Chris, >>> [...] >>> In that case, another opportunity to step forward with the now much-used >>> \after function, here to be applied as >>> \after 3/4 \! c1\> >> >> This last one _doesn't_ work for me. I get two hairpins (< >) to the >> right and below the whole note. > > > Please give a complete, compilable example. Well, this seems silly. I also had the following in my .ly file: { \after 4 \< \after 2 \> \after 2. \! c'1 } so it was working correctly. (And that is the reason why I don't want to make everything public.) ((A few minutes later:)) However, I'm not going to annoy future readers by saying "I figured it out", and will actually send this out to the group for closure. --- CCH ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Suggestions for the lilypond-user archive search
This is a useful website to bookmark and use, but I've found over the years that it can be improved. My suggestions are: (1) Allow an option to search by thread. If X is a thread that matches the search, then most of the emails there (and in Re: X) will also match, filling up the screen. (2) The upper limit for a search term should probably be increased. We have faster computers now, and there are more emails in the archive, the second of which results in more hits. (3) If you are performing an AND search, and one of the terms has too many hits, it is dropped, and you get the search for just the other one. If there are not too many hits for the second term, the search engine should look through those documents for the first term. Example: When I search for "markup table", "table" has 1609 hits at the moment, and "markup" has too many. The engine should go back through "table" 's 1609 hits and check each one for "markup", instead of just providing the 1609 hits for "table". --- Christopher Carl Heckman
FYI: Nested Markuplist-Score-Midi Block Behavior
I don't know whether this is a bug or not, but if you put a score block inside of a markuplist, you cannot export MIDI from it. If it's not fixed, it should be documented at the website. Minimal(?) example: \markuplist { \score { { c1 } \layout { } \midi { } } } result: no .midi file. --- Christopher Carl Heckman
Re: FYI: Nested Markuplist-Score-Midi Block Behavior
On Fri, Nov 15, 2024 at 10:58 PM Werner LEMBERG wrote: > > [Sending this e-mail again to the 'lilypond-user' list, which we > forgot to include in our conversation.] > > >> Maybe you are mixing up the the `\score` *markup* command (to be > >> used within `\markup` or `\markuplist`) with the 'normal', > >> top-level `\score` command? > > > > My initial reaction to that question was: There's a difference? (I've > > been using Lilypond for eight years now, and I've never encountered > > this information.) > > Yes, there is one. Consider the following example. > [...] > If you compile that you can see that the `\score` markup command > suppresses page turns because they don't make sense in markup. > And I suspect that that's why \score-lines isn't called \score as well. > > My next reaction was: Why is the command the same, when the behavior > > is different? > > For convenience. Why should it be called differently? In \markuplist, there's a command that does something similar but has a different name (\score-lines). If I'm understanding correctly (a dangerous assumption 8-) ), \score-lines works like TeX's horizontal mode, and \score works like its vertical mode. (A \markup must appear all on one page.) > I dare to say > that in the great majority of all use cases it doesn't make a > difference. Your report is the first one ever related to MIDI and > markup, as far as I remember. > > > Why doesn't the \markup version of \score call the "normal" version > > of \score, with all its features? > > Because some features don't make sense in markup, as mentioned above. > Note also that the creation of MIDI files is done by `lilypond` in a > separate pass that completely ignores markup. > That second reason makes a lot more sense. > > If you don't want to change \markup's version of \score to do > > exactly what the top level \score does, then section 3.2.1 > > (Structure of a score) and 3.6.3 (The MIDI block) are logical places > > to put a warning. Right after the "Note: There must be only one > > outer music expression ..." the following should be added: "Note > > also that if a \score is inside of a \markup or \markuplist block, > > no MIDI will be created, even with a \midi block." > > Thanks. I've solved it a bit differently, please check > > https://gitlab.com/lilypond/lilypond/-/merge_requests/2495 > > again. > I've suggested changing line 3896 to "called @code{\score} that doesn't produce MIDI output, even if a @code{\midi} block is present," At least I think I did. (I'm not familiar with the system.) --- Christopher Carl Heckman
Re: Some things need need to be fixed on the interfaces pages
On Tue, Dec 10, 2024 at 12:58 AM Werner LEMBERG wrote: > > > I went through the interfaces pages recently, and I found a couple of > > things that need to be fixed (these is from the 2.25 version). > > > > (1) The centered-spanner-interface page talks about using it with > > MultiMeasureRest, but MultiMeasureRest isn't among the list of > > grobs at the bottom that use it. (The MultiMeasureRest page > > doesn't mention that it uses the centered-spanner-interface, > > either.) > > Well, what you are actually talking about is the description of the > property `spacing-pair`, which mentions `MultiMeasureRest`. However, > there are *two* properties with this name: one is part of > `centered-spanner-interface`, and the other one is part of > `multi-measure-interface`. > > The policy of LilyPond is to avoid different property names for > similar functionality, which often leads to cryptic property > descriptions to be as generic as possible. In this particular case an > example is given, which is actually a good thing, but it doesn't cover > the `centered-spanner-interface` incarnation of this property. > > Maybe you can suggest a better wording for the description of > `spacing-pair`? > [...] On the centered-spanner-interface page, the comment about the MultiMeasureRest can just be deleted (as it's already on the multi-measure-interface page, as long as the description of spacing-pair is correct. > > (2) The stroke-finger-interface page says that it is for "right hand > > finger instructions." Well, this isn't true if the instrument is > > being played left-handed. In that case the "right hand" really > > is the "picking hand" or "strumming hand." > > What instrument(s) do you have in mind? It is possible to improve the > description while talking about 'left hand' and 'right hand' in the > context of fretted instruments, but I don't think it makes sense to > change these long-established terms. > The main instrument I'm thinking of is the guitar. And there's actually precedent, in that left-handed chord diagrams (FretBoards) are supported by Lilypond. --- Christopher Carl Heckman
Some things need need to be fixed on the interfaces pages
I went through the interfaces pages recently, and I found a couple of things that need to be fixed (these is from the 2.25 version). (1) The centered-spanner-interface page talks about using it with MultiMeasureRest, but MultiMeasureRest isn't among the list of grobs at the bottom that use it. (The MultiMeasureRest page doesn't mention that it uses the centered-spanner-interface, either.) (2) The stroke-finger-interface page says that it is for "right hand finger instructions." Well, this isn't true if the instrument is being played left-handed. In that case the "right hand" really is the "picking hand" or "strumming hand." Similarly, "left hand" should be replaced with something like "fretting hand." (This term looks strange if you're playing a fretless instrument. If there are any violinists out there: If you play the violin right-handed, what is your left hand called?) --- Christopher Carl Heckman
Re: Some things need need to be fixed on the interfaces pages
On Tue, Dec 10, 2024 at 9:38 PM Werner LEMBERG wrote: > > >> The policy of LilyPond is to avoid different property names for > >> similar functionality, which often leads to cryptic property > >> descriptions to be as generic as possible. In this particular case > >> an example is given, which is actually a good thing, but it doesn't > >> cover the `centered-spanner-interface` incarnation of this > >> property. > >> > >> Maybe you can suggest a better wording for the description of > >> `spacing-pair`? > >> [...] > > > > On the centered-spanner-interface page, the comment about the > > MultiMeasureRest can just be deleted (as it's already on the > > multi-measure-interface page, as long as the description of > > spacing-pair is correct. > > Exactly this is not possible, because there exists only a single, > global property called `spacing-pair`, which consequently has a > single, global description. > > In other words, the auto-generated documentation sees that an > interface uses `spacing-pair`, and it shows its description. > Okay, I see now. I guess this makes building the website a lot easier. 8-) Maybe the comment about the MultiMeasureRest should become a Snippet instead. > IIRC, a suggestion in the mentioned thread is to make the property > description displayed for a given grob show which interfaces it is > part of, for example > > ``` > ‘spacing-pair’ (pair) > interface(s): > centered-spanner-interface, multi-measure-interface Yes, but spacing-pair isn't part of the multi-measure-interface. Unless that's something that's being developed. >>> https://lilypond.org/doc/v2.24/Documentation/internals/multi_002dmeasure_002dinterface > default value: > '(break-alignment . break-alignment) > There's a problem there, too, in that the default value depends on the grob. In MeasureSpanner, the default value is (staff-bar . staff-bar) In PercentRepeat, it's (break-alignment . staff-bar) But I guess this is an issue to be mentioned in the other thread. > >> What instrument(s) do you have in mind? It is possible to improve > >> the description while talking about 'left hand' and 'right hand' in > >> the context of fretted instruments, but I don't think it makes > >> sense to change these long-established terms. > > > > The main instrument I'm thinking of is the guitar. > > OK, I see. The probably simplest solution is to explicitly mention > that LilyPond uses the term 'right hand' to actually indicate the > strumming hand. > > > And there's actually precedent, in that left-handed chord diagrams > > (FretBoards) are supported by Lilypond. > > Well, this makes sense, because they are displayed differently. > Also, there's a grob named StrokeFinger. It's not named RightHandFinger. == Christopher Carl Heckman Honors Faculty Teaching Associate Professor 33° 25' 7'' N, 111° 55' 55'' W ECA 212 School of Mathematical & Statistical Sciences Arizona State University (T1N R4E Sect22 NW1/4) Tempe, AZ 85287 - 1804 United States of America North America Planet Earth Solar System Gould Belt Local Bubble Local Fluff Milky Way Galaxy, Orion Arm Local Group Virgo Supercluster Pisces-Cetus Supercluster Complex Universe Multiverse ==
Re: Some things need need to be fixed on the interfaces pages
On Tue, Dec 10, 2024 at 9:38 PM Werner LEMBERG wrote: > > >> The policy of LilyPond is to avoid different property names for > >> similar functionality, which often leads to cryptic property > >> descriptions to be as generic as possible. In this particular case > >> an example is given, which is actually a good thing, but it doesn't > >> cover the `centered-spanner-interface` incarnation of this > >> property. > >> > >> Maybe you can suggest a better wording for the description of > >> `spacing-pair`? > >> [...] > > > > On the centered-spanner-interface page, the comment about the > > MultiMeasureRest can just be deleted (as it's already on the > > multi-measure-interface page, as long as the description of > > spacing-pair is correct. > > Exactly this is not possible, because there exists only a single, > global property called `spacing-pair`, which consequently has a > single, global description. > > In other words, the auto-generated documentation sees that an > interface uses `spacing-pair`, and it shows its description. > > IIRC, a suggestion in the mentioned thread Do you know the name of that thread? I tried searching for it, but couldn't come up with anything. --- Chris > is to make the property > description displayed for a given grob show which interfaces it is > part of, for example > > ``` > ‘spacing-pair’ (pair) > interface(s): > centered-spanner-interface, multi-measure-interface > default value: > '(break-alignment . break-alignment) > > A pair of alignment symbols which set an object's spacing > relative to its left and right ‘BreakAlignment’s. > > For example, a ‘MultiMeasureRest’ will ignore prefatory items > at its bounds (i.e., clefs, key signatures and time > signatures) using the following override: > > \override MultiMeasureRest.spacing-pair = >#'(staff-bar . staff-bar) > ``` > > On the description page for `centered-spanner-interface` it could > display the following: > > ``` > ‘spacing-pair’ (pair) > also used in: > multi-measure-interface > > A pair of alignment symbols which set an object's spacing > relative to its left and right ‘BreakAlignment’s. > > For example, a ‘MultiMeasureRest’ will ignore prefatory items > at its bounds (i.e., clefs, key signatures and time > signatures) using the following override: > > \override MultiMeasureRest.spacing-pair = >#'(staff-bar . staff-bar) > ``` > > >> What instrument(s) do you have in mind? It is possible to improve > >> the description while talking about 'left hand' and 'right hand' in > >> the context of fretted instruments, but I don't think it makes > >> sense to change these long-established terms. > > > > The main instrument I'm thinking of is the guitar. > > OK, I see. The probably simplest solution is to explicitly mention > that LilyPond uses the term 'right hand' to actually indicate the > strumming hand. > > > And there's actually precedent, in that left-handed chord diagrams > > (FretBoards) are supported by Lilypond. > > Well, this makes sense, because they are displayed differently. > > > Werner --- Christopher Carl Heckman
Re: Some things need need to be fixed on the interfaces pages
On Thu, Dec 12, 2024 at 4:05 PM David Kastrup wrote: > > Christopher Heckman writes: > > > On Wed, Dec 11, 2024 at 10:58 PM Werner LEMBERG wrote: > >> > >> >> IIRC, a suggestion in the mentioned thread is to make the property > >> >> description displayed for a given grob show which interfaces it is > >> >> part of, for example > >> >> > >> >> ``` > >> >> ‘spacing-pair’ (pair) > >> >> interface(s): > >> >> centered-spanner-interface, multi-measure-interface > >> [...] > >> >> default value: > >> >> '(break-alignment . break-alignment) > >> >> > >> > > >> > There's a problem there, too, in that the default value depends on the > >> > grob. > >> > > >> > In MeasureSpanner, the default value is (staff-bar . staff-bar) > >> > > >> > In PercentRepeat, it's (break-alignment . staff-bar) > >> > >> I don't see a problem here. > > > > You can't talk about *the* default value, because it's not unique; you > > can only talk about *a* default value. > > I think you are confusing value and default value. The default value is > what is being used unless overriden by grob definition or context > definition or user. Many grob definitions override the default, and > several context definitions also apply overrides. Only then does the > user come into play. > > > The default values seem to be set in grobs, not interfaces, so as an > > alternative, how about something like ... > > Again: you are confusing what "default" means in this context. The > grobs can override the defaults. > > -- > David Kastrup Okay, I think I see what's going on; the interfaces set values, then the Grobs set values, then specifics are set, in that order. When the Grob sets the value, you're calling that an "override"; I consider it to still be part of the "default" values. In the Internals section of lilypond.org, the default values of properties are largely listed on the grob pages, not on the interface pages, which is what I was going by. As it turns out -- correct me if I'm wrong -- the interfaces don't set too many default values, mostly "pointer intialization" or "behind the scene" work, but they always get to be first. And getting back to the topic at hand, I still think that the *overriden* values should be listed for each Grob should be listed for each property, because that would be one less mouse click. == Christopher Carl Heckman Honors Faculty Teaching Associate Professor 33° 25' 7'' N, 111° 55' 55'' W ECA 212 School of Mathematical & Statistical Sciences Arizona State University (T1N R4E Sect22 NW1/4) Tempe, AZ 85287 - 1804 United States of America North America Planet Earth Solar System Gould Belt Local Bubble Local Fluff Milky Way Galaxy, Orion Arm Local Group Virgo Supercluster Pisces-Cetus Supercluster Complex Universe Multiverse ==
Re: Some things need need to be fixed on the interfaces pages
On Wed, Dec 11, 2024 at 10:58 PM Werner LEMBERG wrote: > > >> IIRC, a suggestion in the mentioned thread is to make the property > >> description displayed for a given grob show which interfaces it is > >> part of, for example > >> > >> ``` > >> ‘spacing-pair’ (pair) > >> interface(s): > >> centered-spanner-interface, multi-measure-interface > [...] > >> default value: > >> '(break-alignment . break-alignment) > >> > > > > There's a problem there, too, in that the default value depends on the grob. > > > > In MeasureSpanner, the default value is (staff-bar . staff-bar) > > > > In PercentRepeat, it's (break-alignment . staff-bar) > > I don't see a problem here. You can't talk about *the* default value, because it's not unique; you can only talk about *a* default value. > For grob `foo`, it is completely > irrelevant whether property `bar` is part of interface `xxx` or `yyy`. > You access it as `foo.bar`. Consequently, it is just a courtesy to > the reader to mention which interface a property is part of. > > Maybe a grob description on the page showing the available default > properties for `MeasureSpanner` could be displayed [...] > The default values seem to be set in grobs, not interfaces, so as an alternative, how about something like ... ‘spacing-pair’ (pair) A pair of alignment symbols which set an object's spacing relative to its left and right ‘BreakAlignment’s. interface(s): centered-spanner-interface, multi-measure-interface default value in grob(s): CenteredBarNumber: [none] MeasureCounter: '(break-alignment . break-alignment) MultiMeasureRest: '(break-alignment . break-alignment) PercentRepeat: '(break-alignment . staff-bar) (with the appropriate links added) > >>> And there's actually precedent, in that left-handed chord diagrams > >>> (FretBoards) are supported by Lilypond. > >> > >> Well, this makes sense, because they are displayed differently. > > > > Also, there's a grob named StrokeFinger. It's not named > > RightHandFinger. > > This is admittedly an inconsistency and could be fixed. However, I'm > not sure whether it is worth the cost: Renaming stuff forces all > LilyPond users to re-learn commands that exist since a long time. > Normally, we only do this only if there is confusing terminology (see > the parallel thread about musical duration, moments, etc.) In this > case, however, it will IMHO suffice to mention that LilyPond uses the > term 'right hand' for the strumming hand. > > A user can also very easily define new commands that better fits the > intended purpose, for example, > > ``` > strummingHandFinger = \rightHandFinger > ``` Yes. Also, I guess not as many left-handed players are upset about this as I thought. --- Christopher Carl Heckman