Re: tabs vs. spaces in source code

[Ian Hulin]

Hi Graham,

Graham Percival wrote:

On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote:

Thanks, Neil. My editor does confusing things with tabs.
I hate them. Who would object if I just started running
tabs->spaces on the source docs? I think we should have
a strict no-tabs rule. And I'm in good company:
http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00103.html


If the programmers, particularly Han-Wen (who appears to already
agree with this) decide to make it a standard, fine.  This should
also be mentioned in the CG, just like all the doc policy items.
If it _is_ mentioned in the CG, please put a mention about editing .make 
files; tabs _are_ significant here and required when you are defining rules.


Cheers,
Ian






___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

feature request (\cueNotes)

[Werner]

I really would be glad, if there was a possibility to make notes (including
heads, stems, beams, flags, slurs, clefs, accidentals, ...) smaller.

Unfortunately the \small, \tiny, \set fontSize commands don't affect all parts
of notes (beams, ... are not affected).

Something like
\cueNotes or just \cue with 


<< { a4 a a' a, }\\{ \cue { s4 s a s } } >>

or

<< { \ cue { es2~ es8 f 
% the following d4 could also be s4
d4 } } \\ { g8 a16 b c4. d8 d4 } >>


would be nice.
Or something like


\relative c
{ a4 b a b
\cueDuring { a a a a, } #UP { a' a a a } 
a1
}


instead of the complicated


\relative c
{ a4 b a b
\cueDuring #"StichnotenEins" #UP { a' a a a } 
a1
}
StichnotenEins = \relative c { a a a a, }
\addQuote "StichnotenEins" { \StichnotenEins }


Anybody, who could provide this? (I could pay something for that.)

Btw. - the first solution, a \cue command, which makes following musicexpression
smaller (notes, heads, flags AND beams, stems, accidentals, (clefs), ...) would
be much better than the second.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: RFC: new vertical layout engine

[Kieren MacMillan]

Hi Werner (et al,),

Please use two spaces after a full stop in documentation strings  
for consistence.


Since this is incorrect typographical practice, and Lilypond prides  
itself on beautiful typography, I'm surprised this is the standard in  
the docs — why/how was this decision made?


Cheers,
Kieren.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: tabs vs. spaces in source code

[Werner LEMBERG]

>> Thanks, Neil. My editor does confusing things with tabs.

Then use a different editor.

>> I hate them.

I dislike them, too, but there are many editors which handle them just
fine.  I don't see a problem here.


Werner


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: RFC: new vertical layout engine

[Werner LEMBERG]

>> Please use two spaces after a full stop in documentation strings for
>> consistence.
> 
> Since this is incorrect typographical practice,

It really depends.  IIRC, the Chicaco manual of style recommended
this.

> and Lilypond prides itself on beautiful typography, I'm surprised
> this is the standard in the docs — why/how was this decision made?

There are two reasons.

  1) Editors like Emacs benefit from having two spaces after a full
 stop so they can recognize the end of a sentence properly -- in
 contrast to an abbreviation which is followed by a single space
 only.

  2) The `info' program needs two spaces a full stop for similar
 reasons.

Note that documentation in either HTML or PDF format created with
texinfo doesn't show those two spaces.  It's just a means to better
organize the source code and not related to the output.


Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: RFC: new vertical layout engine

[Kieren MacMillan]

Hi Werner,


It really depends. IIRC, the Chicaco manual of style recommended this.


"The view at CMOS is that there is no reason for two spaces after a  
period in published work."



Also see page 28 of Robert Bringhurst's "The Elements of  
Typographical Style" (*the* authoritative reference):
"As a general rule, no more than a single space is required after a  
period, a colon or any other mark of punctuation."


In other words, it doesn't depend: no serious style manual or guide  
recommends more than one space after a period (with rare exceptions  
like setting romanized Sanskrit, phonetics, etc.).



  1) Editors like Emacs benefit from having two spaces after a full
 stop so they can recognize the end of a sentence properly -- in
 contrast to an abbreviation which is followed by a single space
 only.

  2) The `info' program needs two spaces a full stop for similar
 reasons.

Note that documentation in either HTML or PDF format created with
texinfo doesn't show those two spaces.  It's just a means to better
organize the source code and not related to the output.


I would imagine HTML would "do the right thing" (since the spaces  
are, I assume, not coded as   in the source).


However, the PDF (e.g., the NR) *appears* to preserve double-space  
sentence separations — where (e.g., some specification/documentation)  
can I confirm that the process which generates the PDF version of the  
docs turns double-spaced source into single-space output?


Cheers,
Kieren.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: RFC: new vertical layout engine

[Werner LEMBERG]

> "The view at CMOS is that there is no reason for two spaces after a
> period in published work."

Ok, whatever :-) Look up references to TeX and LaTeX for more on this
topic.

> However, the PDF (e.g., the NR) *appears* to preserve double-space
> sentence separations — where (e.g., some
> specification/documentation) can I confirm that the process which
> generates the PDF version of the docs turns double-spaced source
> into single-space output?

For TeX, it is completely irrelevant whether there are one, two, or
more spaces between words (and after full stops).  However, there are
special cases for American typography.  To cite the texinfo info
pages:

  In American typography, it is traditional and correct to put extra
  space at the end of a sentence, after a semi-colon, and so on.  This
  is the default in Texinfo.  In French typography (and many others),
  this extra space is wrong; all spaces are uniform.

  Therefore Texinfo provides the `...@frenchspacing' command to control
  the spacing after punctuation.  It reads the rest of the line as its
  argument, which must be the single word `on' or `off' (always these
  words, regardless of the language) of the document.  [...]

Indeed, I just see that @frenchspacing is only used for French and
Japanese (the latter only partially).  It should be activated for all
languages except, perhaps, English.  Note that I don't care what you
native speakers actually decide for English :-)


Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: tabs vs. spaces in source code

[Carl Sorensen]

On 7/24/09 11:32 PM, "Mark Polesky"  wrote:

