Re: other manual style issues
On 14-Sep-04, at 1:52 AM, Mats Bengtsson wrote: When writing scientific papers with math formulas in them, I often use a comma before the formula. If you think of the figure as an inserted clarification in the sentence, it makes sense to use a comma. (Of course, then you would like a comma also after the figure. Again, with math formulas, it's common to end the formula with a comma or a period - something you unfortunately cannot do with the figures.) I agree that we should have a comma (or occasionally a period) before a figure. But the current LilyPond style guidelines call for no punctuation between the text and an example. Would anybody (*cough* Han-Wen *cough* :) object if I changed this guideline to allow for some punctuation? I don't think I'd use a colon; it would be either commas or periods. And in some cases I might not use any punctuation. But in most cases I'd prefer to include a comma. This would be a post-3.0 change, so we don't need to fight about it right now. Cheers, - Graham ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Docs for 3.0
There's two things I need help with, somewhat urgently before 3.0: 1) In the manual, "Controlling formatting of prefatory matter" (currently 5.3.10): there's an example of doing weird stuff with the clef and key signature, and no explanatory text. If it's just an example of doing weird stuff, I can write some text. Although I'm not certain how much it adds to the manual... would anybody mind if we just delete this section? (perhaps sticking the example into the "tricks n' tips" section?) 2) Piano templates. I propose deleting "piano-4-voices.ly". I'm not sure whether to move "piano-lyrics.ly" (lyrics centered between the staffs) into the manual, or not bother saving that one. Opinions? The real problem is "piano-dynamics.ly" (dynamics centered between the two piano staffs). It sounds like a good template to have, but I don't understand the template myself, and there's a bunch of ugly stuff in there (like extra-offset). Could a piano player have a look at this and simplify it? Or make a completely new template that does the same thing? Cheers, - Graham ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: @internalsref{foo}
On 15-Sep-04, at 3:14 PM, Han-Wen Nienhuys wrote:
[EMAIL PROTECTED] writes:
@internalsref{foo} creates "see _foo_".
No, this is unintentional; @internalsref is a macro. We may have to
adjust the macro definition.
After editing another section of the manual, I think that we do indeed
need to adjust this definition. "see _foo_" doesn't work; it's always
used in the context where it should simply be "_foo_".
I looked at documentation/user/macros.itexi , but I couldn't figure
out what to change. Could a texidoc guru adjust this?
Cheers,
- Graham
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
'make all' fails
CVS ChangeLog 1.2624 on 'make all' exits like this: bison -o out/parser.cc parser.yy mv -f parser.yy.tab.c out/parser.cc # bison < 1.30 mv: can't stat source parser.yy.tab.c make[1]: [out/parser.cc] Error 1 (ignored) rm -f ./out/parser.dep; DEPENDENCIES_OUTPUT="./out/parser.dep ./out/parser.o" g++ -c -DHAVE_CONFIG_H -DSTRING_UTILS_INLINED -Iinclude -I./out -I../flower/include -I../flower/./out -I../flower/include -O2 -finline-functions -g -pipe -I/usr/include/python2.2 -O2 -finline-functions -g -pipe -I/usr/include/python2.2 -W -Wall -Wconversion -o out/parser.o out/parser.cc parser.yy: In function `int yyparse(void*)': parser.yy:696: non-lvalue in assignment make[1]: *** [out/parser.o] Error 1 rm out/lexer.cc out/parser.cc make[1]: Leaving directory `/usr/src/lilypond/lily' make: *** [all] Error 2 [EMAIL PROTECTED] lilypond]# -David ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [bug?] Line_interface::line
[EMAIL PROTECTED] writes: > > > On Tue, 21 Sep 2004, Han-Wen Nienhuys wrote: > > > ... > > > Well, ... > > > > > > (1) There is no \unset command for grob properties (at least not that I > > > know of). Hence, I guess by "unset dash-fraction" you mean > > > "\override TextSpanner #'dash-fraction = #'()"? At least, this trick > > > seems to do the job. > > > > > > \revert TextSpanner #'dash-fraction > > > > Ok, that may work too if I can be sure that nobody else has touched this > property before. This hasn't been a problem since 2.1.something. > In this example, property "style" is set to "line", but I still get a > dashed line. That is, the "style" property does not have any effect. To > get a solid line, I have to unset dash-fraction. > > However, if I set "style" to "zigzag", I *do* get a zigzag line, > regardless if I have or have not set dash-fraction. (But in this case the > zigzag line is aligned completely wrong, as I already reported a view days > ago; but that is another bug...) > > That is, setting dash-fraction to some value prevents you from typesetting > solid lines, while dashed lines and zigzag lines still work. This does > not sound very logical, does it? Ok, so the real problem is the zig zag line, which isn't even a line to begin with. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [bug?] Line_interface::line
On Tue, 21 Sep 2004, Han-Wen Nienhuys wrote:
> ...
> > Well, ...
> >
> > (1) There is no \unset command for grob properties (at least not that I
> > know of). Hence, I guess by "unset dash-fraction" you mean
> > "\override TextSpanner #'dash-fraction = #'()"? At least, this trick
> > seems to do the job.
>
>
> \revert TextSpanner #'dash-fraction
>
Ok, that may work too if I can be sure that nobody else has touched this
property before. But I am targeting at the episem code (which should now
more or less work in current CVS). That is, I want to unset it without
knowing its previous value (see the episem stuff in engraver-init.ly and
gregorian-init.ly). Therefore, setting it to #'() seems safer (though
still assuming that the user does not touch it afterwards).
> > (2) I think it is a design flaw that you have to unset the dash-fraction
> > property (which, by default, is set to some value) in order to make
> > the style property work. If this intended, it should at least be
> > clearly documented in the manual that changing the style property of
> > TextSpanner by default has no effect.
>
> I think I don't get the entire picture. Can you post a .ly snippet of
> what you _would_ like to have working?
>
Well, that's basically the snippet that I already sent:
startTextSpanner = #(make-span-event 'TextSpanEvent START)
stopTextSpanner = #(make-span-event 'TextSpanEvent STOP)
\score {
\context Voice \transpose c c' {
f a c' bes a g f g f
\startTextSpanner
g a bes
\stopTextSpanner
a g f f
}
\paper {
\context {
\Voice
\override TextSpanner #'style = #'line
\override TextSpanner #'edge-height = #'(0 . 0)
\override TextSpanner #'padding = #0.5
\override TextSpanner #'enclose-bounds = #1
\override TextSpanner #'edge-text = #'("abc" . "def")
}
}
}
In this example, property "style" is set to "line", but I still get a
dashed line. That is, the "style" property does not have any effect. To
get a solid line, I have to unset dash-fraction.
However, if I set "style" to "zigzag", I *do* get a zigzag line,
regardless if I have or have not set dash-fraction. (But in this case the
zigzag line is aligned completely wrong, as I already reported a view days
ago; but that is another bug...)
That is, setting dash-fraction to some value prevents you from typesetting
solid lines, while dashed lines and zigzag lines still work. This does
not sound very logical, does it?
Greetings,
Jürgen
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [bug?] Line_interface::line
[EMAIL PROTECTED] writes:
>
>
> On Tue, 21 Sep 2004, Han-Wen Nienhuys wrote:
>
> > [EMAIL PROTECTED] writes:
> > >
> > >
> > > On Fri, 17 Sep 2004, Han-Wen Nienhuys wrote:
> > >
> > > > [EMAIL PROTECTED] writes:
> > > > > else
> > > > > {
> > > > > return make_line (thick, from, to);
> > > > > }
> > > > >
> > > > >
> > > > > Are you sure that the "else" branch (i.e. making a solid line) should be
> > > > > regardless of the "style" property entered only if "scm_is_number
> > > > > (dash_fraction)" evaluates to false?
> > > >
> > > > I don't understand. If you want dashed lines, you should set
> > > > dash-fraction.
> > > >
> > >
> > > No, the opposite. I want a solid line, but I always get a dashed line:
> >
> > then unset dash-fraction.
> >
>
> Well, ...
>
> (1) There is no \unset command for grob properties (at least not that I
> know of). Hence, I guess by "unset dash-fraction" you mean
> "\override TextSpanner #'dash-fraction = #'()"? At least, this trick
> seems to do the job.
\revert TextSpanner #'dash-fraction
> (2) I think it is a design flaw that you have to unset the dash-fraction
> property (which, by default, is set to some value) in order to make
> the style property work. If this intended, it should at least be
> clearly documented in the manual that changing the style property of
> TextSpanner by default has no effect.
I think I don't get the entire picture. Can you post a .ly snippet of
what you _would_ like to have working?
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[bug] final \mark does not show up
Hi!
In section 5.3.8 of the manual ("Bar lines"), the last \mark in the second
figure (lily-1457749936.ly) does not show up: there should be a ":"
printed above the rightmost dotted bar line.
Greetings,
Jürgen
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [bug?] Line_interface::line
On Tue, 21 Sep 2004, Han-Wen Nienhuys wrote:
> [EMAIL PROTECTED] writes:
> >
> >
> > On Fri, 17 Sep 2004, Han-Wen Nienhuys wrote:
> >
> > > [EMAIL PROTECTED] writes:
> > > > else
> > > > {
> > > > return make_line (thick, from, to);
> > > > }
> > > >
> > > >
> > > > Are you sure that the "else" branch (i.e. making a solid line) should be
> > > > regardless of the "style" property entered only if "scm_is_number
> > > > (dash_fraction)" evaluates to false?
> > >
> > > I don't understand. If you want dashed lines, you should set
> > > dash-fraction.
> > >
> >
> > No, the opposite. I want a solid line, but I always get a dashed line:
>
> then unset dash-fraction.
>
Well, ...
(1) There is no \unset command for grob properties (at least not that I
know of). Hence, I guess by "unset dash-fraction" you mean
"\override TextSpanner #'dash-fraction = #'()"? At least, this trick
seems to do the job.
(2) I think it is a design flaw that you have to unset the dash-fraction
property (which, by default, is set to some value) in order to make
the style property work. If this intended, it should at least be
clearly documented in the manual that changing the style property of
TextSpanner by default has no effect.
> > The above code produces a dashed line instead of a solid one. Actually,
> > it seems there are at least two bugs, because even if I change
> > Line_interface::line () such that the else branch is entered for solid
> > lines (by removing the "scm_is_number (dash_fraction)" clause in the if
> > condition), I still get a dashed line.
>
> hmm. interesting. can you add a .ly snippet to the bug database?
>
It just turned out that the .pdf output on my machine was created from an
outdated .ps file, such that I got a wrong .pdf output. Unsetting
dash-fraction seems to be sufficient.
Greetings,
Jürgen
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[bug] Docu: bad code snippet
Section 7.1.5 ("Changing context default settings") contains twice the
line:
\override Stem #'thickness
I guess, this should be
\override Stem #'thickness = #2.0
or something alike, right?
Greetings,
Jürgen
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [bug?] Line_interface::line
[EMAIL PROTECTED] writes:
>
>
> On Fri, 17 Sep 2004, Han-Wen Nienhuys wrote:
>
> > [EMAIL PROTECTED] writes:
> > > else
> > > {
> > > return make_line (thick, from, to);
> > > }
> > >
> > >
> > > Are you sure that the "else" branch (i.e. making a solid line) should be
> > > regardless of the "style" property entered only if "scm_is_number
> > > (dash_fraction)" evaluates to false?
> >
> > I don't understand. If you want dashed lines, you should set
> > dash-fraction.
> >
>
> No, the opposite. I want a solid line, but I always get a dashed line:
then unset dash-fraction.
> The above code produces a dashed line instead of a solid one. Actually,
> it seems there are at least two bugs, because even if I change
> Line_interface::line () such that the else branch is entered for solid
> lines (by removing the "scm_is_number (dash_fraction)" clause in the if
> condition), I still get a dashed line.
hmm. interesting. can you add a .ly snippet to the bug database?
> BTW, why is make_line (...)
> defined in Line_interface rather than in Lookup?
because I don't want to copy all the properties over all the grobs
using it.
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [bug?] Line_interface::line
On Fri, 17 Sep 2004, Han-Wen Nienhuys wrote:
> [EMAIL PROTECTED] writes:
> > else
> > {
> > return make_line (thick, from, to);
> > }
> >
> >
> > Are you sure that the "else" branch (i.e. making a solid line) should be
> > regardless of the "style" property entered only if "scm_is_number
> > (dash_fraction)" evaluates to false?
>
> I don't understand. If you want dashed lines, you should set
> dash-fraction.
>
No, the opposite. I want a solid line, but I always get a dashed line:
startTextSpanner = #(make-span-event 'TextSpanEvent START)
stopTextSpanner = #(make-span-event 'TextSpanEvent STOP)
\score {
\context Voice \transpose c c' {
f a c' bes a g f g f
\startTextSpanner
g a bes
\stopTextSpanner
a g f f
}
\paper {
\context {
\Voice
\override TextSpanner #'style = #'line
\override TextSpanner #'edge-height = #'(0 . 0)
\override TextSpanner #'padding = #0.5
\override TextSpanner #'enclose-bounds = #1
\override TextSpanner #'edge-text = #'("abc" . "def")
}
}
}
The above code produces a dashed line instead of a solid one. Actually,
it seems there are at least two bugs, because even if I change
Line_interface::line () such that the else branch is entered for solid
lines (by removing the "scm_is_number (dash_fraction)" clause in the if
condition), I still get a dashed line. BTW, why is make_line (...)
defined in Line_interface rather than in Lookup?
This bug is relevant for me, because it breaks the episem feature of
ancient notation.
Greetings,
Jürgen
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
