On Thu, Oct 14, 2010 at 4:57 PM, Mark Polesky wrote:
> I think this is a good time to rethink how LilyPond uses the
> \markup command. Perhaps the code is too casual in this
> respect? It would be nice instead to have a more semantic
> command vocabulary to replace top-level markups, for
> examp
On Thu, Oct 14, 2010 at 07:57:02AM -0700, Mark Polesky wrote:
> David Kastrup wrote:
> > In short, we are going down a road now where any
> > user-visible improvement (for which the necessity is
> > clear) will become increasingly painful to do for both
> > developers and users.
Sure. Let's bite
Mark Polesky writes:
> David Kastrup wrote:
>> In short, we are going down a road now where any
>> user-visible improvement (for which the necessity is
>> clear) will become increasingly painful to do for both
>> developers and users.
>>
>> Since obviously I am alone with this opinion among the
>
David Kastrup wrote:
> In short, we are going down a road now where any
> user-visible improvement (for which the necessity is
> clear) will become increasingly painful to do for both
> developers and users.
>
> Since obviously I am alone with this opinion among the
> developers, I would suggest po
David Kastrup wrote Thursday, October 14, 2010 10:05 AM
"Trevor Daniels" writes:
Although this is a good point, the problem is not as
stark as this might suggest. There are many situations
when writing LilyPond code when score-wide settings are
inappropriate. This is just another. \overr
Valentin Villenave writes:
> On Thu, Oct 14, 2010 at 9:42 AM, David Kastrup wrote:
>> Let me put it bluntly: the new scheme cements the decision to make
>> markups and titles have the same spacing.
>
> Greetings David,
>
> Quoting Mark (the man through whom the scandal cometh!)
That is the wron
On Thu, Oct 14, 2010 at 9:42 AM, David Kastrup wrote:
> Let me put it bluntly: the new scheme cements the decision to make
> markups and titles have the same spacing.
Greetings David,
Quoting Mark (the man through whom the scandal cometh!) in the very
first mail in this thread,
"
Obviously not
"Trevor Daniels" writes:
> Although this is a good point, the problem is not as
> stark as this might suggest. There are many situations
> when writing LilyPond code when score-wide settings are
> inappropriate. This is just another. \override permits
> appropriate setting to be made at each p
David Kastrup wrote Thursday, October 14, 2010 8:42 AM
Carl Sorensen writes:
On 10/13/10 2:40 PM, "David Kastrup" wrote:
The point is that we want a sane way of specifying document
layout
parameters. The current naming scheme resembles that desire.
The
current code not. Adapting the n
Carl Sorensen writes:
> On 10/13/10 2:40 PM, "David Kastrup" wrote:
>
>> The point is that we want a sane way of specifying document layout
>> parameters. The current naming scheme resembles that desire. The
>> current code not. Adapting the naming scheme to the deficiencies of
>> the code is
On 10/13/10 2:40 PM, "David Kastrup" wrote:
> Carl Sorensen writes:
>
>> On 10/13/10 8:29 AM, "David Kastrup" wrote:
>>
>>> Carl Sorensen writes:
>>>
David Kastrup writes:
>
>
> So my fear is that the new scheme is both strictly logical, and not
> useful for
Carl Sorensen writes:
> On 10/13/10 8:29 AM, "David Kastrup" wrote:
>
>> Carl Sorensen writes:
>>
>>> David Kastrup writes:
>>>
So my fear is that the new scheme is both strictly logical, and not
useful for specifying a coherent document layout.
>>>
>>> But the new sch
On 10/13/10 8:29 AM, "David Kastrup" wrote:
> Carl Sorensen writes:
>
>> David Kastrup writes:
>>>
>>
>>>
>>> So my fear is that the new scheme is both strictly logical, and not
>>> useful for specifying a coherent document layout.
>>
>> But the new scheme is just a restatement (renamin
Carl Sorensen writes:
> David Kastrup writes:
>>
>
>>
>> So my fear is that the new scheme is both strictly logical, and not
>> useful for specifying a coherent document layout.
>
> But the new scheme is just a restatement (renaming) of the current
> scheme.
The renaming moves from a document
David Kastrup writes:
>
>
> So my fear is that the new scheme is both strictly logical, and not
> useful for specifying a coherent document layout.
But the new scheme is just a restatement (renaming) of the current scheme.
Mark is not trying to *redo* the document layout algorithms; he's tryi
David Kastrup writes:
> Mark Polesky writes:
>
>> David Kastrup wrote:
>>> The main problem I see with that naming scheme is that it
>>> does not reflect score sheet design, but the current
>>> implementation.
>>>
>>> [...]
>>>
>>> So the proposed scheme ties something presented as document
>>>
On Tue, Oct 12, 2010 at 07:18:37PM -0400, James Lowe wrote:
> As an instrument player (as opposed to a singer or 'vocalist')
> who has neither conducted or composed anything more than a few
> 'dittys' I can see how this would be the case where I have never
> come across the term system.
For the re
On Wed, Oct 13, 2010 at 12:20:04AM +0100, Trevor Daniels wrote:
>
> Graham Percival
>
> >I would recommend adding this to Learning 2 Tutorial. Maybe
> >somewhere in 2.3 Multiple notes at once; maybe somewhere in
> >2.5 Final touches. I'll let somebody else think about it in more
> >detail and p
On Tue, Oct 12, 2010 at 04:58:42PM -0600, Carl Sorensen wrote:
>
> it is "staff" and "staves", according to the GDP rules:
>
> http://lists.gnu.org/archive/html/lilypond-devel/2007-09/msg00240.html
Thanks! James, could you send me a patch for the CG?
> Of course, Neil considered that a US bias
On 12/10/10 23:45, Alexander Kobel wrote:
> On 2010-10-13 00:27, Wols Lists wrote:
>> Add "stave" to this. Actually, I would have defined a stave as a line of
>> music, and a system as a group of linked staves played simultaneously.
>> But that all depends on how you understand the word "line" :-)
On 12/10/10 23:44, Graham Percival wrote:
> On Tue, Oct 12, 2010 at 04:23:49PM -0600, Carl Sorensen wrote:
>> On 10/12/10 4:20 PM, "Wols Lists" wrote:
>>
>>> For a musician to get that wrong is as seriously incompetent as for a
>>> computer guy to refer to a hard disk as ram (I know the
>>> man-i
Graham Percival
Yes, but I see some weaknesses in our docs.
- Glossary: staff should link to system
- Glossary: both staff and system could benefit from images
- Learning: add some link(s) to Glossary: system. Currently we
have none!
gperc...@futoi:~/src/lilypond/Documentation/learning$ git
Graham Percival
Sent: Tue 12/10/2010 23:44
To: Carl Sorensen
Cc: lilypond-devel@gnu.org
Subject: Re: names of vertical spacing dimensions
On Tue, Oct 12, 2010 at 04:23:49PM -0600, Carl Sorensen wrote:
>
> On 10/12/10 4:20 PM, "Wols Lists" wrote:
>
> > For a musician to
On 10/12/10 4:51 PM, "Graham Percival" wrote:
> On Wed, Oct 13, 2010 at 12:45:33AM +0200, Alexander Kobel wrote:
>> On 2010-10-13 00:27, Wols Lists wrote:
>>> Add "stave" to this. Actually, I would have defined a stave as a line of
>>> music, and a system as a group of linked staves played sim
On Wed, Oct 13, 2010 at 12:45:33AM +0200, Alexander Kobel wrote:
> On 2010-10-13 00:27, Wols Lists wrote:
> >Add "stave" to this. Actually, I would have defined a stave as a line of
> >music, and a system as a group of linked staves played simultaneously.
> >But that all depends on how you understa
On 10/12/10 4:27 PM, "Wols Lists" wrote:
> On 12/10/10 22:05, Graham Percival wrote:
>> On Tue, Oct 12, 2010 at 02:24:37PM +0100, Trevor Daniels wrote:
I'll stop if I am really showing my ignorance (I am not a code
developer),
>>> I'm afraid you're showing your ignorance as a musici
On 2010-10-13 00:27, Wols Lists wrote:
Add "stave" to this. Actually, I would have defined a stave as a line of
music, and a system as a group of linked staves played simultaneously.
But that all depends on how you understand the word "line" :-)
"Stave" or "staff"?! Are these identical? I tho
On Tue, Oct 12, 2010 at 04:23:49PM -0600, Carl Sorensen wrote:
>
> On 10/12/10 4:20 PM, "Wols Lists" wrote:
>
> > For a musician to get that wrong is as seriously incompetent as for a
> > computer guy to refer to a hard disk as ram (I know the
> > man-in-the-street tends to call them both "memor
On 2010-10-13 00:20, Wols Lists wrote:
On 12/10/10 14:02, Kieren MacMillan wrote:
Hi James,
[...]
If Lilypond users are confused because they don't have an understanding of that
basic and universal terminology, they should read (1) some engraving books, and
(2) the Lilypond introductory doc
On 12/10/10 22:05, Graham Percival wrote:
> On Tue, Oct 12, 2010 at 02:24:37PM +0100, Trevor Daniels wrote:
>>> I'll stop if I am really showing my ignorance (I am not a code
>>> developer),
>> I'm afraid you're showing your ignorance as a musician.
>> System and score are not synonomous. A syste
On 10/12/10 4:20 PM, "Wols Lists" wrote:
> On 12/10/10 14:02, Kieren MacMillan wrote:
>> Hi James,
>>
>>> I still think a *user* (not programmer or code developer) is going to really
>>> get frustrated when they don't know what a system is i.e... 'oh you mean the
>>> stuff with the notes in.
On 12/10/10 14:02, Kieren MacMillan wrote:
> Hi James,
>
>> I still think a *user* (not programmer or code developer) is going to really
>> get frustrated when they don't know what a system is i.e... 'oh you mean the
>> stuff with the notes in...we call that a 'score' where I come from.
> The en
On 12/10/10 00:55, Graham Percival wrote:
>> Why not push it as one patch? It seems like all of those pieces need
>> > to be accomplished in order to have a fully-buildable release (i.e. if the
>> > variable names in lilypond don't match the variable names in the docs,
>> > make doc will fail.
>
On Tue, Oct 12, 2010 at 02:24:37PM +0100, Trevor Daniels wrote:
>
> >I'll stop if I am really showing my ignorance (I am not a code
> >developer),
>
> I'm afraid you're showing your ignorance as a musician.
> System and score are not synonomous. A system is a "line"
> of music which includes the
Mark Polesky writes:
> David Kastrup wrote:
>> The main problem I see with that naming scheme is that it
>> does not reflect score sheet design, but the current
>> implementation.
>>
>> [...]
>>
>> So the proposed scheme ties something presented as document
>> spacing parameters into internal de
David Kastrup wrote:
> The main problem I see with that naming scheme is that it
> does not reflect score sheet design, but the current
> implementation.
>
> [...]
>
> So the proposed scheme ties something presented as document
> spacing parameters into internal details of their
> implementation.
Alexander Kobel writes:
> On 2010-10-09 17:46, Mark Polesky wrote:
>> CURRENT NAME PROPOSED NAME
>> -
>> top-system top-system
>> top-title top-markup
>> between-title markup-markup
>> after-titlemarkup-sys
James wrote Tuesday, October 12, 2010 1:27 PM
On 12/10/2010 12:54, David Kastrup wrote:
James writes:
Hello,
On 12/10/2010 10:13, Alexander Kobel wrote:
On 2010-10-09 17:46, Mark Polesky wrote:
CURRENT NAME PROPOSED NAME
-
top-system top-system
top-title top-mar
On 2010-10-12 14:27, James wrote:
On 12/10/2010 12:54, David Kastrup wrote:
James writes:
Why do we have
'top-system' but 'system-bottom' and not instead, 'bottom-system'?
Because there is no system after the bottom?
?
I'll stop if I am really showing my ignorance (I am not a code
develope
Hi James,
> I still think a *user* (not programmer or code developer) is going to really
> get frustrated when they don't know what a system is i.e... 'oh you mean the
> stuff with the notes in...we call that a 'score' where I come from.
The entire music engraving world -- not just Lilypond, bu
Hello,
On 12/10/2010 12:54, David Kastrup wrote:
James writes:
Hello,
On 12/10/2010 10:13, Alexander Kobel wrote:
On 2010-10-09 17:46, Mark Polesky wrote:
CURRENT NAME PROPOSED NAME
-
top-system top-system
top-title top-markup
between-title markup-markup
after-titl
On Tue 12 Oct 2010, 13:54 David Kastrup wrote:
> James writes:
> >>> top-system top-system
> >>> top-title top-markup
> >>> between-title markup-markup
> >>> after-title markup-system
> >>> between-system system-system
> >>> before-title system-markup
> >>> bottom-system system-bottom
> >>> betwee
James writes:
> Hello,
>
> On 12/10/2010 10:13, Alexander Kobel wrote:
>> On 2010-10-09 17:46, Mark Polesky wrote:
>>> CURRENT NAME PROPOSED NAME
>>> -
>>> top-system top-system
>>> top-title top-markup
>>> between-title markup-markup
>>> after-title markup-system
>>> bet
Hello,
On 12/10/2010 10:13, Alexander Kobel wrote:
On 2010-10-09 17:46, Mark Polesky wrote:
CURRENT NAME PROPOSED NAME
-
top-system top-system
top-title top-markup
between-title markup-markup
after-title markup-system
between-system system-system
before-title system-mar
On 2010-10-09 17:46, Mark Polesky wrote:
CURRENT NAME PROPOSED NAME
-
top-system top-system
top-title top-markup
between-title markup-markup
after-titlemarkup-system
between-system system-system
bef
On Mon, Oct 11, 2010 at 6:29 PM, Carl Sorensen wrote:
> On 10/10/10 12:56 PM, "Mark Polesky" wrote:
>
>> ...but Rietveld meshed them all into one. So, once
>> approved, I'll push it as a set of patches, not just one.
>
> Why not push it as one patch? It seems like all of those pieces need
> to
On 10/10/10 12:56 PM, "Mark Polesky" wrote:
> Here's an updated patch set for review:
> http://codereview.appspot.com/2303044/
>
> It's organized into 5 commits on my local branch:
> 1) Rename vertical spacing dimensions.
> 2) Update convert-ly (vertical spacing).
> 3) Run convert-ly on affected
Here's an updated patch set for review:
http://codereview.appspot.com/2303044/
It's organized into 5 commits on my local branch:
1) Rename vertical spacing dimensions.
2) Update convert-ly (vertical spacing).
3) Run convert-ly on affected regtests (vert. spacing).
4) Revise regtest texidoc headers
On Sat, Oct 09, 2010 at 05:50:49PM +0100, Trevor Daniels wrote:
>
> Mark Polesky wrote Saturday, October 09, 2010 4:46 PM
>
> >It's not that I want to split hairs; I want to get the new
> >variable names right the first time. My apologies to any of
> >you who are getting tired with this process.
On 10/9/10 10:52 AM, "Joe Neeman" wrote:
>
>
> On Sat, Oct 9, 2010 at 9:05 AM, Carl Sorensen wrote:
>> On 10/9/10 9:46 AM, "Mark Polesky" wrote:
>>
* * * * * * * * * *
"before-title-spacing" applies to these cases:
1) from last system in a score to top-level markup.
>
On Sat, Oct 9, 2010 at 9:05 AM, Carl Sorensen wrote:
> On 10/9/10 9:46 AM, "Mark Polesky" wrote:
>
> > * * * * * * * * * *
> >
> > "before-title-spacing" applies to these cases:
> > 1) from last system in a score to top-level markup.
> > 2) from last system of one score to scoreTitleMarkup of
>
Mark Polesky wrote Saturday, October 09, 2010 4:46 PM
It's not that I want to split hairs; I want to get the new
variable names right the first time. My apologies to any of
you who are getting tired with this process.
:) Yes, thanks! I'm afraid I'm no longer following this
discussion suff
On 10/9/10 9:46 AM, "Mark Polesky" wrote:
> * * * * * * * * * *
>
> "before-title-spacing" applies to these cases:
> 1) from last system in a score to top-level markup.
> 2) from last system of one score to scoreTitleMarkup of
>another score.
>
> Within the proposed naming scheme, the 2 cho
(David, see the note at the end of this post)
It's not that I want to split hairs; I want to get the new
variable names right the first time. My apologies to any of
you who are getting tired with this process. My current
(and hopefully final) proposal is now this:
CURRENT NAME PROPOSE
Mark Polesky writes:
> (Carl et al.: please read at least the last paragraph!)
>
> Xavier Scheuer wrote:
>> The previous names were quite easy to understand (although
>> it was a bit difficult due to the large number of such
>> variables) but I don't catch at first sight the meaning of
>> the new
(Carl et al.: please read at least the last paragraph!)
Xavier Scheuer wrote:
> The previous names were quite easy to understand (although
> it was a bit difficult due to the large number of such
> variables) but I don't catch at first sight the meaning of
> the new proposed ones...
Well, in the
On 8 October 2010 09:14, Mark Polesky wrote:
>
> [...]
>
> This leaves:
>
> CURRENT NAME PROPOSED NAME
> -
> top-system top-system (no change)
> top-title top-markup
> between-title markup-markup
> after-title
Carl Sorensen wrote:
> Does before-title-spacing apply at the top of the first
> page, or only between scores?
"before-title-spacing" does *not* apply at the top of the
first page, even when print-first-page-number is #t (to
force a header).
> Does between-scores-system-spacing apply only to the
On 10/7/10 8:59 AM, "Mark Polesky" wrote:
> Enough votes are in for 'base-distance (and you can add my
> vote as well), so I think that settles it. But I still need
> people to comment on
>
> 1) the patch:
> http://codereview.appspot.com/2303044
The patch looks fine to me.
>
> and
>
> 2)
On Thu, Oct 07, 2010 at 07:59:25AM -0700, Mark Polesky wrote:
> 1) Pardon my ignorance, but do we ever run convert-ly on the
> regtests?
I'd consider that as part of 1288.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://l
Enough votes are in for 'base-distance (and you can add my
vote as well), so I think that settles it. But I still need
people to comment on
1) the patch:
http://codereview.appspot.com/2303044
and
2) the approach:
http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00095.html
Two more q
Carl Sorensen writes:
> On 10/7/10 7:51 AM, "Valentin Villenave" wrote:
>
>> On Thu, Oct 7, 2010 at 3:41 PM, Carl Sorensen wrote:
>>> I think I'd prefer desired-distance to optimal-distance. optimal distance
>>> is what the algorithms actually end up with, as a tradeoff between desired
>>> dis
On Thu, Oct 7, 2010 at 3:41 PM, Carl Sorensen wrote:
> I think I'd prefer desired-distance to optimal-distance. optimal distance
> is what the algorithms actually end up with, as a tradeoff between desired
> distance and the amount of stuff on a page.
How about requested- rather than desired-?
On 10/7/10 7:51 AM, "Valentin Villenave" wrote:
> On Thu, Oct 7, 2010 at 3:41 PM, Carl Sorensen wrote:
>> I think I'd prefer desired-distance to optimal-distance. optimal distance
>> is what the algorithms actually end up with, as a tradeoff between desired
>> distance and the amount of stuf
On 2010-10-07 15:53, Carl Sorensen wrote:
I like base-; it's shorter to type, and it still carries the right
connotation.
+1.
Cheers,
Alexander
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-de
On 10/7/10 1:44 AM, "Alexander Kobel" wrote:
> On 2010-10-06 17:46, Mark Polesky wrote:
>> I also think the name 'space is misleading; I propose
>> 'default-distance. Opinions?
>
> I can't see why 'space should be misleading, but that might just be that
> I'm accustomed to it by now. It's s
Mark Polesky writes:
> IIUC, making all of these changes should be done in 5 steps:
>
> 1) rename the variables in the code files
> 2) change 'space to 'default-distance* in the code files
> 3) write rules for convert-ly
> 4) update affected regtests (?)
> 5) update the docs
>
> *or Alexander's "
IIUC, making all of these changes should be done in 5 steps:
1) rename the variables in the code files
2) change 'space to 'default-distance* in the code files
3) write rules for convert-ly
4) update affected regtests (?)
5) update the docs
*or Alexander's "optimal-distance" (still open to debate
On 2010-10-06 17:46, Mark Polesky wrote:
I also think the name 'space is misleading; I propose
'default-distance. Opinions?
I can't see why 'space should be misleading, but that might just be that
I'm accustomed to it by now. It's shorter, but anything other is okay
as well.
(Of course, thi
Mark Polesky wrote Wednesday, October 06, 2010 4:46 PM
I also think the name 'space is misleading; I propose
'default-distance. Opinions?
I'd be happy with that change too.
Mark
Trevor
___
lilypond-devel mailing list
lilypond-devel
On 10/6/10 9:46 AM, "Mark Polesky" wrote:
> I also think the name 'space is misleading; I propose
> 'default-distance. Opinions?
So then we'd have, for each item-item-spacing entry
default-distance -- the non-stretched distance between the upper item
reference point and the lower item refer
I also think the name 'space is misleading; I propose
'default-distance. Opinions?
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Mark Polesky wrote Monday, October 04, 2010 11:14 PM
Usually when I propose things like this, they're shot down
pretty fast, but here goes anyway.
It took me a while to mentally connect the names of the
vertical spacing variables with their specific domains. For
example, I think it's counter
Usually when I propose things like this, they're shot down
pretty fast, but here goes anyway.
It took me a while to mentally connect the names of the
vertical spacing variables with their specific domains. For
example, I think it's counterintuitive that
'after-title-spacing does *not* affect the
74 matches
Mail list logo