> 
> 
> Graham Percival wrote:
> 
>> On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote:
>>> Thanks, Neil. My editor does confusing things with tabs.
>>> I hate them. Who would object if I just started running
>>> tabs->spaces on the source docs? I think we should have
>>> a strict no-tabs rule. And I'm in good company:
>>> http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00103.html
>> 
>> If the programmers, particularly Han-Wen (who appears to already
>> agree with this) decide to make it a standard, fine.  This should
>> also be mentioned in the CG, just like all the doc policy items.
> 
> Han-Wen,
> 
> do you want to make it official?
> 
> - Mark
> 
> 

The last communication we had about it, Han-Wen was conditionally in favor
and Jan was opposed.

However, there was no *requirement* for tabs, so if you want to use all
spaces (as I do), you can feel free to do so.

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: tabs vs. spaces in source code

[Mark Polesky]

...tabs in the source code...

Werner Lemberg wrote:
> I dislike them, too, but there are many editors which handle
> them just fine.  I don't see a problem here.

But would you be *opposed* to a strict no-tab rule?

Carl Sorensen wrote:
> The last communication we had about it, Han-Wen was
> conditionally in favor and Jan was opposed.

Are you sure? What do mean by "conditionally"?
http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00103.html

And it looks like Jan was also okay with it:
http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00104.html

If there is anyone opposed to a strict no-tab rule, please speak
up! If I get the official go-ahead from (both? either?) Han-Wen
and Jan, I think I'll start working on it.

Does anyone have a script to automate such a process across
multiple files? I'm not too clever with such things (I don't know
python either). The best I can do is this (using jEdit):

1) save a "tabs2spaces" macro:
   textArea.selectAll();
   textArea.tabsToSpaces();

2) bind it to a keyboard shortcut (-1 is available)

3) open file; -1; close file; repeat.

There are 78 files in the scm folder, it wouldn't take that long
at all. But probably one of you knows a better way (batch-style).

Let me know. I don't want to waste time if I don't have to.

Also, can we list all of the possible situations where we need to
retain tabs? Ian mentioned .make files; the last time this came up
Patrick McCarty mentioned something about demarcating syllables in
lyrics, which I don't think I understand. (Patrick, can you give
an example?)
http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00080.html

Are there any other tabs that need to stay?

I'm looking at this:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=Documentation/user/notation-appendices.itely#l500

But even in such cases, as long as my tab-width matches the
tab-widths in the source, tabs2spaces should be fine. Is it
correct to say that git (or savannah) translates all tabs to 8
spaces without exception?

By the way, I'm intending to re-write the above-referenced
notation-appendices node anyway; it was just an example.

Thanks!
- Mark


  


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: percussion and midi

[Alan Szlosek]

Marc,

Thanks a million for pointing me at the articulation and MIDI discussion. I
now have a pretty good idea of where to go from here, and I'm almost done
with the first item on my todo list.

Thanks again.

On Tue, Jul 14, 2009 at 2:23 AM, Marc Hohl  wrote:

> Hello Alan,
>
> Alan Szlosek schrieb:
>
>> Greetings, current Lilypond developers. I'm new here and would like some
>> guidance.
>>
>> I'm interested in using Lilypond to compose music for high school
>> drumlines. Hopefully my contributions will be useful to others. I'm not new
>> to programming (Computer Science major), but am new to the C++ & Scheme
>> setup in use here. My first task is to make accent marks translate into a
>> dynamic step up in the MIDI output.
>>
>> I would assume that I need to do some work at the iteration stage, as well
>> as the MIDI translation stage. Does an "\accent" get turned into an
>> articulation somehow by ly/script-init.ly ? I'm
>> probably wrong ...
>>
>> I imagine I'll also have to do a check for whether we're dealing with
>> drummode, and conditionally modify some node with extra dynamic information.
>>
>> Can anyone point me in a more clear direction? Thanks.
>>
> I don't know much about MIDI in lilypond, but there has been some
> discussion about articulation
> and MIDI on the lilypond-user mailing list, perhaps the following link
> might help you?
>
> http://lists.gnu.org/archive/html/lilypond-user/2009-06/msg00029.html
>
> Marc
>
>>
>> --
>> Alan Szlosek :: http://www.greaterscope.net
>> 
>>
>> ___
>> lilypond-devel mailing list
>> lilypond-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>>
>>
>
>


-- 
Alan Szlosek :: http://www.greaterscope.net
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: tabs vs. spaces in source code

[Joe Neeman]

On Sat, 2009-07-25 at 09:58 -0700, Mark Polesky wrote:
> ...tabs in the source code...
> 
> Werner Lemberg wrote:
> > I dislike them, too, but there are many editors which handle
> > them just fine.  I don't see a problem here.
> 
> But would you be *opposed* to a strict no-tab rule?

I like spaces just fine, but I'd prefer it if you could hold off on this
for a little while. I have a big patch that I'd like to merge and I'm
not so keen on resolving a bunch of whitespace conflicts...

Joe




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: ppppp but no fffff

[Jonathan Wilkes]

I don't know if this needs an additional command, but in Tchaikovsky's 6th 
symphony there is a "pp" (6 p's) during the clarinet solo at the end 
of the exposition.

What's funny is that he only uses "ff" at the beginning of the next 
section, which is one of the loudest orchestral moments I know.

-Jonathan

Mark Polesky wrote Saturday, July 25, 2009 4:29 AM


> We all okay with this patch?

LGTM

> Of course it's a new command and a syntax change; I don't know if
> that means some special process has to be taken; updating the
> parser, etc. I have no idea, actually. Let me know.

Nothing else is needed, AFAIK.

Trevor




  


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: tabs vs. spaces in source code

[Mark Polesky]

Joe Neeman wrote:
> I like spaces just fine, but I'd prefer it if you could hold off
> on this for a little while. I have a big patch that I'd like to
> merge and I'm not so keen on resolving a bunch of whitespace
> conflicts...

Okay, I'll make a note: I'll wait for Han-Wen, Jan, and Joe.

Thanks.
- Mark


  


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: tabs vs. spaces in source code

[Carl Sorensen]

On 7/25/09 10:58 AM, "Mark Polesky"  wrote:

> 
> 
> ...tabs in the source code...
> 
> Werner Lemberg wrote:
>> I dislike them, too, but there are many editors which handle
>> them just fine.  I don't see a problem here.
> 
> But would you be *opposed* to a strict no-tab rule?
> 
> Carl Sorensen wrote:
>> The last communication we had about it, Han-Wen was
>> conditionally in favor and Jan was opposed.
> 
> Are you sure? What do mean by "conditionally"?
> http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00103.html
> 
> And it looks like Jan was also okay with it:
> http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00104.html

No, Jan was not in favor of it unless it became a standard for GNU coding.
Hence the comment on "first making it a standard" (i.e., a GNU standard)
and "sending a patch to emacs-devel".

The current standard is to let tabs and spaces be handled as emacs handles
them.

> 
> Does anyone have a script to automate such a process across
> multiple files? I'm not too clever with such things (I don't know
> python either). The best I can do is this (using jEdit):
> 
> 1) save a "tabs2spaces" macro:
>textArea.selectAll();
>textArea.tabsToSpaces();
> 
> 2) bind it to a keyboard shortcut (-1 is available)
> 
> 3) open file; -1; close file; repeat.

