Re: Issue 943 in lilypond: A slur should follow the same vertical direction it would have in unbroken state.
Comment #4 on issue 943 by jameseli...@googlemail.com: A slur should follow the same vertical direction it would have in unbroken state. http://code.google.com/p/lilypond/issues/detail?id=943 Sure, a slur should follow the same vertical direction because the regtest for slur-broken-trend.ly says so, and this was the behavior in 2.12. Sorry about the \version line. I learned it's easier to work without them when compiling with two different versions. And I'm sorry, but I can't wrap my head around texinfo. If I had a couple of months to figure it out, I probably could, but as it is, I really don't understand it at all. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Tempo / tuplet bracket bug
Hi,
The following snippet exhibits a bug in the form of contention between
metronome mark and tuplet instantiation:
%%% BEGIN TEMPO INSTANTIATION BUG %%%
\version "2.13.9"
\new Staff {
\time 2/8
\times 2/3 {
\tempo 8=52
c'8 (
c'8
c'8
}
\time 2/8
c'8
c'8 )
}
%%% END TEMPO INSTANTIATION BUG %%
The interpreter gives the following warnings:
GNU LilyPond 2.13.9
Processing `0329.ly'
Parsing...
Interpreting music...
programming error: stopped tuplet bracket has left nor right bound.
continuing, cross fingers
0329.ly:10:10: warning: unterminated slur
c'8
(
0329.ly:16:10: warning: cannot end slur
c'8
)
Preprocessing graphical objects...
Solving 1 page-breaking chunks...[1: 1 pages]
Drawing systems...
And the output is attached here as tuplet-bracket-bound-bug.png.
The problem apparently has to do with the lexical spot at which the tempo
mark instantiates. Moving the tempo mark prior to the tuplet \times command
provides a workaround:
%%% BEGIN WORKAROUND %%%
\version "2.13.9"
\new Staff {
\time 2/8
\tempo 8=52
\times 2/3 {
c'8 (
c'8
c'8
}
\time 2/8
c'8
c'8 )
}
%%% END WORKAROUND %%%
Note that what makes this one particularly slippery is that the output from
the buggy example (shown in the png attached here) is actually syntactically
wrong: the measure of 2/8 prints with three eighth notes (because the tuplet
bracket goes missing). The rhythmic inaccuracy is easy enough to spot in
this pared-down example; but in a situation of considerably more rhythmic
complexity this can be lethal. (In the realworld score that I am working on
that surfaced the bug it was, in fact, only the very visible absence of an
extended slur that made this one possible to find.)
Trevor.
--
Trevor Bača
trevorb...@gmail.com
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: horizontal alignment of dynamics attached to skips
2009/12/17 Reinhold Kainhofer : > Is there any way to make lilypond use the same horizontal position for s\p and > c\p ??? If you don't care about spanner alignment (i.e., hairpins/dynamic text spans), then it's possible to realign the dynamics by using NoteColumn (you can retrieve DynamicText grobs, then reposition them); otherwise it's waiting for somebody to tackle issue #620. \override NoteColumn #'before-line-breaking = #(lambda (grob) (let* ((paper-col (ly:grob-parent grob X)) (elts (ly:grob-object paper-col 'elements)) (dynamic-text #f)) (for-each (lambda (x) (let ((elt (ly:grob-array-ref elts x))) (if (and (ly:item? elt) (grob::has-interface elt 'dynamic-interface)) (set! dynamic-text elt (iota (ly:grob-array-length elts))) (if dynamic-text (set! (ly:grob-property dynamic-text 'X-offset) (+ (ly:self-alignment-interface::x-aligned-on-self dynamic-text) (interval-center (ly:grob-robust-relative-extent grob grob X))) (NB: this must be inside a \layout block at Voice level, since there are no NoteColumn grobs created within Dynamics.) Regards, Neil ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 492 in lilypond: piano pedal disappears during RehearsalMark
Updates: Status: Started Owner: n.puttock Comment #4 on issue 492 by n.puttock: piano pedal disappears during RehearsalMark http://code.google.com/p/lilypond/issues/detail?id=492 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 936 in lilypond: \tempo makes TextSpanner too long
Updates: Status: Duplicate Mergedinto: 492 Comment #2 on issue 936 by n.puttock: \tempo makes TextSpanner too long http://code.google.com/p/lilypond/issues/detail?id=936 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 492 in lilypond: piano pedal disappears during RehearsalMark
Comment #3 on issue 492 by n.puttock: piano pedal disappears during RehearsalMark http://code.google.com/p/lilypond/issues/detail?id=492 Issue 936 has been merged into this issue. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 946 in lilypond: build tarballs of docs
Status: Accepted Owner: Labels: Type-Other Priority-Postponed New issue 946 by percival.music.ca: build tarballs of docs http://code.google.com/p/lilypond/issues/detail?id=946 We want tarballs (or maybe zip, if windows doesn't support .tar.bz2) of: - all split HTML docs - all big HTML docs - all pdf docs - all all docs they should be linked to in Documentation/web/manuals.itexi @node All. NB: problably not worth doing this until the new build system, but if somebody feels a particular itch, I wouldn't turn away a patch that adds this to the current build system. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 928 in lilypond: `Dynamics' items aren't vertically centered
Updates: Status: Fixed Labels: fixed_2_13_10 Comment #1 on issue 928 by n.puttock: `Dynamics' items aren't vertically centered http://code.google.com/p/lilypond/issues/detail?id=928 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 837 in lilypond: Unnecessary empty dirs in Win32 builds
Comment #6 on issue 837 by pkx1...@hotmail.com: Unnecessary empty dirs in Win32 builds http://code.google.com/p/lilypond/issues/detail?id=837 Yes the control panel uninstall does the same thing - takes a long time You can watch the files vanish one at a time, and I am able to simply 'del' the Lilypond Dir or move it to the trash and delete the files manually in a few seconds. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 837 in lilypond: Unnecessary empty dirs in Win32 builds
Comment #5 on issue 837 by pkx1...@hotmail.com: Unnecessary empty dirs in Win32 builds http://code.google.com/p/lilypond/issues/detail?id=837 originally I was going to report this on 2.13.9 and 2.13.8 (I think), but I see that it does the same thing for me on windows 7 for 2.12.3 when I run the uninstaller app. I'll verify control panel uninstall does the same thing for 2.12.3 also. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 837 in lilypond: Unnecessary empty dirs in Win32 builds
Updates: Status: Accepted Labels: -fixed_2_13_8 Comment #4 on issue 837 by percival.music.ca: Unnecessary empty dirs in Win32 builds http://code.google.com/p/lilypond/issues/detail?id=837 There's a credible report that this is broken in 2.13.9 and 2.12.3. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 945 in lilypond: warning about \version for short snippets
> Currently we show a warning if there's no \version
> statement. This is teh suck for the tutorial -- do we
> explain that people need to write
> \version "2.12.0"
> before they've even learned what
> { c'4 }
> means, or do we let their first view of lilypond be a
> warning?
Neither. Just let them get their feet wet with an
error-free minimal example, even if they don't understand
every token. We want users to *always* put the /version
statement, so let's not start with a poorly-written example.
> I see a few options:
> 1. Suck it up and explain \version as the first thing.
Good. But why even bother with an explanation? LM 1.1.4
"Command-line" has the user entering this without explaining
the curly braces or single-quotes:
{
c' e' g' e'
}
A lot of things are like this when first being learned:
int main()
#!/bin/bash
etc...
> 2. Suck it up and tell newbies to ignore the warning.
> (IMO, that's even worse, since it trains them to
> ignore warnings)
Bad.
> 3. Do something intelligent in lilypond, like only
> warning about \version if the input file is more than
> 10 lines long.
Bad. It only takes one line to write an outdated .ly file.
> I prefer #3, of course.
I prefer adding the \version statement silently. Curious
readers can remove it themselves and watch as the warning
appears. It's explained eventually anyway, isn't it?
- Mark
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 945 in lilypond: warning about \version for short snippets
Comment #1 on issue 945 by lemzwerg: warning about \version for short snippets http://code.google.com/p/lilypond/issues/detail?id=945 I'm not willing to work on it, but I have to make a comment anyway, since it sounds that you want to have a poll... I prefer #1: (a) it's the simplest solution (b) heuristics as in #3 are doomed to fail (c) given that syntax changes are likely to come in lilypond 3, even starters should be trained to use a proper \version statement to make a transition as painless as possible -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 945 in lilypond: warning about \version for short snippets
Status: Accepted
Owner:
Labels: Type-Enhancement Priority-Low
New issue 945 by percival.music.ca: warning about \version for short
snippets
http://code.google.com/p/lilypond/issues/detail?id=945
Don't discuss this issue unless you're seriously willing to work on it --
putting patches, organising discussion on -devel, etc.
Currently we show a warning if there's no \version statement. This is teh
suck for the tutorial -- do we explain that people need to write
\version "2.12.0"
before they've even learned what
{ c'4 }
means, or do we let their first view of lilypond be a warning?
I see a few options:
1. Suck it up and explain \version as the first thing.
2. Suck it up and tell newbies to ignore the warning. (IMO, that's even
worse, since it trains them to ignore warnings)
3. Do something intelligent in lilypond, like only warning about \version
if the input file is more than 10 lines long.
I prefer #3, of course.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 944 in lilypond: settings for less than 1 (full) line
Status: Accepted
Owner:
Labels: Type-Enhancement Priority-Low
New issue 944 by percival.music.ca: settings for less than 1 (full) line
http://code.google.com/p/lilypond/issues/detail?id=944
Don't discuss this issue unless you're seriously willing to work on it --
putting patches, organising discussion on -devel, etc.
We set ragged-right and ragged-last for short snippets (below). We might
also want to:
- set indent=0\mm
- set left-margin=0\mm
Some discussion here:
http://lists.gnu.org/archive/html/lilypond-devel/2009-12/msg00360.html
Info from Sven Axelsson:
Jyst FYI: the code in question is in lily/constrained-breaking.cc
in SHA 6673b8fee.
The patch looks like this:
+ /* As a special case, if there is only one line in the score and
ragged-right
+ hasn't been specifically forbidden and the line is stretched, use
+ ragged spacing. */
+ if (last && i == 0
+ && lines_.at (i, j).force_ >= 0
+ && !scm_is_bool (pscore_->layout ()->c_variable ("ragged-right"))
+ && !scm_is_bool (pscore_->layout ()->c_variable ("ragged-last")))
+ragged = true;
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 932 in lilypond: Vertical spacing: repeat brackets and tablatures exceeding page bottom
Updates: Status: Fixed Labels: fixed_2_13_10 Comment #1 on issue 932 by joeneeman: Vertical spacing: repeat brackets and tablatures exceeding page bottom http://code.google.com/p/lilypond/issues/detail?id=932 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 628 in lilypond: Regression: markup \note doesn't work as a TimeSignature stencil
Updates: Status: Fixed Labels: fixed_2_13_10 Comment #8 on issue 628 by n.puttock: Regression: markup \note doesn't work as a TimeSignature stencil http://code.google.com/p/lilypond/issues/detail?id=628 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 943 in lilypond: A slur should follow the same vertical direction it would have in unbroken state.
Comment #3 on issue 943 by lemzwerg: A slur should follow the same vertical direction it would have in unbroken state. http://code.google.com/p/lilypond/issues/detail?id=943 And please format the example so that its description is in texinfo format -- and it should compile! (Your code above lacks a closing double quote in the \version line.) For an example look at issue #928. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 943 in lilypond: A slur should follow the same vertical direction it would have in unbroken state.
Comment #2 on issue 943 by percival.music.ca: A slur should follow the same vertical direction it would have in unbroken state. http://code.google.com/p/lilypond/issues/detail?id=943 Why should a slur blah blah blah? (hint: specify the filename. That way, we know that you're speaking from authority (well, the authority of whoever added that regtest in the first place)) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 943 in lilypond: A slur should follow the same vertical direction it would have in unbroken state.
Updates: Labels: Type-Defect Comment #1 on issue 943 by jameseli...@googlemail.com: A slur should follow the same vertical direction it would have in unbroken state. http://code.google.com/p/lilypond/issues/detail?id=943 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 943 in lilypond: A slur should follow the same vertical direction it would have in unbroken state.
Status: Accepted
Owner:
Labels: Priority-Regression
New issue 943 by jameseli...@googlemail.com: A slur should follow the same
vertical direction it would have in unbroken state.
http://code.google.com/p/lilypond/issues/detail?id=943
A slur should follow the same vertical direction it would have in unbroken
state. The following proves the opposite.
\version "2.13.9
\paper { ragged-right = ##t }
\relative c''{
e1( \break a,)
\time 2/4
}
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Catching up on bugs
In checking the regressions, I've come across some issues. And, sorry
for posting these all in one go, but I've just been saving them up
until one day I could post a massive email and have the bug tracker
explode with new regression issues.
Regressions:
page-label.ly:
line 35: \mark \markup { A (page \concat { \page-ref #'markA "0"
"?" ) }} \label #'markA
displayed as I would expect it in 2.12.2, 2.13.9 puts the mark too
far to the left.
slur-broken-trend.ly the first example e''1( \break a,) flips the
slur direction; according to the description (and the behavior in
2.12) it shouldn't
Issues:
Is the difference between 2.12 and 2.13.9 on ‘page-spacing-staff-
group.ly’ intentional?
page-turn-page-breaking-badturns.ly it recovers well, but is not
displayed on 3 pages.
page-turn-page-breaking-repeats is the difference intentional?
Personally, I think it's an improvement, but that's just from the
limited example presented here.
page-turn-page-breaking.ly needs to be re-written to show the
functionality.
profile-property-access.ly errors and fails when I try to compile it.
Additionally, the properties shown in the output are all 0
quote-during.ly and quote.ly appear to be fundamentally identical.
Additionally, quote-during references cueDuring in the explanatory
text, although cueDuring isn't used in the example.
ragged-right-compressed.ly compiles correctly, but the display in the
html and pdf documentation is on two lines, but the description (and
the output of compiling the example) are on one line
size11-26.ly is it worth it to include allfontstyle.ily in the
documentation download? I downloaded the documentation, and it isn't
included. Consequently, I couldn't compile any of these examples.
On 12.12.2009, at 06:43, Graham Percival wrote:
With the release of 2.13.9, we now believe that all bugs are
either fixed, or have been added to the issue tracker. If you
have reported a bug and it is not in the tracker, please check the
bug reporting guidelines and re-submit it.
http://lilypond.org/doc/v2.13/Documentation/web/bug-reports
Valentin, James: I think it's time for the annual "checking the
regression tests". Instructions are in the Contributor's Guide
6.4 Checking and verifying issues. I'll let you two decide who
does what. It would be nice if this was done within a week or so;
it's not a huge job.
After that, we'll have 2.13.10, and then you two can start
checking all issues. There will be more specific guidelines about
tagging and priorities. I'm going to collect my thoughts into
specific proposals, and begin discussions later today or tomorrow.
Cheers,
- Graham
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 867 in lilypond: lilypond-book can have hash collisions
Updates: Labels: -Type-Enhancement Type-Other Comment #3 on issue 867 by percival.music.ca: lilypond-book can have hash collisions http://code.google.com/p/lilypond/issues/detail?id=867 On Fri, Dec 18, 2009 at 2:38 AM, Han-Wen adds: We already have a plausible explanation, and a fairly simple solution: use flock() in ly:parse-file on the .ly file. Overwriting files is not actually a problem, since the .ly files will be overwritten by the same content. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 942 in lilypond: out-www/web/ has upper-case and lower-case filenames
Status: Accepted Owner: Labels: Type-Other Priority-Low Maintainability New issue 942 by percival.music.ca: out-www/web/ has upper-case and lower-case filenames http://code.google.com/p/lilypond/issues/detail?id=942 gperc...@gperciva-desktop:~/src/build-lilypond/Documentation$ ls -lh out-www/web/?anuals.* -rw-r--r-- 2 gperciva gperciva 1.6K 2009-12-20 16:35 out-www/web/Manuals.fr.html -rw-r--r-- 1 gperciva gperciva 9.4K 2009-12-20 16:35 out-www/web/manuals.html -rw-r--r-- 1 gperciva gperciva 1.6K 2009-12-20 16:35 out-www/web/Manuals.html -rw-r--r-- 2 gperciva gperciva 6.6K 2009-12-20 16:36 out-www/web/manuals.nl.html The upper-case Manuals.html only has a link to the lower-case manuals.html, so I guess the website still works, but it would be nice if those weren't created. These almost-empty capitalized-filenames don't appear for the other manuals (at least, not learning/ and notation/ ; I didn't check the rest). Since they now use the same init file and the only difference is that web has -D web, it shouldn't be too hard to find out why this happens. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 940 in lilypond: unify announcement methods
Comment #2 on issue 940 by percival.music.ca: unify announcement methods http://code.google.com/p/lilypond/issues/detail?id=940 I'm not logging into any webpage. Does it have a command-line client that can be driven by a python script? If not, then no thanks. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 938 in lilypond: building lilypond omf files: what, why, how, etc
Updates: Labels: -Type-Documentation Type-Other Comment #3 on issue 938 by percival.music.ca: building lilypond omf files: what, why, how, etc http://code.google.com/p/lilypond/issues/detail?id=938 How are they used: I mean, does anybody use them? If I go to a repository of open-source manuals (do those exist?), is lilypond listed? Does redhat use them to help the packaging? in short, would anybody notice if we dropped support for them entirely? are the generated correctly? on my local system, I see: gperciva (None) is that correct? What does it say on the official, distributed, version? Are the omf files actually included in the official, distributed version? If not, then it seems obvious that we can just junk them. Valentin: This isn't an issue that can be solved by editing texinfo, ly, or scm files, so it's not documentation. I'm clarifying this distinction in the new bug classifications. We're not just "documenting it somewhere", because it's not clear what the answer those questions _is_. Look, it's not an urgent issue. It has the lowest possible priority. I don't care if nobody looks at this for another year. But if you *do* look into it, I want everything answered. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 941 in lilypond: Enhancement: merging make-markup-command and make-builtin-markup-command
Updates: Cc: nicolas.sceaux Comment #1 on issue 941 by v.villenave: Enhancement: merging make-markup-command and make-builtin-markup-command http://code.google.com/p/lilypond/issues/detail?id=941 I understand Nicolas is on it (or something like that). -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Enhancement request: make-markup-command cleanup and docs
On Sun, Dec 20, 2009 at 11:01 AM, David Kastrup wrote: > The current state of make-markup-command is less than satisfactory since > make-markup-command and make-builtin-markup-command have different > syntaxes and semantics, making the latter an "insider" command that > complicates the transition from advanced user to Lilypond contributor. Thanks, added as http://code.google.com/p/lilypond/issues/detail?id=941 Cheers, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 941 in lilypond: Enhancement: merging make-markup-command and make-builtin-markup-command
Status: Started Owner: v.villenave Labels: Priority-Medium Type-Enhancement Maintainability Patch New issue 941 by v.villenave: Enhancement: merging make-markup-command and make-builtin-markup-command http://code.google.com/p/lilypond/issues/detail?id=941 New request from David Kastrup: """ make-markup-command and make-builtin-markup-command have different syntaxes and semantics, making the latter an "insider" command that complicates the transition from advanced user to Lilypond contributor. There has been work done on unifying the syntax at http://codereview.appspot.com/160048>. The last changes of those patch sets have eliminated make-builtin-markup-command completely, and one has been adding a command line option that stops indexing for make-builtin-markup-command (and the respective markup list command) completely. The latter will make only sense if the effect of this option is made to extend to further commands not related to markup. " David also mentioned that the Contributor's Guide could be improved in this regard: """ If the decision is "no change at all", the patch set at http://codereview.appspot.com/157133> improves the CG documentation. It also forms an excellent starting point if the decision is to incorporate more of the first-mentioned patch, or otherwise change the commands of make-markup flavor. " -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 940 in lilypond: unify announcement methods
Comment #1 on issue 940 by v.villenave: unify announcement methods http://code.google.com/p/lilypond/issues/detail?id=940 If we want to go social-networking, there are unified platforms for this: http://ping.fm/networks/ -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 938 in lilypond: building lilypond omf files: what, why, how, etc
Updates: Labels: -Type-Other Type-Documentation Comment #2 on issue 938 by v.villenave: building lilypond omf files: what, why, how, etc http://code.google.com/p/lilypond/issues/detail?id=938 Then perhaps we should just document this somewhere? Honestly, I'm not sure this discussion even belongs in the tracker... -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Enhancement request: make-markup-command cleanup and docs
The current state of make-markup-command is less than satisfactory since make-markup-command and make-builtin-markup-command have different syntaxes and semantics, making the latter an "insider" command that complicates the transition from advanced user to Lilypond contributor. There has been work done on unifying the syntax at http://codereview.appspot.com/160048>. The last changes of those patch sets have eliminated make-builtin-markup-command completely, and one has been adding a command line option that stops indexing for make-builtin-markup-command (and the respective markup list command) completely. The latter will make only sense if the effect of this option is made to extend to further commands not related to markup. So there remains a technical decision pending about the accepted scope of the proposed changes (from none at all to the last change set). This decision needs to be done by somebody with commit privileges and the required authority. Once this has been done, the changed (or unchanged) state needs further documentation in the CG (the in-code documentation for all variants appears par for the course to me). If the decision is "no change at all", the patch set at http://codereview.appspot.com/157133> improves the CG documentation. It also forms an excellent starting point if the decision is to incorporate more of the first-mentioned patch, or otherwise change the commands of make-markup flavor. With the mentioned sources of input, the improvement of the contributor's guide would appear to be a task at frog level once a decision about the scope of code changes has been made. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
