On 14 March 2010 15:38, Valentin Villenave wrote:
> I've been trying to build the docs with the attached patches for half
> a day without succeeding, so I figure it's time I call for help :(
>
> Can someone tell me what's wrong with these commits?
I've had a quick skim through both patches, and
On 9 March 2010 23:47, Valentin Villenave wrote:
> Don't we have a property for that?
In theory, Separating_line_group_engraver is supposed to prevent this,
but it doesn't work for objects attached to skips (hence why the same
problem rears its ugly head in the Dynamics context).
Cheers,
Neil
On 4 March 2010 11:59, Graham Percival wrote:
> Hopefully we can avoid having momentum on these issues stall, so
> please take a look at the patches.
Thanks for doing this, Graham.
Alas, the first patch doesn't work (another weird regression testing
glitch) and I'm still not satisfied with the
On 2 March 2010 11:25, Marc Hohl wrote:
> Thanks. Can you please push it? I am not allowed to...
I'm happy to push, but there seems to be a problem: the default
repetition function is the tablature version; I think this is due to
the parser evaluating the scheme code in the `tabChordRepetition'
On 25 February 2010 17:50, Reinhold Kainhofer wrote:
> It must be a very simple, stupid error in my code, but I'm simply unable to
> locate it. Here is my current patch (relativ to origin/master):
> http://codereview.appspot.com/224052
Wow, that's a great engraver description, Reinhold. It'd
On 16 January 2010 18:29, Neil Puttock wrote:
> Hi everybody,
>
> This patch allows an episema to be typset over a single neume (issue
> #189) and ensures it can be positioned correctly inside the stave.
> Since the requirements of an episema are slightly different from
> st
On 23 February 2010 09:29, David Kastrup wrote:
> For example, it would likely replace deseses by ais when bes would fit
> much better with the transposed key.
Surely you mean b or ces?
>
> I consider it likely a better idea to just move the notename in the
> direction of the overaccentuation u
On 21 February 2010 20:23, Mark Polesky wrote:
> I'd prefer the former, since maintaining the integrity of
> the program is a higher priority for me. I'm not a huge fan
> of syntax shortcuts, implicit instantiation, etc. I imagine
> these sorts of things can lead to problems down the road.
Tha
On 23 February 2010 20:21, Patrick McCarty wrote:
> Do you think I should try adding some code to
> lily/program-option-scheme.cc to set -dmusic-strings-to-paths in the
> case of -dbackend=svg ? That is, instead of setting it in
> scm/lily.scm ?
That sound feasible so long as the user's still a
On 30 January 2010 19:44, Patrick McCarty wrote:
> I could reproduce this too, so I must have flubbed something in the
> process of running `make check'.
Minor update: I also flubbed something while checking the svg output,
since I ran the test file using ly:set-option; I hadn't noticed that
thi
On 22 February 2010 17:31, Carl Sorensen wrote:
> I'm not sure exactly what the current proposed syntax is (we've had some
> discussions off-list, but not for a while). I would have expected him to
> add Markup 0-5, instead of SCM 0-4. But I haven't seen the specifics of his
> final proposal y
On 22 February 2010 16:39, Carl Sorensen wrote:
> Any concerns about me pushing this patch?
What's the proposed markup command which needs this?
LGTM, but will need documenting in Extending 2.2.3.
Cheers,
Neil
___
lilypond-devel mailing list
lilypon
Hi everybody,
I've been looking at changing the definition of make-ottava-set so it
doesn't use ApplyContext to change all the property settings, and I
have a patch which works, though I'd prefer to change the internal
representation of \ottava so it uses a stream event: this will
simplify the exp
Hi everybody,
I've posted a patch on Rietveld which enhances the behaviour of
\repeat percent by allowing single-beat repeats to be shown with
multiple slashes (if all durations are equal and duration >=
semiquaver) or as double-percent glyphs (varying durations).
I've moved the handling of the d
2010/2/17 John Mandereau :
> Neither can I. Sorry for top-posting but it seems this error is
> unrelated to the one you reported:
>
> error: cannot find description for property originalMiddleCPosition
> (translation)
> /home/lilydev/git/lily/master/out/share/lilypond/current/scm/lily.scm
> make[
On 17 February 2010 16:36, Carl Sorensen wrote:
> Yes, arbitrary properties can be added to the context. Context properties
> are stored as scheme alists. So that is a potential workaround that you
> could use now -- store the private data in a context property (which makes
> it not private, bu
On 9 February 2010 09:20, Marc Hohl wrote:
> So \stopStaff does currently not end the line prematurely, but
> simply tells lilypond not to draw the staff lines any further, right?
Yes. If it did the former, you'd get an automatic line break, and
you'd never be able to do a \stopStaff & \startSt
On 5 February 2010 08:38, Marc Hohl wrote:
> Any ideas/hints etc. are highly appreciated!
If you have a spacer rest after \stopStaff, there's no right edge for
the column which the segno's attached to (it's no longer the last
column in the system).
Regards,
Neil
<>__
On 5 February 2010 10:21, Marc Hohl wrote:
> Just curious:
>
> In line 205 of scm/output-lib.scm is the definition:
> ("|s" . (() . "|"))
>
> Is this bar line style used anywhere? I grepped in the sources and searched
> in the lsr,
> but found nothing...
It's undocumented, but creates a \bar "" a
On 4 February 2010 23:35, Carl Sorensen wrote:
> I think that Werner has found a regression.
>
> See Notation Reference 1.6.3 for 2.12. When the instrument name is changed,
> the first staff after the change shows instrumentName, and succeeding staffs
> show shortInstrumentName.
That's a bug, w
On 2 February 2010 22:54, Graham Percival wrote:
> I remember seeing some discussion and patches about fonts. If I'm
> not hallucinating, then any font-related contributor for 2.14 who
> isn't an official developer should be listed in
> Documentation/included/authors.itexi
> in the fontCurrent m
2010/2/1 John Mandereau :
> I'd suggest a list comprehension.
Ah, I didn't get that far down the page in the Python docs. :)
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
option.startswith (name):
1289 hash.update (option)
Cheers,
Neil
From 3f29f260a05e3fc3b0f16a1bf1495b90ac032026 Mon Sep 17 00:00:00 2001
From: Neil Puttock
Date: Mon, 1 Feb 2010 00:25:42 +
Subject: [PATCH] Fix lilypond-book option glitch
---
scripts/lilypond-book.py |
On 31 January 2010 17:59, Jean-Charles Malahieude wrote:
> It might help to keep in mind that the documentation is produced in 7 other
> languages than English. There is then 1 instance missing?
No, it's surely a bug (if it's not, it's a ridiculous change :).
There should only be one instance o
Here's an example picked at random from a fresh build:
%% Options: [alt=[image of music],alt=[image of music],alt=[image of
music],alt=[image of music],alt=[image of music],alt=[image of
music],alt=[image of
music],doctitle,doctitle,doctitle,doctitle,doctitle,doctitle,doctitle,indent=0\mm,indent=0
Hi Patrick,
Following your fontconfig caching improvements, my
fetaNumber/fetaDynamic glyphs have disappeared (see attached image).
Any idea what's going on?
I'm running Kubuntu 9.10 x64, which comes with fontconfig 2.6.0.
Thanks,
Neil
<>___
lilypond-d
2010/1/27 Carl Sorensen :
> I don't think there is a way to do this better as the code sits now. The
> accidentals in the ambitus are AmbitusAccidentals, and are create by the
> Ambitus_engraver, so the standard accidental styles (which might do what you
> want) don't apply.
Agreed. I think you
Hi Graham,
There's nothing in the documentation policy for \context block
formatting, but since you've amended some examples in the LM, I
thought I'd check what the preferred style should be to prevent any
confusion.
I much prefer the context name to be on the next line (this is how
I've always e
2010/1/26 Carl Sorensen :
> Should this be a separate patch, probably applied before the current patch?
Definitely a separate patch, though I think it can wait until this
patch has been sorted.
> I tried scm_call_5, and got a compile error. Then I looked at the guile
> page, and no scm_call_5,
2010/1/24 Graham Percival :
> Could you add some info about grand-replace.py to the CG? I'm
> thinking in the "release work" chapter, in the "administrative
> policies" section.
Done.
Regards,
Not Nick
___
lilypond-devel mailing list
lilypond-devel@
Hi Carl,
On 22 January 2010 03:14, Carl Sorensen wrote:
> Please review the patch at
>
> http://codereview.appspot.com/186268/show
I'll post some comments on Rietveld soon.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://
Hi everybody,
This patch allows an episema to be typset over a single neume (issue
#189) and ensures it can be positioned correctly inside the stave.
Since the requirements of an episema are slightly different from
standard TextSpanner grobs, I've decided to create a new engraver for
this purpose:
2010/1/16 Mark Polesky :
> http://kainhofer.com/~lilypond/Documentation/changes/index.html
This always happens with font changes on kainhofer.com since it
doesn't do a clean docs build every day.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-
2010/1/16 Mark Polesky :
> The example on the "changes" page is not displaying
> properly.
Where?
Looks fine here: http://lilypond.org/doc/v2.13/Documentation/changes/index#top
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
htt
2010/1/16 Carl Sorensen :
> Now if we didn't find an articulation on the note event, we search through
> the list of tabstring events to find a non-empty tabstring event. Why are
> we doing this second check? Is there another way to get a tabstring event
> besides adding a string as an articulat
2010/1/10 Carsten Steger :
> Also, from our discussion it would appear to me that the patch for the
> halfopen articulation character I have designed could be pushed.
LGTM, pushed to master.
I've just made one minor change: new features go at the top of changes.tely.
Thanks,
Neil
Hi everybody,
Please review this patch: http://codereview.appspot.com/186112/show
Following Joe's comments about my original patch
(http://lists.gnu.org/archive/html/lilypond-devel/2008-11/msg00380.html),
I considered making the 'bound-details changes in line-spanner.cc, but
have settled for a 'b
2010/1/11 :
> This does indeed look suspiciously close to the truth. But which part of the
> code might do this conversion? I looked at the level of raw module-define!
> and ly_module_lookup(), I do not see how these can contain any conversion
> code?
The conversion's done by scale-layout in pa
2010/1/1 Carl Sorensen :
> I think we should go ahead and push this patch (but if we need
> to wait for the new chord name code, I guess we can do so)
If you're happy with the slight change in behaviour, that's fine by me.
Regards,
Neil
___
lilypond-
2010/1/8 Marc Hohl :
> Yes, the picture in the tracker has one loop missing, but in
> all other sources, the sign looked (mainly) as mine.
How do they deal with the segno at the end of a line though? The
tracker example is aligned as a normal barline (i.e., with the
double-bar at the right edge)
2010/1/10 Werner LEMBERG :
> Has there been any change recently to lilypond which causes this
> regression? Obviously some time ago this snippet gave correct
> results...
Only due to a bug in accidental positioning: the two accidentals used
to be typeset in overstrike, so the 'extra-offset setti
2010/1/6 Marc Hohl :
> I've just posted a patch for the alternate segno sign.
> To use the new symbol stored at scripts.varsegno, I have
> adapted the arguments for the \bar command.
Very nice. It's a bit different from the examples posted on the
tracker, but looks very elegant. :)
Two general
2009/12/20 Graham Percival :
> 2.12.3 is out. The "stable version" number on lilypond.org has been
> updated. Could somebody add the announcement to the old website?
> Also, could somebody do the same for the 2.13.9 release?
All done.
Cheers,
Neil
_
2009/12/20 Carl Sorensen :
> I think I'd like to recommend that in the future, instead of emailing
> patches (with the associated problems with line endings), we just have Frogs
> post them on Rietveld.
I'd also recommend at least checking a snippet runs properly (if not
doing a regression test c
Hi everybody,
This patch does two things:
1) Fix issue #628, whereby grob 'style settings (e.g., TextSpanner
#'style = #'trill) interfere with the default notehead style for
\note(-by-number);
2) Use the code from note-head::calc-glyph-name to ensure all notehead
style can be set via 'style in \
2009/12/11 Werner LEMBERG :
>
> Thanks to Neil, TextSpanner items are now displayed in `Dynamics'
> contexts. However, this exhibits another serious annoyance, as shown
> in bug issue #928.
This should be fixed now, Werner. If you can confirm, I'll close #928.
Thanks,
Neil
___
2009/12/15 Trevor Daniels :
> but if I do this:
>
> SCM duration_symbol;
> Item *duration_grob;
> ...
> duration_grob = make_item ("TabDuration", events_[0]->self_scm ());
> ...
> duration_symbol = ly_string2scm ("A");
> duration_grob->set_property ("text", duration_symbol);
>
> the program
2009/12/15 Valentin Villenave :
> Hm, I forgot about that. We already encountered the same problem when
> Reinhold rewrote the \tempo command, for instance.
> *sigh* This is one of those limitations that make me want to bang my
> head against a wall. Do you think this could deserve a feature reque
2009/12/15 Carl Sorensen :
> Everything compiles OK. And it runs fine until I get into recheck_beam.
> Recheck_beam actually executes successfully, but an exception is thrown
> later, and the exception doesn't make sense to me when I use gdb. Values
> are changed between the calling procedure an
2009/12/15 Frédéric Bron :
> I think your problem may come from the fact that:
> * in Beam::set_beaming, "i" is a vsize (=size_t) which is an unsigned integer
> * in Beaming_pattern::beamlet_count, "i" is an int which is signed
No, that's only likely to cause a compilation warning, since `i' in
s
2009/12/15 Graham Percival :
> Check it here. It compiled, just about, with much cajoling, and
> that's good enough for me.
> http://lilypond.org/~graham/
Will check later. Can't at the moment since I'm testing Carl's
autobeaming patch.
> I see dead people. And also a lot of backports. Any
2009/12/15 Valentin Villenave :
> Please, please don't. To me, having the ability to use \relative
> without specifying a pitch is (and should remain) a feature, not a
> bug. Yeah, I know, that requires parsing, yadda yadda. We can live
> with it.
If it's really that important, then we shouldn't
2009/12/15 Graham Percival :
> 1) "why is `\relative {' being deprecated" -- see the mailist
> archives. I don't know the details, but Han-Wen suggested it, and
> he's the person who'd know. :)
A good reason would be that it would allow \relative to be removed
from the parser: currently we ne
Hi everybody,
While puzzling over the purpose of the method try_music (), I noticed
that the only engravers/translators to use this method are the type
swallowers/Swallow_engraver/performer. Since this method appears to
have been junked when the translator listener macros were introduced
for stre
2009/12/11 Trevor Daniels :
> I've just posted patch set 3 to Reitveld, after quite
> some struggles with juggling regression-testing and
> doc-building in a too-small virtual ubuntu system.
>
> See http://codereview.appspot.com/164063
Looks fine to me apart from some formatting nitpicks.
I'll po
2009/10/13 Neil Puttock :
> 2009/10/12 Joe Neeman :
>
>> Thanks for testing. Do you have an example to show the problem? It was
>> certainly my intention to have Dynamics work with alignment-distances.
>
> Sure, try this:
I've had another look at this, and it seem
2009/12/13 Graham Percival :
> Be warned that sometimes lilypond-book has hash collisions in the
> filename, which can lead to weird compile errors when one process
> finished dealing with aa/lily-.ps (and thus deletes it), while
> another process has finished generating aa/lily-.ps but ha
2009/12/12 Werner LEMBERG :
> have you finished your work on fixing #305? I can vaguely remember
> something into this direction ...
Not yet; I'm trying to sort out a consistent method for allowing
explicit directions to override the alignment spanner.
Cheers,
Neil
___
2009/12/13 Mark Polesky :
> Is there a way to improve this? I don't want to put too
> much extra stress on CPU1 if I run `make check' alot. Or am
> I being paranoid?
make -j5 CPU_COUNT=5 check
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-d
2009/12/11 Mark Polesky :
> Graham Percival wrote:
>> It was added as a short-cut hack for
>> << c1 {s4\< s s\> s\!} >>
>
> So then I assume you're okay with me de-quantizing the
> espressivo as well. Is the attached patch okay to apply,
LGTM.
> do I need to do anything described in CG 8.7 "Ad
2009/12/9 Trevor Daniels :
>
> Mark Polesky wrote Wednesday, December 09, 2009 9:05 AM
>>
>
>> Wow. It's been just over 94 (and a half) *days* since my last transmission
>> here. If > anyone is curious, I am still alive,
>
> Hi Mark - good to hear it ;)
+1
I was beginning to wonder whether you'd
2009/12/8 Werner LEMBERG :
>
> See issue #926. This makes the Dynamics context quite useless.
Fixed in git.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
2009/12/9 Harmath Dénes :
> Apparently, this got discussed in:
>
> http://www.mail-archive.com/fink-us...@lists.sourceforge.net/msg28916.html
> http://www.mail-archive.com/fink-us...@lists.sourceforge.net/msg29280.html
>
> but without solution. Can this be filed as a bug? Is there a workaround?
H
2009/12/8 Graham Percival :
> I was amused by the recent "punctuation fix" commit: I've always
> considered the CG to be "the guide for contributors", or "the
> contributors's [sic] guide". In modern English, the latter is
> abbreviated (condensed?) into "the contributors' guide".
Easily amused,
2009/12/3 David Kastrup :
> I keep asking for the testing, with little success so far. I still
> don't know whether the changes from a week ago solve the memory
> leak/corruption problem reported with a previous version.
Thanks, the latest patchset works fine (see attached test results),
and the
2009/12/2 Carl Sorensen :
> Oh, I had misunderstood. Actually, according to gdb, the \turn has a
> script-priority of 0.
Oops, of course, since it's the only Script in the stack.
>
>>
>>> Does this mean we need to establish the outside-staff-priority for *all*
>>> scripts?
>>
>> No, since some
2009/12/2 Trevor Daniels :
> Happy to do this, but I'm a little puzzled as
> the list seems far from complete. The
> tab-note-heads-engraver reads several event
> properties and sets 'text and 'staff-position.
> Should they be added to the list too, or are
> all read event properties excluded?
I
2009/12/2 Carl Sorensen :
> But it seems to me that if outside-staff-priority is set for one grob, and
> not for the other, then they should be compared by script-priority, since
> there is *not* an outside-staff priority.
That's exactly what I mean: in the case above, the turn has no
outside-sta
2009/12/1 Carl Sorensen :
> There is a question I have though,
>
> In your opinion, should
>
> c4^"1"^"2"\turn
>
> put the \turn at the top or the bottom of the stack?
I think I prefer leaving it as it is, otherwise it breaks the rule
that outside-staff-priority should only take precedence over
s
2009/11/29 Trevor Daniels :
> Well, they'll be based on TabStaff/TabVoice rather than
> Staff/Voice contexts. I think I prefer to have Tab in the
> name as that is what they are - Lute Tablature.
Fair enough; you're in charge here, so that's fine. :)
> Run make test-baseline - Problem!
> Appea
2009/11/28 Graham Percival :
> Ok. Could we get this added to makelsr.py ? I'd be surprised if
> it takes more than 1 line of python to strip all trailing
> whitespace.
If I can work out how to do it in python, sure. :)
Cheers,
Neil
___
lilypond-de
2009/11/26 Trevor Daniels :
> Is this a sensible/suitable/best approach? Any other
> comments welcome.
I can't see anything wrong with the approach you've outlined below.
> Lettered fret indications
> Based on "Letter tablature formatting" example from LSR
> Needs to be installed in scm/tran
2009/11/27 Graham Percival :
> or whether Neil automatically stripped out the extra whitespace when
> committing LSR updates
I strip all the trailing whitespace with sed after downloading the LSR tarball.
Cheers,
Neil
___
lilypond-devel mailing list
2009/11/25 David Kastrup :
> I have my doubts -j2 is concerned with the patch other than accidently.
I can only run make check successfully without it (though the results
aren't a pretty sight due to the large number of profile changes).
> Our results are so different that I have my suspicion th
2009/11/25 Francisco Vila :
> My imagemagick 6.3.7 does not accept this option
Neither does mine:
n...@cherry:~$ compare -version
Version: ImageMagick 6.5.1-0 2009-08-27 Q16 OpenMP http://www.imagemagick.org
n...@cherry:~$ compare -dissimilarity-threshold 1 a.png b.png diff.png
compare: unrecog
2009/11/24 David Kastrup :
> After applying http://codereview.appspot.com/160048> first,
> indeed the following diff that throws out all the toplevel scoping
> constructs and separate definitions of define-markup-command and
> define-markup-list-command passes the regressions tests. Furthermore,
2009/11/23 Reinhold Kainhofer :
> As the author of the harp pedals code, I'm fine with that change (provided the
> regtest still works, which I haven't checked).
The regtests are fine here, so I've pushed to master.
Regards,
Neil
___
lilypond-devel m
2009/11/23 David Kastrup :
> Reinhold Kainhofer writes:
>
>> Am Montag, 23. November 2009 01:03:10 schrieb David Kastrup:
>>> ---
>>> scm/define-markup-commands.scm | 3 +--
>>> 1 files changed, 1 insertions(+), 2 deletions(-)
>>>
>>> This patch series makes the syntax of builtin markup
>>> co
2009/11/22 Graham Percival :
> I'm vaguely aware of some discussion about a memory leak. Would
> anybody mind if we release 2.13.8 now?
>
> A few tests are in the usual place:
> http://lilypond.org/~graham/
The mingw binary works fine under Wine.
>
> The regtests look good, other than chords-fu
2009/11/22 Reinhold Kainhofer :
> This way, running lilypond on the konsole will simply execute the built
> lilypond binary from the build (=src) tree and use all include and scm files
> from the source tree, no installation necessary. Plus, I can always run the
> Kubuntu-installed lilypond 2.12.x
2009/11/21 David Kastrup :
> Modifying Lilypond, then recompiling and reinstalling. That's not the
> most hack-friendly way. I am still finding my way around.
You're only modifying .scm files, so there shouldn't be any
recompiling/reinstalling involved.
Regards,
Neil
2009/11/21 David Kastrup :
> Yes, but that is no fun since I need _new_ internals local to the staff.
If you're happy just using \markup, then you can add the new property
to instrument-specific-markup-interface (see
define-grob-interfaces.scm).
Regards,
Neil
__
2009/11/20 Reinhold Kainhofer :
> Using a deque instead of a vector works just fine.
This still fails for me with --disable-optimising:
Program received signal SIGSEGV, Segmentation fault.
0x005dc58e in Prob::internal_get_property
(this=0x7fff00cf8b30, sym=0x7435abe0) at prob.cc:152
2009/11/17 Han-Wen Nienhuys :
> My worry is that this might not work correctly for
>
> \tweak #'bound-details #'foo #'bar #22
>
> If that works, please ignore my comment.
No, that can't work, since the level of nesting varies. I don't see
it as a problem though since users are encouraged to over
2009/11/14 Han-Wen Nienhuys :
> Shouldnt this be something recursive? I thought properties could nest
> beyond one level.
I don't see how it can be, unless you mean building the property alist
given the list of symbols and a value to set.
The problem with the current behaviour is that it's only
2009/11/14 Neil Puttock :
> IIRC, you mentioned this before; I think it's to do with (your) emacs
> expecting a colon at the end of the macro (which isn't strictly
> necessary).
D'oh. I mean semicolon of course. :)
___
lil
2009/11/13 Graham Percival :
> Oh, and there's lots of
> MAKE_SCHEME_CALLBACK (Axis_group_interface, print, 1)
> -SCM
> + SCM
My emacs doesn't do this. :)
IIRC, you mentioned this before; I think it's to do with (your) emacs
expecting a colon at the end of the macro (which isn't strictly
neces
Hi everybody,
Please review this patch:
http://codereview.appspot.com/152127/show
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
2009/11/13 Graham Percival :
> Would it be worth adapting _ as an alternative to spaces inside
> illustrations inside comments, just to avoid this problem?
> Stating that the code style is "whatever emacs does, as long as
> you manually revert its formatting in areas X Y and Z" is getting
> really
2009/11/13 Graham Percival :
> I guess I could test this tomorrow.
Doesn't work for me unfortunately:
WARNING: Unable to find node 'Scheme tutorial' in book learning.
cp /home/neil/lilypond/Documentation/css/*.css out-www/contributor/
cp /home/neil/lilypond/Documentation/css/*.css out-www/notati
2009/11/13 Graham Percival :
> If you could choose one such example, and add it somewhere to the
> CG similar to this:
> http://lilypond.org/doc/v2.13/Documentation/contributor/Sectioning-commands
> (bottom of the page)
>
> that would be awesome.
It's already there in section 8.5.5 (you added it
2009/11/12 Chris Snyder :
> After the on-going discussion that included talk about formatting, I did a
> quick search for automatic code formatters, starting with one for the C++
> code (I think it's reasonable to expect to use a different formatter for
> each programming language). I came across o
2009/11/12 :
> Is the patch ready to push now?
LGTM, apart from a few remaining whitespaces and wonky indents. :)
I've sorted these and will push to master shortly.
Thanks for being so patient,
Neil
___
lilypond-devel mailing list
lilypond-devel@gn
Hi all,
Though strings are valid markup objects according to the type
predicate `markup?', the parser only recognizes full_markup objects as
valid for music functions, which means it's currently impossible to
pass both strings and markups unless using Scheme.
I've posted a modest patch here,
htt
2009/11/9 Marc Hohl :
> I added another version of my patch without these comments;
> I tried to fill the [DOCME] in the description tag with something more
> useful.
Cheers, it's applied.
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@
2009/11/9 :
> This patch fixes 786 (and 800, which I think should be labeled a dupe).
I can't verify #800 here; the extender's still too short.
> No regression tests were adversely affected, but there could possibly be
> some issues with creating "empty" LyricText objects.
Can you check lyric-
2009/8/27 Neil Puttock :
> http://codereview.appspot.com/109113/show
I've made a small improvement to grid-line-interface::print.
Any comments? :)
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org
2009/11/8 Michael Käppler :
> Here you are.
Cheers, it's applied.
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
2009/11/6 Marc Hohl :
> Ready to be applied?
LGTM.
I don't think these comments are necesary though:
+ %% No key in tablature!
+ %% No string numbers ;-) !
+ %% No ottava spanners
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gn
2009/11/6 Michael Käppler :
> Maybe you can have a look at it. It's just the most important things for
> now, maybe it should be extended later.
Just a few minor quibbles:
+The amount @code{inner-margin} is additionately increased
additionally (though I'd probably remove this, since `increased'
401 - 500 of 1080 matches
Mail list logo