vim has settings that will convert tabs to spaces; all one would need to do
would be to open the file and save it; vim would take care of the conversion
automatically.


> 
> There are 78 files in the scm folder, it wouldn't take that long
> at all. But probably one of you knows a better way (batch-style).
> 
> Let me know. I don't want to waste time if I don't have to.
> 
> Also, can we list all of the possible situations where we need to
> retain tabs? Ian mentioned .make files; the last time this came up
> Patrick McCarty mentioned something about demarcating syllables in
> lyrics, which I don't think I understand. (Patrick, can you give
> an example?)
> http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00080.html
> 
> Are there any other tabs that need to stay?
> 
> I'm looking at this:
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=Documentation/user
> /notation-appendices.itely#l500
> 
> But even in such cases, as long as my tab-width matches the
> tab-widths in the source, tabs2spaces should be fine. Is it
> correct to say that git (or savannah) translates all tabs to 8
> spaces without exception?

No, this is not correct.  tabs go to the nearest 8-space column.

So if you type two spaces followed by a tab, you'll be in column 8, not in
column 10.

Thanks,

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: RFC: new vertical layout engine

[Kieren MacMillan]

Hi Werner,


To cite the texinfo info pages:


Thanks for the reference — for subsequent thread-followers, I also  
recommend




Indeed, I just see that @frenchspacing is only used for French and
Japanese (the latter only partially).  It should be activated for all
languages except, perhaps, English.  Note that I don't care what you
native speakers actually decide for English


Excellent!
Then I nominate @frenchspacing (i.e., single-spaced sentences) be  
used for the English docs, consistent with the overwhelming majority  
of modern English typographic style guides and practice...

Seconder? Opposed? Abstentions?

Cheers,
Kieren.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: ppppp but no fffff

[Mark Polesky]

Jonathan Wilkes wrote:
> I don't know if this needs an additional command, but in
> Tchaikovsky's 6th symphony there is a "pp" (6 p's) during
> the clarinet solo at the end of the exposition.

Yes, and I mentioned the  on the last page of book 2 of
the Ligeti etudes. Graham proposed a 5-letter limit, and the rest
of us were all okay with that.
http://lists.gnu.org/archive/html/lilypond-devel/2009-06/msg00417.html

Although, it just struck me, what does MIDI do when it gets a
dynamic it doesn't recognize? Maybe it's written somewhere; I
haven't checked.

> LGTM

Thanks.
- Mark


  


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: tabs vs. spaces in source code

[Patrick McCarty]

On Sat, Jul 25, 2009 at 09:58:26AM -0700, Mark Polesky wrote:
> 
> Also, can we list all of the possible situations where we need to
> retain tabs? Ian mentioned .make files; the last time this came up
> Patrick McCarty mentioned something about demarcating syllables in
> lyrics, which I don't think I understand. (Patrick, can you give
> an example?)
> http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00080.html

This is actually an email from Dana Emery in response to me.

I don't think the lyric issue is relevant though, because IIRC
LilyPond treats a tab between two syllables as a single space.

> But even in such cases, as long as my tab-width matches the
> tab-widths in the source, tabs2spaces should be fine. Is it
> correct to say that git (or savannah) translates all tabs to 8
> spaces without exception?

