hus is unlikely to see any event-chord. The instance in
modal-transforms.scm explicitly catches event-chord before
simultaneous-music . I doubt either of those instances navigated that
problem consciously.
My vote would be to stop an event-chord from being marked as
simultaneous-music. Neither are treated as events but are processed by
individual iterators. And it does not look like this "feature" has been
employed anywhere consciously.
--
David Kastrup
default values", but not even context
definitions set anything that cannot be undone. That's the reason
defaults are established in the Global context rather than the Score
context where they could be overriden/unset without fallback.
--
David Kastrup
\volta 2 { d' | }
> }
> c' |
> \bar "|."
> }
> }
I don't understand what you expect here. Alternatives in a repeat
construct have to be the last thing, yet you add c' | \bar "|." into the
repeat volta. How is that supposed to be formatted?
--
David Kastrup
\midi { }
> }
Not a bug. Documented behavior.
<https://lilypond.org/doc/v2.24/Documentation/notation/using-repeats-with-midi>
--
David Kastrup
is is sent to very many people who may or may not be interested in
> all topics on the list.
Did you really have to _quote_ all of the quoted messages of last week
_again_ to make that point?
That will make all of those nonsensically quoted messages from last week
appear _twice_ in next week
hing.aux to
be created/written.
This made the punishment for writing \include{something.tex} instead of
the correct \include{something} pretty severe (until MikTeX was made to
detect this special case and refuse the operation).
--
David Kastrup
Snippets manual, MIDI chapter, Staff.midiInstrument list omits "guitar
harmonics" between "distorted guitar" and "acoustic bass" (position 32).
\language "deutsch"
\new NoteNames { b1 }
This outputs `h♭` instead of `b`.
--
David Kastrup
onvert_002dly
fatal error: failed files: "scheme-sandbox"
--
David Kastrup
reak r1 1 }
>
>
> Not sure it’s ever going to trigger in real-life situations, but it’s
> a crash without error handling. “Output code 11.”
That is not a minimal example. Try
\new Staff \with { \consists "Custos_engraver" } { 1 }
--
David Kastrup
most 20 years old, from a time where HP had a bit of a
different reputation regarding printers... It also helps that complete
service manuals with detailed disassembly instructions are available.
Of course, this cannot make up for letter/A4 discrepancy either, but it
should be possible to tell the printer driver to make up for that with
scaling.
--
David Kastrup
ap `bar-glyph` in `strip-string-annotation`.
I can upload a patch.
Is there any benefit in adding a regression test? It compiles
correctly, it's just the warning that is bogus. Is this detected in
regressing testing?
-David
"2.24.0"
#(define mydrums '( (hightom default #f 3)))
\score {
\new DrumStaff \with { drumStyleTable = #(alist->hash-table mydrums) }
{
\new DrumVoice { \voiceTwo \drummode { \partial 2 \acciaccatura tomh8 tomh4
\acciaccatura tomh8 tomh4 } }
}
}
--
David Kastrup
ve any effect on span-bar::compound-bar-line, which does
not use get-span-glyph, but calls
(assoc-get bar-glyph span-bar-glyph-alist)
directly.
-David
> not by default), but I can't see why we wouldn't want 'barcheck
> failed' warnings whenever ANY note goes across a barline (other than
> via a tie), for whatever reason. It's a really useful warning for
> double-c
nce for "simile" triplets entered as
>> durations with *2/3 multiplier.
>
> OK, then we'd have to say "it's a warning only if the resulting
> note is longer than the bar". Can the existing bar-check code
> be modified to take these multipliers into acco
e for "simile" triplets entered as
durations with *2/3 multiplier.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
mpressed rests bars but the eight bars are unfolded.
>
> If I remove the two partial before, it works.
Why don't you do that, then? The first one is utterly wrong anyway
since it does not match the beat structure of the following partial bar.
\partial carves out material _before_ a ba
gt; NameError: name 'path_replace' is not defined
>
> Is this a known issue?
commit 3d3f8531da00247ad55b6a613bf0adc5e9b71954
Author: Jean Abou Samra
Date: Tue Oct 25 01:28:28 2022 +0200
convertrules.py: define path_replace on toplevel
Fixes #6446 (
David Poon writes:
> Thank you so much for the speedy and clear response. I didn't consider that
> it was because the notehead styles were different! Glad for the
> understanding.
Maybe there'd be a way for the implementation to check for the same
glyph instead? For style
Thank you so much for the speedy and clear response. I didn't consider that
it was because the notehead styles were different! Glad for the
understanding.
-David
On Fri, 4 Nov 2022 at 10:27, Jean Abou Samra wrote:
> Le 04/11/2022 à 18:14, David Poon a écrit :
> > When I use Bar
ice will both
give the desired output, but the code as-is duplicates noteheads.
-David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
David Kastrup writes:
> Jean Abou Samra writes:
>
>> Thus I wrote to the general GNU list server admins and proposed
>> to step up for being an admin on these lists, just like I am
>> already an admin on lilypond-user-fr (the French-speaking equivalent
>> of lil
t let things
through.
That's the impression I also get from current LilyPond list moderators
(thanks David!): you don't really get the impression that there is
anybody doing anything except that the amount of visible spam is
essentially zero and that doesn't happen by itself.
--
David
David Kastrup writes:
> Kenneth Wolcott writes:
>
>> Hi;
>>
>> This is an extremely minor bug.
>>
>> Which version of "English" is the Lilypond documentation written in?
>>
>> If it is American English, then:
>>
>> N
n.itexi:@subsubheading Paul Davis, developer of
@uref{https://jackaudio.org/, JACK} and @uref{https://www.ardour.org/, Ardour}
Documentation/en/web/introduction.itexi:of LilyPond's behaviour. Please read
this manual before doubting
Ok, essentially just "behaviour".
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ht get carried away sometimes),
but the general level of discourse should be at a user-accessible level.
And if it isn't, asking questions is not supposed to be frowned upon.
You can check out the archives to see whether you think frequenting it
might be something that might benefit you and/or o
so I don't know if there's any
> action to take, but I thought I'd document it here.
Historically, multiple grace parts in sequence were just not supported.
I have no idea whether some refactoring by Dan has changed the substance
of the matter bu
tention to
> redefine something that already exists?
Why?
>
>
> \version "future"
>
> foo = { c2 } % Works, providing \foo does not exist.
> bar = { c4 4 } % Warns, since \bar does exist.
Why would that warran
command line
help and as #t in the lilypond-usage manual.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
2/3
} {
\ossia
}
\new Staff \rightHand
>>
%%%
Now that \stopStaff is placed at the time where you actually want to
have the staff end, that's exactly where the staff _does_ end.
And what you see now in terms of stems deserves the title "bug, or at
least ugly".
But
o distinct tokens; it would be prohibitive to have to
define all of c c1 c2 c4 c8 c16 c32 c64 c128 c' c'1 c'2 c'4 cis? cis?1 ...
separately.
Having spaces count as an additional token would make it troublesome to
deal with durations like \breve .
Yes, it can be a source of entr
for this. It doesn't work polyphonically as in per-note but
rather per-channel, but with the usual per-Staff channel mapping used in
LilyPond, that should be good for covering some distance. But LilyPond
would need to support it.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
then don't need another
repetition).
> They are used in VerticalAxisGroup pure calculations, to estimate how
> tall a staff will be between two certain points in order to score page
> breaking configurations.
Yes, that's more like it.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Parentheses may be scaled incorrectly. They become too big when the staff is
magnified, and too small for smaller staff sizes. TrillPitchParentheses do not
appear to be affected.% Parentheses may be scaled incorrectly. They become too big
% when the staff is magnified, and too small for smaller
David Kastrup writes:
[Percussion notes]
> To get a better headstart for knowing what one needs to tamper with, it
> would be nice to give the MIDI instrument number as well where one is
> assigned.
Ouch. The MIDI _instrument_ number for channel 10 sets the drum _kit_
(and since Lily
ent number as well where one is
assigned.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
op trivial scores from crashing MIDI generation but I guess both our
work was not really plugging the problem at its root and so one can
apparently still generate circumstances where it pops up.
So while it certainly is helpful to see where stuff crashes here (and
possibly fix this particular cra
ntinuing, cross fingers
programming error: no dynamic span to finish
continuing, cross fingers
MIDI output to `bah.midi'...
Compilation segmentation fault (core dumped) at Sun Oct 24 00:14:21
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypo
David Kastrup writes:
> I just had the pipeline run
>
> https://gitlab.com/lilypond/lilypond/-/pipelines/393509219
>
> finish. This change adds engravers/performers including engraver
> information, stuff that is extracted into the IR. It also adds a
> regtest.
>
>
which
presumably means that the documentation will not be updated until after
some other change adds documentation.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
James writes:
> On 17/10/2021 21:45, David Kastrup wrote:
>>
>> Since it is sort of a nuisance to get rid of files you don't own, it
>> would be good if make install-* did not create any files in-tree when
>> the respective make * commands have already been run.
&
David Kastrup writes:
> Example file:
>
> timetrack =
> {
> \set Score.skipTypesetting = ##t
> \skip 1
> \set Score.skipTypesetting = ##f
> \skip 1*2
> }
>
> music =
> {
> c1\mf
> c1\f
> c1\ff
> }
>
>
> \score {
>
n 1.00 starting at 2
continuing, cross fingers
Success: compilation successfully completed
Compilation finished at Mon Oct 18 20:12:07
~~~
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
discussion where his role and
involvement are sort of given the kind of consideration that a CI script
gets.
Not that I am guilty of that here myself: the average LilyPond
developer's experience and opinion about the topic may differ from
Jean's exactly because we've see
Jean Abou Samra writes:
> Le 16/10/2021 à 13:09, David Kastrup a écrit :
>> Jean Abou Samra writes:
>>> Hi James, Werner, all,
>>>> I would say that 'most' emails to the bug list do NOT need an
>>>> issue, they are either replies to emails or
eporting list (and the
documentation does not really mention the list I think) but at least
gets stuff into the system (where it sometimes is left to rot without
further feedback).
That's still preferable to what you propose, but quite worse than having
an actual bug reporting list like we h
Federico Bruni writes:
> Il giorno mar 21 set 2021 alle 22:48:04 +0200, David Kastrup
> ha scritto:
>> "make doc-clean" appears to work better. I find it somewhat
>> surprising
>> that it should not have been implied by "make clean".
>
> IIR
Federico Bruni writes:
> Il giorno mar 21 set 2021 alle 22:48:04 +0200, David Kastrup
> ha scritto:
>> "make doc-clean" appears to work better. I find it somewhat
>> surprising
>> that it should not have been implied by "make clean".
>
> IIRC i
Jean Abou Samra writes:
> Le 21/09/2021 à 22:03, David Kastrup a écrit :
>> Jean Abou Samra writes:
>>
>>> Le 21/09/2021 à 21:24, David Kastrup a écrit :
>>>> I am reverting
>>>>
>>>> commit 79114c78d12a24b6089af0375dcac5b739c29a0c
&g
Jean Abou Samra writes:
> Le 21/09/2021 à 21:24, David Kastrup a écrit :
>> I am reverting
>>
>> commit 79114c78d12a24b6089af0375dcac5b739c29a0c
>> Author: Jean Abou Samra
>> Date: Tue Aug 31 17:49:30 2021 +0200
>>
>> Doc: Better h
Jean Abou Samra writes:
> Le 21/09/2021 à 21:12, David Kastrup a écrit :
>> David Kastrup writes:
>>
>>> dak@lola:/usr/local/tmp/lilypond$ CPU_COUNT=9 make -j9 info
>>> Making Documentation/out-www/lilypond-changes.info < texi
>>> Making Docume
David Kastrup writes:
> David Kastrup writes:
>
>> dak@lola:/usr/local/tmp/lilypond$ CPU_COUNT=9 make -j9 info
>> Making Documentation/out-www/lilypond-changes.info < texi
>> Making Documentation/out-www/lilypond-learning.info < texi
>> Making Documenta
David Kastrup writes:
> dak@lola:/usr/local/tmp/lilypond$ CPU_COUNT=9 make -j9 info
> Making Documentation/out-www/lilypond-changes.info < texi
> Making Documentation/out-www/lilypond-learning.info < texi
> Making Documentation/out-www/en/notation.texi < tely
> Maki
exi
lilypond-book.py: error: file not found: en/hyphenation.itexi
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
.
In particular the linked page--though it calls itself DejaVu-fonts with
a fancy logo--has no information about the fonts, or any links to the
correct site.
According to Wikipedia, the official web site of the actual DejaVu fonts
is .
--
David Zelinsky
Jonas Hahnfeld writes:
> Am Dienstag, dem 17.08.2021 um 21:43 +0200 schrieb David Kastrup:
>> Seems a bit wasteful not to include !882 while fixing point-and-click.
>
> Not really, the official binaries continue to be Guile 1.8 so nothing
> really changes there. I wouldn
to Guile's %load-path.
>
> Yes, the wrapper from GUB uses the wrong directory in GUILE_LOAD_PATH.
> The fix is rather simple (https://github.com/gperciva/gub/pull/87),
> maybe it would be a good idea to release 2.23.4 with this. Phil, what
> do you think?
Seems a bit wasteful n
o start into grace mode anyway. The downside is that
// this will get us confused when given something like
//
// \new Voice { \oneVoice \grace { c''8 8 } g'1 }
//
// where \grace executes its actions already before \oneVoice, causing
// different stem directions.
which is rela
t; TabNoteHead.font-size } d'
> }
> }
Do not pair \override and \revert. Instead pair \temporary \override
with \revert. Otherwise you may get interactions with outer overrides,
and grace notes do come with their own set of overrides.
--
David Kastrup
___
James writes:
> Hello
>
> On 01/07/2021 22:36, David Kastrup wrote:
>> Please look/listen at the following:
>>
>>
>> Separate rolls are not separated, articulations are executed on every
>> single stroke (where they are inaudible for drums) instead of t
wanted to
differentiate between producing performance material or producing Midi
as an intermediate for importing into a different notation program.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Hans Åberg writes:
>> On 1 Jul 2021, at 23:36, David Kastrup wrote:
>>
>> Separate rolls are not separated, articulations are executed on every
>> single stroke (where they are inaudible for drums) instead of the note
>> as such, ties (indicating an actual lack
note
as such, ties (indicating an actual lack of separation) instead tie the
whole roll into a single stroke, dynamics, well...
This is pretty much a disaster.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
So I think one thing we should be doing as part of \partial is to
trigger the issuance of a time signature at the next bar start
regardless of whether the signature stays the same.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
David Kastrup writes:
> \include "articulate.ly"
>
> \score
> {
> \articulate
> {
> \tempo 4 = 60
> c'1:32-"rall."
> c'1-"a tempo"
> }
> \midi { }
> }
Ok, putting \displayLilyMusic before \articulate
\include "articulate.ly"
\score
{
\articulate
{
\tempo 4 = 60
c'1:32-"rall."
c'1-"a tempo"
}
\midi { }
}
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
orking executable not using Xcode.
How feasible or hard that path is (and how much Apple is invested in
making Darwin available in a timely or useful manner) is a different
question.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
t unlikely to get us into hot water.
Opposed to that, we know for sure that the 64bit SDKs are off-limits.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
LilyPad and doing a Darwin-only version of LilyPond, assuming that we can
>> do this with suitably free components.", by David Kastrup. I don't think
>> many people are using the limited editor LilyPad. There are a
>> lot of better
>> tools available
Carl Sorensen writes:
> On 4/22/21, 9:49 AM, "Bart Kummel" wrote:
>
> I think you should re-consider this comment: "The other option is ditching
> LilyPad and doing a Darwin-only version of LilyPond, assuming that we can
> do this with suitably free
Bart Kummel writes:
> I think you should re-consider this comment: "The other option is
> ditching LilyPad and doing a Darwin-only version of LilyPond, assuming
> that we can do this with suitably free components.", by David
> Kastrup. I don't think many people a
o financially sponsor his unofficial porting
work so that he does not end up shortchanged for providing the Apple
installers created on his Apple hardware.
In short: as long as people are not willing to work themselves for the
change they want to see, it will not happe
Kevin Barry writes:
> On Wed, Mar 31, 2021 at 01:42:17AM +0200, David Kastrup wrote:
>> David Kastrup writes:
>>
>> > Apparently, images are no longer copied when doing
>> >
>> > make install-info
> I always work in a terminal so I wouldn'
David Kastrup writes:
> Apparently, images are no longer copied when doing
>
> make install-info
>
> making the documentation near useless. Pages look like
>
> File: lilypond-notation.info, Node: Pitches, Next: Rhythms, Up: Musical
> notation
>
> 1.1 Pitches
-info creates a link
lrwxrwxrwx 1 root root 35 Mär 31 01:28 lilypond ->
../doc/lilypond/html/Documentation/
in /usr/local/share/info
that is entirely useless since I am not interested in installing the
HTML documentation.
--
David Kastrup
___
bu
eed, but LilyPond tries
preserving straightforward relations of the input to the music
expression. Mapping the music expression to some behavior during
iteration is then a different endeavor.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
#x27;direction #DOWN -\markup
It won't make a difference for text scripts that are going to appear
below the system anyway. But for example in \voiceOne settings, they'd
go above the system by default.
--
David Kastrup
___
bug-lilypond mailing l
ocation fluids.
So unless you don't know what version of LilyPond will parse your code,
I'd strongly suggest omitting them. In particular, code preceded by
\version "2.23.1"
is more or less defined to not require their use.
When the function actually needs
ond.app/Contents/Resources/share/lilypond/current/scm/lily.scm:1036:21:
> Wrong type argument in position 1: (1 "4.." . #f)
>
> What am I missing here?
convert-ly ?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
f. The changed function is now more robust against
different input, but I have no idea if the different input constitutes a
bug.
So it would be good if Dan checked whether the current behavior is the
desired one.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Aaron Hill writes:
> On 2020-09-22 5:54 am, David Kastrup wrote:
>> The whole code in the find-non-empty loop, apart from this error, is
>> garbage. Here is a bit more code and analysis:
>> (define-public (add-quotable name mus)
>> (let* ((tab (eval &
David Kastrup writes:
> Pierre-Luc Gauthier writes:
>
>> Hi there,
>>
>> When I compile :
>>
>> test = {}
>> \addQuote "test" \test
>>
>> I get :
>>
>> GNU LilyPond 2.21.7
>> Processing `test.ly'
>&g
long
time, so a more recent change must have affected context-list which
previous to that change apparently always contained raw-voice somewhere,
or at least in the case you now posted.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
this?
>
> ```
> { \grace { c8 d8 } e4 }
> ```
\grace does not just introduce grace timing. It also does things like
\stemUp and size reduction. So what should happen with
{ \grace { \stemDown c8 } { d8 } }
?
--
David Kastrup
___
bug
; Changing the code to use
>>> \context Voice or \new Voice or \new Staff
>>> works.
>>>
>>> Cheers,
>>> Harm
>>
>> It seems it occurred somewhere in those builds that we can no longer
>> compile by default. Also see:
>> https://lis
-message of f372c695a52cf83ea00ff3be40acc542b4d46cbd
> \new Staff \with { instrumentName = "3" }
> \relative {
> \partial 4
> \repeat volta 4 { e'4 | c2 d2 | e2 f2 | }
> \alternative { { g4 g g } { a a a a } }
> a b2.
> }
>
> %% Accidental missing
>
uding the fonts with a GPL program (which would
make it silly to choose Affero GPL in the first place, but I chose to
check anyway).
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Right now I'm too tired ...
You don't need something like git-cl: the basic setup is really quite
simple. The most efficient way to organise continuous ongoing work is
something we are still figuring out, but you are talking about entry
hurdles here. Th
of Lilypond. Can you please have a look at this?
You downloaded the wrong version. On all download pages I can find on
the web page (including for developer versions), there are unofficial
downloads for 64Bit MacOSX that should be working with Catalina.
--
David Kastrup
_
by Jonas
> Hahnfeld). I'm not sure that this is plausible, maybe I was to naive
> in bisecting.
Did you restrict bisection to changes of a single file, or did you do it
on the full commit series?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
use case.
> https://sourceforge.net/p/testlilyissues/issues/5964/
> Since it got broken recently, that should be fairly easy to bisect.
Uh, there are several years of development between 2.20.0 and 2.21.1.
Unfortunately. But at least few version changes...
--
David Kastrup
___
}
>
> <http://lilypond.1069038.n5.nabble.com/file/t5463/BookOutputName_with_variable.png>
>
You don't say what your problem is and your screenshot is marked up with
conflicting statements.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
you post there, please also look there for
replies. For likely user-level problems rather than genuine LilyPond
bugs, please try the lilypond-u...@gnu.org list first.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.g
emolo-event. See:
>
> http://lilypond.org/doc/v2.18/Documentation/notation/writing-parts#quoting-other-voices
Huh. Why wouldn't that be the default? This report triggered a Deja vu
with me; I thought it was fixed previously? Or was this some other kind
of event recently added?
--
Dav
ields
and the last one before that in 2015 (something related to grace notes).
It has been ported over to Python 3, though.
I don't think there are active plans for anything at the moment (or even
any active developer who had significant involvement with abc2ly), so
feel free to jump in.
--
Dav
r GCC optimizing (!this) away as being always false, basically
because we called member functions on a null pointer, and the member
functions then checked the condition.
There are other reasons why current compilers do no longer compile
2.18.2, so it would be rather tricky to track this down.
lly I think it is
a bit too special-cased to certain context types, but one can probably
adapt it to be more general while leaving the same kind of messages for
the types you now special-cased.
Thanks!
--
David Kastrup
___
bug-lilypond mailing list
b
rather than
\consists "Merge_rests_engraver"
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Jean Abou Samra writes:
> Hi,
>
> Le 3 mars 2020 à 20:58, David Kastrup < d...@gnu.org> a écrit :
>
> Well, the less reason for quibbling (which I myself tend to indulge in
> more than appropriate) ends up on our list and the less confusion ends
> up wit
1 - 100 of 1958 matches
Mail list logo
