On Thu, 7 Mar 2024, 14:24 , wrote:
>
> \include "hel-arabic.ly"
> \relative {
> \key do \rast
>
Shouldn't this be
\key c \rast
?
c' d edb f | g a bdb c | eb a g f | edb d c
> }
>
> => rast1.png
>
>
> Hassan
>
Neil
>
On Tue, 16 Apr 2019 at 12:30, Malte Meyn wrote:
> Thanks for the hint! I had already seen that (only then I realised that
> \fermata already creates a MultiMeasureTextEvent and
> MultiMeasureRestText grob that just has an 'articulation-type instead of
> 'text property). But your hint made me look
Hi Malte,
On Mon, 15 Apr 2019 at 10:55, Malte Meyn wrote:
> Are there any other ideas how the R\fermata thing could be done?
Check out scm/lily-syntax-constructors.scm, where there's a
constructor for MM rests:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=scm/ly-syntax-construct
Hi Janek,
On 1 August 2014 13:32, Janek Warchoł wrote:
I'm putting a modest bounty on
> https://code.google.com/p/lilypond/issues/detail?id=4044 - this
> problem is a nuisance for my work on predefined instruments, so i'd
> like to see it disappear.
I remember looking at this a while ago. If
On 5 April 2013 17:47, Janek Warchoł wrote:
Regardless of it being a spanner, i've tried to find where
> MultiMeasureRestText's (and MultiMeasureRestNumber's) Xparent is set,
> but without sucsess. I thought that maybe it happens in line 240 of
> paper-column-engraver, but apparently not.
Span
On Mar 17, 2013 11:10 AM, "m...@mikesolomon.org"
wrote:
> In the stop_translation_timestep method of the lyric engraver, lyrics are
given note heads as parents. Could you send a minimal where the lyrics are
unassociated from note-heads?
\lyrics { do re mi }
If there's no associated voice the l
On Feb 28, 2013 8:37 PM, "m...@mikesolomon.org"
wrote:
> You're right, but I've opted for the breaking behavior in the most recent
patch-set (\breakSlurHere). Otherwise, slurs wouldn't be able to span only
one musical moment.
Ok, so how about using an event of class break-span-event (like
\brea
On Aug 28, 2012 12:14 PM, "m...@mikesolomon.org"
wrote:
> I'm a bit short on time but could someone do some snooping to try and
figure out what the problematic commit is?
I don't think there is one. I can't double check at the moment, but
there's a dubious callback for BarNumber self-alignment-
On 15 July 2012 22:22, Phil Holmes wrote:
> Could someone have a look at http://lsr.dsi.unimi.it/LSR/Item?id=190 and say
> what's wrong with it, please?
It uses extra-offset to move the segno, so no space is reserved for it
on the left hand side.
Cheers,
Neil
___
On 31 May 2012 18:40, wrote:
> Thank you for reviewing this, Neil!
You're welcome. :)
LGTM.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 27 February 2012 13:48, Graham Percival wrote:
> What would be involved in making a clean solution for this? I
> imagine that a separate TextMark engraver (just like the
> RehearsalMark engraver and MetronomeMark engravers) would do the
> trick, but that's a bunch of icky C++ code. Is there
On 23 February 2012 17:04, Francisco Vila wrote:
> I can fix this by my own if anybody does not provide me a title before.
> Thanks.
The title must be "Glissandi can skip grobs" to match the file name.
Cheers,
Neil
___
lilypond-devel mailing list
li
On 6 February 2012 16:59, wrote:
> Should have added before: the most recent patch set is not bug free.
Cyclic dependencies for TextScript Y-offset.
But you've just fixed that by the look of it. ;)
> I'm fixing all of the regtest issues, but what I need most from other
> people who have a few
2012/1/26 Janek Warchoł :
> A potentially silly question: does make doc include running regtests?
> (i don't mean regtest comparison, just compiling all the snippets)
> I don't see anything about it in CG.
Yes.
Cheers,
Neil
___
lilypond-devel mailing l
On 23 January 2012 01:02, wrote:
> Regarding comments by Neil and Bertrand:
>
> I rewrote Stem::is_normal_stem the way Neil suggested. Looking at the
> code in Stem.cc, it appears that both ways are being used to check the
> style property. I don't know which is the more correct.
Strictly speak
On 20 January 2012 17:32, David Kastrup wrote:
> n.putt...@gmail.com writes:
>
>> Hi David,
>>
>> Should I wait for a new patch or can I test using the latest one here?
>>
>> I've tried it out briefly on a real music example, and have a problem
>> with identifiers:
>>
>> foo = \mark \default
>>
>>
Hi,
The clickable examples in the docs have stopped working. The links
appear to be broken since they're missing the .ly suffix.
Try the example on this page:
http://lilypond.org/doc/v2.15/Documentation/learning/clickable-examples
It goes to
http://lilypond.org/doc/v2.15/Documentation/9e/lily
On 12 January 2012 15:43, wrote:
> Unfortunately, that doesn't seem to do anything. Unless I'm not
> accessing the property correctly ... see the latest patch.
You're trying to access style from the Stem instead of the NoteHead.
Cheers,
Neil
___
lil
On 11 January 2012 17:13, wrote:
> I've posted a potential solution to get rid of the "stems", but it's not
> very elegant because it breaks the pattern.
>
> Perhaps someone else has a better idea.
Add a check for kievan style in Stem::is_normal_stem ().
Cheers,
Neil
_
2012/1/8 Janek Warchoł :
> ok, i think i understand what you said (that's a success :) ), but i
> don't know what should i use instead of glyph-name callback - a hint
> please?
Write an offset callback instead? It should be safe to access
glyph-name at that point.
Cheers,
Neil
2012/1/8 Marc Hohl :
> Are you sure the attached patch is up-to-date with your work?
> I get a small change clef in the fifth line, see attachment.
I get the same result as Janek. I think the problem is that the
glyph-name callback checks break-status, thus shouldn't be called from
the engraver
On 8 January 2012 15:45, David Kastrup wrote:
> I am also replacing the flowery language "Use like @code{\\tweak}." and
> "Use like @code{\\once}." since neither makes any sense whatsoever: you
> don't use the first before a postevent,
What's a postevent these days then? If you want to tweak an
On 1 January 2012 19:37, David Kastrup wrote:
> Done, so let's see if this gets through to master, and if it does, you
> might want to try the LSR updating procedure again.
You need to remove the comment block at the top, the texidoc
translations and `% begin verbatim' comments. These are all a
On 7 November 2011 19:32, Graham Percival wrote:
> Failing either of these, I guess we're into git bisect time, which
> of course sucks for doc-building if you're not Phil or James. I
> know that Phil can build the docs, but hopefully James' computer
> will fail in this same way?
I've just fini
On 21 October 2011 12:39, wrote:
> For me, this function is totally useless. If we want to check whether
> they are equal, we use scm_equal_p, if we want to see whether they are
> the same object, we use scm_eqv_p.
>
> Besides, I can't find any use for this function with git grep.
I think Guil
On 21 October 2011 07:50, Mike Solomon wrote:
> Of this I am not sure. My gut says yes, but I don't know why the regtest
> that skips quanting was added and the extent to which quantless-beams are
> used by users.
Never, I'd imagine. I certainly don't recall any users wanting to
switch it of
On 20 October 2011 15:01, David Kastrup wrote:
> I think the current state of dev/syntax should be committable. It has
> no problems accepting context modifications. The function signature of
> ((string? "Bottom") ly:context-mod?) should work just fine for accepting
> an optional context string
On 8 October 2011 17:41, Graham Percival wrote:
> Yeah, that's the point of using one of the other commands; you can
> specify the branch. There's also some way of specifying the
> branch using the bin/gub method too... it'd be listed in
> lilypond.make... but I don't have it written down handy.
On 8 October 2011 16:23, Graham Percival wrote:
> I /think/ it's this command you want:
>
> python bin/gib --platform=mingw
> --branch=lilypond=git.sv.gnu.org--lilypond.git-master lilypond
>
> (all on one line)
>
> but it might be this one instead:
>
> bin/gub --platform=mingw
> 'git://git.sv.gnu
On 1 October 2011 18:19, Peekay Ex wrote:
> Neil what command do you run when you do a test-baseline so that I
> might get something like you do?
I don't. :) I couldn't work out which file was failing, so I did what
I usually do: run all the regression tests until it crashes.
The output I've p
On 1 October 2011 18:16, Graham Percival wrote:
> The problem is verified; I see exactly the same behaviour as Neil
> with 4f49b000d6e257724e311b406e2346b8388c1f0e
Here's a minimal snippet which fails:
\version "2.15.14"
\relative c' {
\times 2/3 { f8 e d }
}
Cheers,
Neil
_
On 1 October 2011 18:04, m...@apollinemike.com wrote:
> A follow-up: I can't figure out how the error could come about.
> Interval::center should, in Tuplet_number::calc_y_offset, always be getting
> an interval for which it can find the center (it uses robust_scm2interval).
> Does anyone wi
Hey guys,
I can't complete test-baseline due to an assertion error running
mozart-hrn-3.ly. Here's the backtrace:
Drawing systems...lilypond: ../flower/include/interval.hh:226: T
Interval_t::center() const [with T = double]: Assertion `!is_empty
()' failed.
Program received signal SIGABRT, Abor
On 26 Sep 2011 09:08, "m...@apollinemike.com" wrote:
>
> is anyone else getting:
>
> warning: identifier name is a keyword: `relative'
Sounds like you've pulled the latest changes without rebuilding.
You'll only get that message if the lexer hasn't been recompiled, since
David's removed that tok
On 19 September 2011 19:48, m...@apollinemike.com wrote:
> What I'd really like to know is why the spring ideal and minimum distances
> are different just by virtue of its belonging to the array, but I have a
> feeling the answer lies deep in the bowels of the horizontal spacing code and
> I d
On 25 September 2011 15:19, Phil Holmes wrote:
> a) I believe the slashedGrace function is
> to allow a slurred grace note inside a slur
Nope. Reinhold recently added support for separate slurs on graces,
so they work fine nested inside other slurs.
b) I'm not convinced a tied grace note makes
On 22 September 2011 17:38, Graham Percival wrote:
> On Thu, Sep 22, 2011 at 02:46:38PM +0100, Phil Holmes wrote:
>> There are 2 significant problems I've found with 2.15.12.
>
> Could we get issues for these? I should probably cancel the
> release countdown.
I can't verify either problem here.
On 22 September 2011 12:48, Phil Holmes wrote:
> We probably need to learn how to use git bisect...
It's David's most recent commit: 6c3445a0791831d450573cf583da36aecac5322c
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://
On 20 September 2011 21:50, Benkő Pál wrote:
> I don't know what to do, could you help me?
The attached patch works for me (haven't run make check on it though).
Cheers,
Neil
From f6f1ad62263b4dfb5f518da71891d3a0b30c89a3 Mon Sep 17 00:00:00 2001
From: Neil Puttock
Date: Tue, 20 S
2011/9/20 Neil Puttock :
> I'm running make doc with the patch applied at the moment. Will
> report any problems.
There's nothing wrong with the patch as far as I can tell. Make doc
completes successfully here.
The only thing that's missing is an entry in
Documentat
2011/9/20 Janek Warchoł :
> I'm not sure what is your opinion on this patch currently. Do you
> agree to push it if it doesn't break make, make doc and regtests? Do
> you agree with my comment no.7
> http://code.google.com/p/lilypond/issues/detail?id=1873#c7 ?
Yes.
I'm running make doc with th
On 17 September 2011 15:45, Mike Solomon wrote:
> The problem comes not from this patch but from the calculation of the
> horizontal skylines for NonMusicalPaperColumns. Try adding:
>
> \override Score . NonMusicalPaperColumn #'stencil = #ly:separation-item::print
>
> To the beginning of Sopran
On 17 September 2011 12:16, m...@apollinemike.com wrote:
> They should be applied separately - 5038042 fixes 1881, and 5057041 prunes
> down bloated code. There is a chance that 5057041 is effected by 5038042 (I
> haven't tested them together yet) though I doubt it. After their countdowns,
>
On 16 September 2011 12:50, Peekay Ex wrote:
> The CG doesn't mention this for reg test checking.
Indeed, it only mentions this for debugging.
> Is this something I should be doing now and if so does it matter where
> this switch comes in the syntax?
It's part of the configure process, so eith
On 17 September 2011 09:27, Peekay Ex wrote:
> I don't know if this is expected based on either/both commits but in
> the two reg tests the 'instrument names' have now disappeared.
Nope, it's a regression. I'm afraid Joe's fallen into the same trap I
did when I looked at issue #1598. We can't
On 15 September 2011 23:04, wrote:
> On 2011/09/15 21:41:27, Neil Puttock wrote:
>
>> For some reason, your patch fails `make check' on my system.
>
> Neil, I've just applied this patch - after seeing your note - to the
> latest 'git pull -r' and
On 15 September 2011 14:43, wrote:
> Done, typical beginner imperfections, thanks for pointing out.
Thanks. :)
For some reason, your patch fails `make check' on my system. I
consistently get SIGABRT thrown soon after running:
job 2 terminated with signal: 6
job 1 terminated with signal: 6
On 15 Sep 2011 00:31, "Carl Sorensen" wrote:
>
> On 9/14/11 4:31 PM, "Graham Percival" wrote:
>
> > There's been no action on this for a few weeks. I'm starting to
> > wonder if we should abandon this proposal and try bringing it back
> > in a few months.
>
> Why?
>
> The only outstanding issue
On 12 September 2011 20:45, Reinhold Kainhofer wrote:
> Exactly, that was my idea. My problem is that I can't do it like in the
> percent repeat case, where we have percent-repeat-events (generated in the
> iterator), which start at the right moment and have the correct length. In the
> measure c
On 12 September 2011 20:03, Reinhold Kainhofer wrote:
> Any idea how to implement this?
Shouldn't it just be a spanner whose bounds are the left column and
right column for each bar? Similar to a full-bar rest or percent
repeat.
Cheers,
Neil
___
lil
On 12 September 2011 13:47, Marc Hohl wrote:
> I created a new directory, made a git repository from scratch,
> changed the one line and did
>
> make all
> make doc
Hmm, in that case, I'm not sure why it doesn't work. I assume you
changed the offending line to this:
@funindex \\~a
Cheers,
Nei
On 12 September 2011 13:49, David Kastrup wrote:
> Not as long as I have not checked and pushed appropriate changes.
I don't see how that's relevant. You've broken the way the argument
list is documented for each function. That has no bearing on the way
music functions are indexed.
Cheers,
Ne
On 12 September 2011 13:32, Marc Hohl wrote:
> ok, but does that mean that issue 1135 can be closed?
> As mentioned elsewhere, I replaced @findex by @funindex in
>
> scm/document-identifiers.scm
>
> but this seems to change nothing ...
Did you ensure it's rebuilt properly? IIUC you need to touc
2011/9/12 Janek Warchoł :
> 2011/9/12 Marc Hohl :
>> Do I understand issue 1135 right - the scheme functions should get listed
>> on out-www/offline-root/Documentation/internals/scheme-functions.html?
>>
>> Or am I searching on the wrong place?
>
> I'm not the one who can answer this question :(
>
On 10 September 2011 14:59, Neil Puttock wrote:
> Hi guys,
>
> This perfectly innocent looking snippet spits forth several errors
> with current master:
Of course, I mean cyclic dependencies. :)
These are pretty serious. I haven't done `make check' for a few weeks
and
On 11 September 2011 16:02, David Kastrup wrote:
> git grep '\\relative [^@a-z]'
>
> has a hit rate of close to 100%.
Most of those are regression tests added after Mark's work.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http
On 11 September 2011 15:22, Graham Percival wrote:
> On Sun, Sep 11, 2011 at 03:58:32PM +0200, David Kastrup wrote:
>> One could start by removing it from snippets and regtests.
>
> Yes, one could.
Hmm, there shouldn't be any since Mark P removed them all a while ago.
I suppose a few must have
On 10 September 2011 21:34, Graham Percival wrote:
> Neil: is it ok to run makelsr.py locally? I think that
> translators and some programmers need this, but if you're rather
> deal with it yourself, that's fine.
Local updates shouldn't pose any problems.
Cheers,
Neil
Hi guys,
This perfectly innocent looking snippet spits forth several errors
with current master:
\version "2.15.11"
\relative c' {
s2. c8[ c
c8 c]
}
/tmp/tmpJ8GqW5/document.ly:4:8: programming error: cyclic dependency:
calculation-in-progress encountered for #'quantized-positions (Beam)
s
On 5 September 2011 20:10, David Kastrup wrote:
> I suggest trying the following Lilypond fragment out.
>
> #(define (make-accidental-mod style)
> "Make a context modification from accidental style @var{style}."
> (let ((style-settings '(1 2 3 4)))
> #{ \with { extraNatural = #(cadr $style-se
On 5 September 2011 20:04, Reinhold Kainhofer wrote:
> Ah, I see. The problem is that the context mods are also used inside context
> definitions, like
>
> a=\with {
> \description "Some mod"
> ...
> }
> \context {\Score
> \description "context desc"
> \a
> }
>
> This is effectively the same
On 5 September 2011 17:29, wrote:
>
> http://codereview.appspot.com/4819064/diff/1/lily/context-mod-scheme.cc
> File lily/context-mod-scheme.cc (right):
>
> http://codereview.appspot.com/4819064/diff/1/lily/context-mod-scheme.cc#newcode45
> lily/context-mod-scheme.cc:45: LY_DEFINE (ly_make_contex
On 5 September 2011 17:29, wrote:
> It's hard for me to track all of this carefully, but I much prefer the
> context mod approach to the ly:export approach.
>
> LGTM
Thanks. :)
BTW, this doesn't bypass the existing ly:export version, since that's
still required for setting accidental styles in
On 5 September 2011 17:21, wrote:
> LGTM.
Thank you. :)
> http://codereview.appspot.com/4819064/diff/1/lily/parser.yy
> File lily/parser.yy (right):
>
> http://codereview.appspot.com/4819064/diff/1/lily/parser.yy#newcode670
> lily/parser.yy:670: continue;
> What exactly is the reason for this h
On 5 September 2011 17:15, James Lowe wrote:
> Pass make and reg test
>
> ;)
Hehe, I'm grateful as always for your testing work (and quite envious
of your ninja PC, but can't justify an upgrade yet. :)
Cheers,
Neil
___
lilypond-devel mailing list
lil
On 4 September 2011 20:39, Graham Percival wrote:
> Since Colin is off on holiday in the best place on earth (i.e.
> Western Canada), I'll send the reminder.
>
> All the above people: you have patches that should be pushed.
> http://code.google.com/p/lilypond/issues/list?can=2&q=label:patch&sort=p
On 24 August 2011 22:26, Graham Percival wrote:
> No complaints from last time, with the possible exception of Neil
> wanting a different behavior for (else...)
I haven't had time to test it thoroughly since my last comments, but
there are some other issues which will need fixing before we can ap
On 18 August 2011 13:44, Mike Solomon wrote:
> What about pure-container ?
It's all right, I suppose... but what about the unpure part? After
all, the container's not just about the pure callback.
Cheers,
Neil
___
lilypond-devel mailing list
lilypon
On 18 August 2011 22:46, Reinhold Kainhofer wrote:
> BTW, I managed to get the LSR-copy running on my machine:
> http://lsr.kainhofer.at/LSR/
>
> (the jail is set up but not yet used for compiling)
>
> HOWTO as usual at http://wiki.kainhofer.com/lilypond/lsr_setup
Wow, that's awesome work, Reinh
On 15 August 2011 13:31, wrote:
> Also, just a quick reply to let you know that the calc_stem_end and
> calc_stem_begin methods are left in the code base for people who want to
> override the Y-extent of the stem while conserving either the beginning
> or end of the stem, ie:
>
> \override Stem
On 14 August 2011 01:03, Ricardo Wurmus wrote:
> So ly:glob-property has side effects because of the stem callback?
> How can I make sure to get the final stem direction after all
> dependent properties were calculated?
>
> I want to replace a note head with a triangle, but there is a gap
> betwe
On 13 August 2011 20:06, Carl Sorensen wrote:
> De we have a standard for how much indentation we should have for each type
> of compound expression?
>
> define
> let
> begin
>
> all get two, apparently.
>
> I see some sources that show that
>
> list
>
> gets one.
>
> Are you aware of a definitiv
On 13 August 2011 17:14, Ricardo Wurmus wrote:
> I'm having a problem with a scheme engraver. Whenever I fetch the
> direction property of a grob's stem object (or directly through a
> listener on stem-event), the following warning is shown:
>
> warning: no viable initial configuration found: m
On 12 August 2011 01:44, Carl Sorensen wrote:
> Yep. Here it is, along with the change to /usr/bin/env guile.
I had to change this to
/usr/bin/guile
to get the script to work:
/usr/bin/env: guile -s: No such file or directory
> I think I'm really going to like having this, if we can get all
On 11 August 2011 12:34, m...@apollinemike.com wrote:
> I figured out why it works - I figured I'd post this to the list in case
> anyone else ever wants to mess around with pure properties.
>
> The StemTremolo is added to the paper column's element grob array via the
> axis-group-engraver beca
On 10 August 2011 15:00, Ricardo Wurmus wrote:
> Is there a way to change that order, or call the note-head-interface
> function again at the very end for processing a grob?
Acknowledger order depends on the order engravers are \consist-ed (the
only exception is if you set must-be-last to #t)
I
On 9 August 2011 09:47, Phil Holmes wrote:
> I said in a separate message that this isn't necessary. The link is
> automatically converted to a clickable link.
This only works reliably with Adobe Reader.
Foxit produces an incorrect link: mutopia.org/It (it picks up the
start of the next line)
On 9 August 2011 20:21, Reinhold Kainhofer wrote:
> So having only 9 warnings in our codebase (four of which are in the
> lexer/parser, which hardly anyone of us really understands!) is amazing.
There are many more warnings (> 180) if you're compiling a 64-bit
binary. They could be silenced via
On 8 August 2011 09:09, m...@apollinemike.com wrote:
> Question: on line 722 of axis-group-interface.cc, I see:
>
> while (i + 1 < elements.size ()
> && scm_eq_p (elements[i + 1]->get_property
> ("outside-staff-priority"), priority))
>
> Shouldn't this be:
>
> while (i + 1 <
On 8 August 2011 12:43, David Kastrup wrote:
> I have no clue what start and end are
start and end are column ranks, i.e., an index to the position of a
particular column in a score. You can see them if you enable
debugging for columns:
\relative c' {
c1
}
\layout {
\context {
\Score
On 9 August 2011 07:41, wrote:
> On 2011/08/09 05:08:56, hanwenn wrote:
>>
>> LGTM
>
>> note that image of the issue will also require a minimum distance
>
> setting,
>>
>> otherwise, the glissando will be shortened into a dot?
>
> Done. New patchset uploaded.
This doesn't ensure the glissando'
On 7 August 2011 21:33, wrote:
> Before I push this (and as Neil has just done an LSR update) do I still
> need to run makelsr.py before applying this patch once it has been
> approved?
Nope.
> I have removed one snippet from both dirs (snippets/new and snippets).
Don't forget to remove the t
On 7 August 2011 21:58, James Lowe wrote:
> I guess that opens a whole new vista of questions - i.e. along the lines of
> how would I know that if its not documented in the IR
How is it not documented?
If I navigate to TieColumn,
http://lilypond.org/doc/v2.15/Documentation/internals/tiecolumn
On 7 August 2011 20:48, Reinhold Kainhofer wrote:
> I wouldn't go that lowlevel. I rather thought about a scheme function that
> prints a ly:warning and then returns the new definition (or calls the new
> function).
How would you prevent the deprecation warning from being issued when
the identif
On 7 August 2011 20:21, wrote:
> http://codereview.appspot.com/4672059/diff/1/ly/property-init.ly
> File ly/property-init.ly (right):
>
> http://codereview.appspot.com/4672059/diff/1/ly/property-init.ly#newcode189
> ly/property-init.ly:189: fermataMarkup = \fermata
> How about a wrapper to mark
On 7 August 2011 17:01, wrote:
> Nice! LGTM.
Thank you.
> Will need some doc changes too.
Indeed. I'll sort that out later (+ a regression test to exercise the
code properly).
> Should we deprecate \fermataMarkup?
I think so. A convert rule would be reliable since it's just a substitution
Hi James,
There's nothing wrong with the following:
However, the @code{tie-configuration} property of
@code{TieColumn} can be overridden to set start line and direction
of ties as required.
'tie-configuration *is* a property of TieColumn, but one that happens
not to be set by default (that's wh
On 6 August 2011 15:31, David Kastrup wrote:
> I have a hard time counting the removal of a band aid for an artificial
> test case with undefined behavior (try finding a place in the user
> documentation that declares this kind of code as producing predictable
> results) as a regression because t
2011/8/4 Xavier Scheuer :
> That has been registered as issue #1774, isn't it?
> http://code.google.com/p/lilypond/issues/detail?id=1774
Not quite. Gould makes an exception for semibreves with adjacent
notes; in this case, they should be aligned as if they had stems:
\version "2.15.9"
\new Sta
On 29 July 2011 17:20, Graham Percival wrote:
> Could somebody get rid of these already? They're left-over from
> Valentin's note name changes from Dec 2010 or so;
They come from parsing string-tunings-init.ly.
> they were
> debugging messages which were supposed to be removed, but weren't
> c
On 29 July 2011 22:44, wrote:
> Just to be sure I understand, you'd prefer to require a manual tweak to
> deal with the dynamic in the example snippet, rather than allow the
> automatic behavior introduced with Keith's patch.
The automatic behaviour is undesirable, since it introduces extra
spac
On 28 July 2011 15:57, wrote:
> Many thanks to everyone for their help on this.
>
> Pushed as 233aad0ba9781e43424c4e77a859e42b660210e6.
Hi Mike, can you look at my comments from a month ago please? I
believe some of them are still relevant.
Thanks,
Neil
___
On 26 July 2011 22:41, David Kastrup wrote:
> So the question basically is: which of those mechanisms is actually
> being in use? Are there examples for existing music functions
> interpreting a postevent or a chord constituent?
\tweak would be the most common usage for both of these cases:
c1
On 26 July 2011 11:17, m...@apollinemike.com wrote:
> This is my fault. I don't know why I missed it these warnings in the
> side-by-side comparison, but I won't let this slip again.
It isn't your fault. There were no warnings.
It appears David's getting warnings from the more recent change
On 26 July 2011 18:43, David Kastrup wrote:
> Come on. I got pointed to this patch because _warnings_ occured. Don't
> tell me "David is the only one who can see warnings". The patch is in
> an area I have no clue about. _Anybody_ with reasonable C and Scheme
> experience would have seen the
On 24 July 2011 19:51, m...@apollinemike.com wrote:
> On Jul 24, 2011, at 6:43 PM, James Lowe wrote:
>
>> Hello,
>>
>> From Neil P. explaining the finer points of footnote code, while looking at
>> my in-progress Doc patch for footnotes
>>
>> --snip--
>>
>> \footnote associates a single footnote
On 23 July 2011 15:48, wrote:
> (a) is currently impossible to calculate in all circumstances, and (c)
> would require a code dup. I think by making these available as
> properties, the user can then use this data to fix the problem. In the
> example given in Issue 36, I would personally rotat
On 24 July 2011 09:55, m...@apollinemike.com wrote:
> Why is it a bad thing to do it this way? Currently, the
> Beam_collision_engraver implements dynamic filtering based on interface, and
> I don't think there's a problem with that (it is the only way to make it
> ignore certain grobs on the
On 23 July 2011 23:05, wrote:
> Can you give me an idea what his does and how to test this or what I am
> going to see as someone who runs a lot of make/reg tests?
If somebody forgets to document a new property (in
scm/define-grob-properties.scm or scm/define-context-properties.scm)
this will en
On 23 July 2011 04:07, Graham Percival wrote:
> Presumably a different problem this time?
>
> I know that Carl is either flying to Korea, or just about to fly
> to Korea, so could somebody else look into this? You should be
> able to "make doc" on stable/2.14 from scratch. It doesn't work
> in p
1 - 100 of 1080 matches
Mail list logo