The commitdiffs are sometimes off (I don't know why), but the "raw"
sources and "blobs" always show tabs converted into 8 spaces.

One thing you could do right now, without awaiting approval, is to
check for lines that have tabs *after* spaces at the beginning.  These
should be converted to tabs *followed* by spaces.

-Patrick


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: RFC: new vertical layout engine

[Patrick McCarty]

On Sat, Jul 25, 2009 at 01:30:45PM -0400, Kieren MacMillan wrote:
>
> Excellent!
> Then I nominate @frenchspacing (i.e., single-spaced sentences) be used 
> for the English docs, consistent with the overwhelming majority of modern 
> English typographic style guides and practice...
> Seconder? Opposed? Abstentions?

Don't we want to be following the GNU Coding Standards?  They
explicitly suggest using two spaces after a full stop.

http://www.gnu.org/prep/standards/html_node/Comments.html#Comments

-Patrick


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: tabs vs. spaces in source code

[Mark Polesky]

Carl Sorensen wrote:
> No, Jan was not in favor of it unless it became a standard for
> GNU coding. Hence the comment on "first making it a standard"
> (i.e., a GNU standard) and "sending a patch to emacs-devel".
>
> The current standard is to let tabs and spaces be handled as
> emacs handles them.

Oh, is that something that could ever happen, realistically?

> vim has settings that will convert tabs to spaces; all one would
> need to do would be to open the file and save it; vim would take
> care of the conversion automatically.
>
> ...
>
> > But even in such cases, as long as my tab-width matches the
> > tab-widths in the source, tabs2spaces should be fine. Is it
> > correct to say that git (or savannah) translates all tabs to 8
> > spaces without exception?
>
> No, this is not correct.  tabs go to the nearest 8-space column.
>
> So if you type two spaces followed by a tab, you'll be in column
> 8, not in column 10.

Ha! That's what I meant. Just as easily the jEdit macro could do
it. And I could call removeTrailingWhiteSpace() while I'm at it:

  textArea.selectAll();
  textArea.removeTrailingWhiteSpace();
  textArea.tabsToSpaces();
  buffer.save(view,null,true);
  jEdit.closeBuffer(editPane,buffer);

Patrick McCarty wrote:
> One thing you could do right now, without awaiting approval, is
> to check for lines that have tabs *after* spaces at the
> beginning.  These should be converted to tabs *followed* by
> spaces.

Well, that was exactly what my editor was doing wrong, but I'd
rather wait for consensus on the tabs->spaces than waste time
doing something that I might just change later anyway.

- Mark


  


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: tabs vs. spaces in source code

[Hans Aberg]

On 25 Jul 2009, at 19:39, Patrick McCarty wrote:


One thing you could do right now, without awaiting approval, is to
check for lines that have tabs *after* spaces at the beginning.  These
should be converted to tabs *followed* by spaces.


This is not correct, as if tabs are set to 8 spaces, 2 spaces followed  
by a tab is position 8, whereas a tab followed by two spaces is  
position 10. Unless you meant that in such cases, the unneeded spaces  
should be removed.


You may have to de-tab as you have time to check that the result looks  
good in an editor.


  Hans




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: RFC: new vertical layout engine

[Mark Polesky]

Kieren MacMillan wrote:
> Excellent!
> Then I nominate @frenchspacing (i.e., single-spaced sentences)
> be used for the English docs, consistent with the overwhelming
> majority of modern English typographic style guides and
> practice... Seconder? Opposed? Abstentions?

Seconder.
http://www.chicagomanualofstyle.org/CMS_FAQ/OneSpaceorTwo/OneSpaceorTwo_questions01.html

Patrick McCarty wrote:
> Don't we want to be following the GNU Coding Standards?  They
> explicitly suggest using two spaces after a full stop.

The GNU Coding Standards specify two spaces after the end of
sentences in *comments* only. See paragraph 6:
http://www.gnu.org/prep/standards/html_node/Comments.html#Comments

- Mark


  


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

markup?/markup-list? -> ly:markup?/ly:markup-list?

[Mark Polesky]

I used to make the mistake of typing ly:markup? when using
define-markup-command. Then I would scratch my head when I got

Unbound variable: ly:markup?

I would run over to IR 4, and think, it's not here, where did it
go?

So, is there any reason that it's "markup?" and not "ly:markup?".
Ditto with "markup-list?".

Thanks.
- Mark


  


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: tabs vs. spaces in source code

[Carl Sorensen]

On 7/25/09 11:47 AM, "Mark Polesky"  wrote:

> 
> 
> Carl Sorensen wrote:
>> No, Jan was not in favor of it unless it became a standard for
>> GNU coding. Hence the comment on "first making it a standard"
>> (i.e., a GNU standard) and "sending a patch to emacs-devel".
>> 
>> The current standard is to let tabs and spaces be handled as
>> emacs handles them.
> 
> Oh, is that something that could ever happen, realistically?

In the GNU world, yes.  emacs is the GNU standard programming editor.

In *my* real world, I use only spaces in my documents.  It's not a
standard, but it doesn't break the standard, either.

emacs vs. other editors (mostly vim in the Linux world) is a topic that
tends to start flame wars, so I generally stay away from this topic.
After erroneously stating that we shouldn't have tabs in source files,
I decided to just set my editor so it would work OK, and that's the
way I've resolved it.

Thanks,

Carl





___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: RFC: new vertical layout engine

[Anthony W. Youngman]

In message <20090725.163011.184567355...@gnu.org>, Werner LEMBERG 
 writes

Indeed, I just see that @frenchspacing is only used for French and
Japanese (the latter only partially).  It should be activated for all
languages except, perhaps, English.  Note that I don't care what you
native speakers actually decide for English :-)


As a native English speaker (that's English, not American), I'd say that 
two spaces are wrong, too.


(That said, I know the docs use American, not English, as their main 
language :-)


Cheers,
Wol
--
Anthony W. Youngman - anth...@thewolery.demon.co.uk



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: markup?/markup-list? -> ly:markup?/ly:markup-list?

[Nicolas Sceaux]

Le 25 juil. 09 à 20:19, Mark Polesky a écrit :


So, is there any reason that it's "markup?" and not "ly:markup?".
Ditto with "markup-list?".


The ly: prefix was supposed to be used for functions defined in
the C++ part, which markup? and markup-list? are not.

Nicolas



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: RFC: new vertical layout engine

[Patrick McCarty]

On Sat, Jul 25, 2009 at 11:01:44AM -0700, Mark Polesky wrote:
> 
> Kieren MacMillan wrote:
> > Excellent!
> > Then I nominate @frenchspacing (i.e., single-spaced sentences)
> > be used for the English docs, consistent with the overwhelming
> > majority of modern English typographic style guides and
> > practice... Seconder? Opposed? Abstentions?
> 
> Seconder.
> http://www.chicagomanualofstyle.org/CMS_FAQ/OneSpaceorTwo/OneSpaceorTwo_questions01.html
> 
> Patrick McCarty wrote:
> > Don't we want to be following the GNU Coding Standards?  They
> > explicitly suggest using two spaces after a full stop.
> 
> The GNU Coding Standards specify two spaces after the end of
> sentences in *comments* only. See paragraph 6:
> http://www.gnu.org/prep/standards/html_node/Comments.html#Comments

Ak, okay.  And the standards are silent about this issue when it comes
to documentation.

I'm not really for or against it then.  :-)  I will adjust if need be.

Thanks,
Patrick


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: RFC: new vertical layout engine

[Carl Sorensen]

On 7/25/09 12:01 PM, "Mark Polesky"  wrote:

> 
> 
> Kieren MacMillan wrote:
>> Excellent!
>> Then I nominate @frenchspacing (i.e., single-spaced sentences)
>> be used for the English docs, consistent with the overwhelming
>> majority of modern English typographic style guides and
>> practice... Seconder? Opposed? Abstentions?
> 
> Seconder.
> http://www.chicagomanualofstyle.org/CMS_FAQ/OneSpaceorTwo/OneSpaceorTwo_questi
> ons01.html
> 
> Patrick McCarty wrote:
>> Don't we want to be following the GNU Coding Standards?  They
>> explicitly suggest using two spaces after a full stop.
> 
> The GNU Coding Standards specify two spaces after the end of
> sentences in *comments* only. See paragraph 6:
> http://www.gnu.org/prep/standards/html_node/Comments.html#Comments
> 
> - Mark

Two spaces after a full stop allows the emacs sentence detection code to
work properly.

@frenchspacing eliminates the extra space after the full stop at the end of
the sentence.

Aren't we glad we use typesetting software instead of WYSIWYG word
processors?  We can separate content from presentation.  Two spaces to make
emacs work, @frenchspacing to make the docs work.

Let's keep the two space rule for our documentation!

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: RFC: new vertical layout engine

[Mark Polesky]

Carl Sorensen wrote:

> Two spaces after a full stop allows the emacs sentence detection code to
> work properly.
> 
> @frenchspacing eliminates the extra space after the full stop at the end of
> the sentence.
> 
> Aren't we glad we use typesetting software instead of WYSIWYG word
> processors?  We can separate content from presentation.  Two spaces to make
> emacs work, @frenchspacing to make the docs work.
> 
> Let's keep the two space rule for our documentation!

I understand it now. I'm with Carl.
- Mark



  


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: RFC: new vertical layout engine

[Kieren MacMillan]

Hi Carl (et al.),

Two spaces after a full stop allows the emacs sentence detection  
code to work properly.
@frenchspacing eliminates the extra space after the full stop at  
the end of the sentence.


Then it's settled — excellent!

Thanks,
Kieren.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

how to view console on Windows?

[Mark Polesky]

This was never resolved:
http://lists.gnu.org/archive/html/lilypond-devel/2009-06/msg00434.html

I'm on Windows, and I can see the console with the help of 
LilyPondTool. But how do I view console output without a gui?
It's not in the log file.

Anyone?

- Mark



  


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Feature request: 'line' articulation

[Valentin Villenave]

2009/7/24 Werner LEMBERG :
> I don't object to add it to the font, so please add it as a feature
> request.

Here goes: http://code.google.com/p/lilypond/issues/detail?id=822

Regards,
Valentin


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Docs and new web site reorganization steps

[John Mandereau]

Le mercredi 22 juillet 2009 à 10:30 +0200, John Mandereau a écrit :
> Step 1) Move all Texinfo documentation in user/ and topdocs/ one
> directory higher (done in my working tree), in translations too.
> 
> Step 2) Update all build and maintenance scripts and the CG.
> At the end of this step docs should be in a releasable state again.
> 
> Step 3) Move Snippets and split out the essay (including CG updates).

I actually just pushed Step 1) and parts of 2) and 3) (updating build
scripts so that the docs build :o), updating makelsr.py and moving
snippets). I strive to update the CG and maintenance scripts and push
this on Monday; now I know I've been awarded a PhD grant at math
department of Pisa University (Italy), I'm going to spend for LilyPond
the time I may probably no longer have for three years, not counting the
delay of all what I have already promised to do for months :-P

Best,
John


signature.asc
Description: Ceci est une partie de message numériquement signée
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] IR 3 Backend: More auto-sorting.

[Valentin Villenave]

2009/7/25 Mark Polesky :
> Thanks, Neil. My editor does confusing things with tabs.
> I hate them. Who would object if I just started running
> tabs->spaces on the source docs? I think we should have
> a strict no-tabs rule. And I'm in good company:
> http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00103.html

I think this is also covered by
http://code.google.com/p/lilypond/issues/detail?id=746

Maybe you could start converting tabs to spaces progressively on a
separate branch, to make sure nothing gets broken in the process?

Regards,
Valentin


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: how to view console on Windows?

[Jonathan Kulp]

You can run it from the dos cmd prompt.  Just do "lilypond foobar.ly" and it
should work.

Jon

On Sat, Jul 25, 2009 at 2:02 PM, Mark Polesky  wrote:

>
> This was never resolved:
> http://lists.gnu.org/archive/html/lilypond-devel/2009-06/msg00434.html
>
> I'm on Windows, and I can see the console with the help of
> LilyPondTool. But how do I view console output without a gui?
> It's not in the log file.
>
> Anyone?
>
> - Mark
>
>
>
>
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>



-- 
Jonathan Kulp
http://www.jonathankulp.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: ppppp but no fffff

[Jonathan Wilkes]

> http://lists.gnu.org/archive/html/lilypond-devel/2009-06/msg00417.html

Oh, I haven't played around with make-dynamic-script yet.  I guess it's not 
necessary to have a pre-defined command for "pp" and the like, 
since it's so easy to add these extreme dynamics as needed.  Thanks for 
the link.

> 
> Although, it just struck me, what does MIDI do when it gets
> a
> dynamic it doesn't recognize? Maybe it's written somewhere;
> I
> haven't checked.

There's something in NR 3.5.5 that describes how to control MIDI behavior
for (custom) dynamics.  But if I just use make-dynamic-script to print out 
"ff" or "z" in the score, and I don't use any other dynamics, 
it gets softer when the custom dynamic is used in the MIDI file.

-Jonathan

> 
> > LGTM
> 
> Thanks.
> - Mark
> 
> 
>       
> 





___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: how to view console on Windows?

[Mark Polesky]

Jonathan Kulp wrote:
>>You can run it from the dos cmd prompt.  Just do "lilypond
>>foobar.ly" and it should work.

Yes it does... thank you, that helps. But shouldn't the output
be sent to the log file? I wish it were. Does anyone know how
to do that?

Thanks.
- Mark



  


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: RFC: new vertical layout engine

[Werner LEMBERG]

>> Indeed, I just see that @frenchspacing is only used for French and
>> Japanese (the latter only partially).  It should be activated for all
>> languages except, perhaps, English.  Note that I don't care what you
>> native speakers actually decide for English
> 
> Excellent!  Then I nominate @frenchspacing (i.e., single-spaced
> sentences) be used for the English docs, consistent with the
> overwhelming majority of modern English typographic style guides and
> practice...  Seconder? Opposed? Abstentions?

A minor note: @frenchspacing is actually set for German et al. via the
@documentlanguage command -- I forgot about that.  No need to set
@frenchspacing directly.


Werner


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: RFC: new vertical layout engine

[Werner LEMBERG]

>> Then I nominate @frenchspacing (i.e., single-spaced sentences) be
>> used for the English docs, consistent with the overwhelming
>> majority of modern English typographic style guides and practice...
>> Seconder? Opposed? Abstentions?
> 
> Don't we want to be following the GNU Coding Standards?  They
> explicitly suggest using two spaces after a full stop.

We are talking about the output appearance, not how the input gets
formatted.


Werner


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: tabs vs. spaces in source code

[John Mandereau]

Le samedi 25 juillet 2009 à 09:58 -0700, Mark Polesky a écrit :
> But even in such cases, as long as my tab-width matches the
> tab-widths in the source, tabs2spaces should be fine. Is it
> correct to say that git (or savannah) translates all tabs to 8
> spaces without exception?

Git doesn't translate tabs, and although 8 spaces is a commonly used
equivalence for a tab, there is no such universal standard equivalence.

As Hans pointed out, the most important is that sources look good in
text editors, so as long as it's possible to set up everyone's text
editor correctly in this respect, there's no need to worry about tabs
IMHO.

FWIW my binary of Emacs 22.3.1 does insert spaces rather than tabs in
programming and Texinfo source code.

Best,
John


signature.asc
Description: Ceci est une partie de message numériquement signée
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Docs and new web site reorganization steps

[Patrick McCarty]

On Sat, Jul 25, 2009 at 09:25:01PM +0200, John Mandereau wrote:
> Le mercredi 22 juillet 2009 à 10:30 +0200, John Mandereau a écrit :
> > Step 1) Move all Texinfo documentation in user/ and topdocs/ one
> > directory higher (done in my working tree), in translations too.
> > 
> > Step 2) Update all build and maintenance scripts and the CG.
> > At the end of this step docs should be in a releasable state again.
> > 
> > Step 3) Move Snippets and split out the essay (including CG updates).
> 
> I actually just pushed Step 1) and parts of 2) and 3) (updating build
> scripts so that the docs build :o), updating makelsr.py and moving
> snippets). I strive to update the CG and maintenance scripts and push
> this on Monday; now I know I've been awarded a PhD grant at math
> department of Pisa University (Italy), I'm going to spend for LilyPond
> the time I may probably no longer have for three years, not counting the
> delay of all what I have already promised to do for months :-P

Thanks for doing this, John!

However, I just tried `make install' after `make all', and I get the
attached output.

Thanks,
Patrick
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C python install &&  
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C scripts install && 
 make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C flower install && 
 make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C lily install &&  
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C mf install &&  
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C ly install &&  
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C tex install &&  
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C ps install &&  
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C scm install &&  
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C po install &&  
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C make install &&  
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C elisp install &&  
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C vim install &&  
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C input install &&  
make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C stepmake install 
&&  make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C Documentation 
install && true
make[1]: Entering directory `/home/pnorcks/git/lilypond/python'
(/usr/bin/python /home/pnorcks/git/lilypond/stepmake/bin/install.py -c -d 
/home/pnorcks/usr/lib/lilypond/2.13.4/python || true) && /usr/bin/python 
/home/pnorcks/git/lilypond/stepmake/bin/install.py -c -c -m 644 ./out/midi.so 
/home/pnorcks/usr/lib/lilypond/2.13.4/python/
(/usr/bin/python /home/pnorcks/git/lilypond/stepmake/bin/install.py -c -d 
/home/pnorcks/usr/share/lilypond/2.13.4/python/ || true) && /usr/bin/python 
/home/pnorcks/git/lilypond/stepmake/bin/install.py -c -c -m 644 
./out/convertrules.py ./out/fontextract.py ./out/langdefs.py ./out/lilylib.py 
./out/musicexp.py ./out/musicxml.py ./out/rational.py ./out/safeeval.py 
./out/convertrules.pyc ./out/fontextract.pyc ./out/langdefs.pyc 
./out/lilylib.pyc ./out/musicexp.pyc ./out/musicxml.pyc ./out/rational.pyc 
./out/safeeval.pyc /home/pnorcks/usr/share/lilypond/2.13.4/python/ &&  true
make PACKAGE=LILYPOND package=lilypond -C auxiliar install && true
make[2]: Entering directory `/home/pnorcks/git/lilypond/python/auxiliar'
true
make[2]: Leaving directory `/home/pnorcks/git/lilypond/python/auxiliar'
make[1]: Leaving directory `/home/pnorcks/git/lilypond/python'
make[1]: Entering directory `/home/pnorcks/git/lilypond/scripts'
make PACKAGE=LILYPOND package=lilypond -C auxiliar man &&  make 
PACKAGE=LILYPOND package=lilypond -C build man && true
make[2]: Entering directory `/home/pnorcks/git/lilypond/scripts/auxiliar'
true
make[2]: Leaving directory `/home/pnorcks/git/lilypond/scripts/auxiliar'
make[2]: Entering directory `/home/pnorcks/git/lilypond/scripts/build'
true
make[2]: Leaving directory `/home/pnorcks/git/lilypond/scripts/build'
/usr/bin/python /home/pnorcks/git/lilypond/stepmake/bin/install.py -c -d 
/home/pnorcks/usr/share/man/man1
/usr/bin/python /home/pnorcks/git/lilypond/stepmake/bin/install.py -c -c -m 644 
./out/convert-ly.1 ./out/lilypond-book.1 ./out/abc2ly.1 ./out/etf2ly.1 
./out/midi2ly.1 ./out/lilypond-invoke-editor.1 ./out/musicxml2ly.1 
./out/lilysong.1 ./out/lilymidi.1 /home/pnorcks/usr/share/man/man1
make PACKAGE=LILYPOND package=lilypond -C auxiliar all &&  make 
PACKAGE=LILYPOND package=lilypond -C build all && true
make[2]: Entering directory `/home/pnorcks/git/lilypond/scripts/auxiliar'
true
make[2]: Leaving directory `/home/pnorcks/git/lilypond/scripts/auxiliar'
make[2]: Entering directory `/home/pnorcks/git/lilypond/scripts/build'
true
make[2]: Leaving directory `/home/pnorcks/git/lilypond/scripts/build'
/usr/bin/python /home/pnorcks/git/lilypond/stepmake/bin/install.py -c -d 
/home/pnorcks/usr/bin
t

Re: Docs and new web site reorganization steps

[Patrick McCarty]

On Sat, Jul 25, 2009 at 1:05 PM, Patrick McCarty wrote:
> On Sat, Jul 25, 2009 at 09:25:01PM +0200, John Mandereau wrote:
>> Le mercredi 22 juillet 2009 à 10:30 +0200, John Mandereau a écrit :
>> > Step 1) Move all Texinfo documentation in user/ and topdocs/ one
>> > directory higher (done in my working tree), in translations too.
>> >
>> > Step 2) Update all build and maintenance scripts and the CG.
>> > At the end of this step docs should be in a releasable state again.
>> >
>> > Step 3) Move Snippets and split out the essay (including CG updates).
>>
>> I actually just pushed Step 1) and parts of 2) and 3) (updating build
>> scripts so that the docs build :o), updating makelsr.py and moving
>> snippets). I strive to update the CG and maintenance scripts and push
>> this on Monday; now I know I've been awarded a PhD grant at math
>> department of Pisa University (Italy), I'm going to spend for LilyPond
>> the time I may probably no longer have for three years, not counting the
>> delay of all what I have already promised to do for months :-P
>
> Thanks for doing this, John!
>
> However, I just tried `make install' after `make all', and I get the
> attached output.

Also, I can't find NEWS.tely in the source tree.

-Patrick


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] IR 3 Backend: More auto-sorting.

[Neil Puttock]

2009/7/25 Mark Polesky :

> In the meantime, I'll wait for someone to verify the
> revised patch.

+  (sort
(map symbol->string
 (hashq-ref iface->grob-table
(car interface)
-   '()))
+   '()))
+ly:string-cistring, otherwise LGTM.

Regards,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Docs and new web site reorganization steps

[Patrick McCarty]

On Sat, Jul 25, 2009 at 1:16 PM, Patrick McCarty wrote:
> On Sat, Jul 25, 2009 at 1:05 PM, Patrick McCarty wrote:
>> On Sat, Jul 25, 2009 at 09:25:01PM +0200, John Mandereau wrote:
>>> Le mercredi 22 juillet 2009 à 10:30 +0200, John Mandereau a écrit :
>>> > Step 1) Move all Texinfo documentation in user/ and topdocs/ one
>>> > directory higher (done in my working tree), in translations too.
>>> >
>>> > Step 2) Update all build and maintenance scripts and the CG.
>>> > At the end of this step docs should be in a releasable state again.
>>> >
>>> > Step 3) Move Snippets and split out the essay (including CG updates).
>>>
>>> I actually just pushed Step 1) and parts of 2) and 3) (updating build
>>> scripts so that the docs build :o), updating makelsr.py and moving
>>> snippets). I strive to update the CG and maintenance scripts and push
>>> this on Monday; now I know I've been awarded a PhD grant at math
>>> department of Pisa University (Italy), I'm going to spend for LilyPond
>>> the time I may probably no longer have for three years, not counting the
>>> delay of all what I have already promised to do for months :-P
>>
>> Thanks for doing this, John!
>>
>> However, I just tried `make install' after `make all', and I get the
>> attached output.
>
> Also, I can't find NEWS.tely in the source tree.

Never mind about this.  FTR, it's now called "changes.tely".

-Patrick


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: ppppp but no fffff

[Neil Puttock]

2009/7/25 Jonathan Wilkes :

> There's something in NR 3.5.5 that describes how to control MIDI behavior
> for (custom) dynamics.  But if I just use make-dynamic-script to print out
> "ff" or "z" in the score, and I don't use any other dynamics,
> it gets softer when the custom dynamic is used in the MIDI file.

The absolute dynamic value for unhandled dynamics is 0.5, just above
pianissimo.  Here's where it's set in dynamic-performer.cc:

 126   Real volume = robust_scm2double (svolume, 0.5);

Regards,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: RFC: new vertical layout engine

[Trevor Daniels]

Kieren MacMillan wrote Saturday, July 25, 2009 6:30 PM

Thanks for the reference — for subsequent thread-followers, I also 
recommend



Indeed, I just see that @frenchspacing is only used for French 
and
Japanese (the latter only partially).  It should be activated for 
all
languages except, perhaps, English.  Note that I don't care what 
you

native speakers actually decide for English


Excellent!
Then I nominate @frenchspacing (i.e., single-spaced sentences) be 
used for the English docs, consistent with the overwhelming 
majority  of modern English typographic style guides and 
practice...

Seconder? Opposed? Abstentions?


I've no problem with either one or two spaces
as a standard in the docs, but I tend to
automatically type two as I was raised on
monospaced mechanical typewriters and later
monospaced teletypes and screens.  I still prefer
a monospaced font for email - I find it much easier
to read.  It is customary to use two spaces at
the end of a sentence when using a monospaced font.
In fact it was the standard taught to professional
typists in England until word processors and
proportional fonts appeared.

Trevor 




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Weird make error

[Carl Sorensen]

I'm trying to build lilypond after doing a "make distclean".

make runs through the creation of the .o and the executable.  It finishes
the fonts, then when it starts compiling the snippets it ends with:

make PACKAGE=LILYPOND package=lilypond -C J.S.Bach all &&  make
PACKAGE=LILYPOND package=lilypond -C F.Schubert all &&  make
PACKAGE=LILYPOND package=lilypond -C E.Satie all &&  make PACKAGE=LILYPOND
package=lilypond -C W.A.Mozart all &&  make PACKAGE=LILYPOND
package=lilypond -C R.Schumann all && true
mkdir -p ./out
touch ./out/dummy.dep
echo '*' > ./out/.gitignore
true
mkdir -p ./out
touch ./out/dummy.dep
echo '*' > ./out/.gitignore
true
mkdir -p ./out
touch ./out/dummy.dep
echo '*' > ./out/.gitignore
true
mkdir -p ./out
touch ./out/dummy.dep
echo '*' > ./out/.gitignore
true
mkdir -p ./out
touch ./out/dummy.dep
echo '*' > ./out/.gitignore
true
mkdir -p ./out
touch ./out/dummy.dep
echo '*' > ./out/.gitignore
true
mkdir -p ./out
touch ./out/dummy.dep
echo '*' > ./out/.gitignore
true
make[2]: *** No rule to make target `all'.  Stop.
make[1]: *** [all] Error 2
make: *** [all] Error 2


But nothing seems to have failed.

How can I track this down?

Thanks,

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Contrib Guide not built

[Jonathan Kulp]

After pulling the latest changes, the contributor guide pdf version is not
building.  The html big-page and all other docs are built properly with
their new names. I looked through the build log and can't find any errors
saying why the CG pdf wouldn't get built.

Jon

-- 
Jonathan Kulp
http://www.jonathankulp.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: SVG backend: On-the-fly conversion of Emmentaler/Aybabtu glyphs to paths

[joeneeman]

On 2009/07/24 23:30:00, Patrick McCarty wrote:

On 2009/07/21 18:43:10, joeneeman wrote:
> I think it would be helpful if you gave an example or 2 of the sort

of string

> you expect to match here. I'm a bit worried also about the fact that

you

require
> the attributes to be in a specific order.



The new code uses a generalized regular expression that will match a



element with attributes in any order.



The code is slower now, I think due to the complexity of the new

regular

expression.  It might be a better idea if I rewrite this in C++

eventually.

How slow is it? Are we talking would-be-nice-if-it-were-faster slow or
nobody-will-want-to-use-it slow? The reason I ask is that I think the
_real_ solution would be to use an actual XML parser to parse the whole
svg font and dump all the glyphs into a hash table. As it is, you're
scanning a complicated regexp through the whole font file every time you
want a glyph.

Of course, that's a bunch of work and it involves, for example, deciding
which XML parsing lib to use and whether to use it from C++ and scheme.
So unless it's unusably slow, I'd suggest adding a TODO and committing
this patch.


http://codereview.appspot.com/96083


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: SVG backend: On-the-fly conversion of Emmentaler/Aybabtu glyphs to paths

[joeneeman]

It seems as though rietveld wants to send my code-comments and my
reply-to-comments comments in two separate emails. Sorry for the noise.


http://codereview.appspot.com/96083/diff/1015/20
File lily/pango-font.cc (right):

http://codereview.appspot.com/96083/diff/1015/20#newcode354
Line 354: bool has_utf8_string = false;
I like this way of dealing with the ps backend much better...

http://codereview.appspot.com/96083/diff/1015/20#newcode367
Line 367: if ((name == "svg" && !feta) || (name != "svg" &&
has_utf8_string))
...but I think it would be ideal if the text_stencil code was totally
unaware of the backend (maybe using something like
-ddump-music-strings-as-paths, which defaults to true when
-dbackend=svg). I'm not suggesting you do it now, but it would be nice
to have a NOTE or TODO here.

http://codereview.appspot.com/96083


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Contrib Guide not built

[Patrick McCarty]

Hi Jon,

On Sat, Jul 25, 2009 at 5:57 PM, Jonathan Kulp wrote:
> After pulling the latest changes, the contributor guide pdf version is not
> building.  The html big-page and all other docs are built properly with
> their new names. I looked through the build log and can't find any errors
> saying why the CG pdf wouldn't get built.

I can confirm.  The entire "split" version of the CG is not being built either.

I think this is a makefile issue, so I'll wait for John to look at it.
 I thought my latest build fix on master might have fixed the CG
issue, but it didn't.

The same thing appears to be happening with changes.tely (the former
NEWS.tely): the big page and translated big pages are generated, but
not the split version.

-Patrick


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: SVG backend: On-the-fly conversion of Emmentaler/Aybabtu glyphs to paths

[Patrick McCarty]

On Sat, Jul 25, 2009 at 7:03 PM,  wrote:
> On 2009/07/24 23:30:00, Patrick McCarty wrote:
>
>> The new code uses a generalized regular expression that will match a 
>> element with attributes in any order.
>> The code is slower now, I think due to the complexity of the new regular
>> expression.  It might be a better idea if I rewrite this in C++ eventually.
>
> How slow is it? Are we talking would-be-nice-if-it-were-faster slow or
> nobody-will-want-to-use-it slow? The reason I ask is that I think the
> _real_ solution would be to use an actual XML parser to parse the whole
> svg font and dump all the glyphs into a hash table. As it is, you're
> scanning a complicated regexp through the whole font file every time you
> want a glyph.
>
> Of course, that's a bunch of work and it involves, for example, deciding
> which XML parsing lib to use and whether to use it from C++ and scheme.
> So unless it's unusably slow, I'd suggest adding a TODO and committing
> this patch.

It's not as slow as I made it sound.  :-)  It really depends on how
many grobs need to be processed.

Though smaller LY files will compile more quickly now with the SVG
backend than with the PS backend (bach-schenker.ly comes to mind).

I've added the TODOs and pushed the patchset.

Thanks,
Patrick


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

How can I use git to help me merge a patch with the new directory structure

[Carl Sorensen]

As you're aware, I've been working on a patch for autobeaming.

It affects c++, scheme, and documentation files.

Now I want to apply the patch to master.  But the problem is that all of the
documentation files have moved to Documentation/ISOLANG/notation  instead of
Documentation/ISOLANG/user

So this seems to break any means of making my patch apply.

Any git gurus out there who have an idea of how I can do this without having
to manually apply patches made between the files in the different
directories?

Any help would be appreciated; right now I feel like all of my work on
autobeaming is in shambles and I'm going to have to do it all over again.

Thanks,

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel