Re: format-mark-* Was: \set vs \override

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: format-mark-* Was: \set vs \override

Valentin Villenave
Administrator
On Wed, Dec 2, 2009 at 9:04 AM, Mats Bengtsson <[hidden email]> wrote:

> Running the command "grep format-mark- scm/translation-functions.scm" in
> Linux gives the following list of functions:
>
> (define-public (format-mark-alphabet mark context)
> (define-public (format-mark-box-alphabet mark context)
> (define-public (format-mark-circle-alphabet mark context)
> (define-public (format-mark-letters mark context)
> (define-public (format-mark-numbers mark context)
> (define-public (format-mark-barnumbers mark context)
> (define-public (format-mark-box-letters mark context)
> (define-public (format-mark-circle-letters mark context)
> (define-public (format-mark-box-numbers mark context)
> (define-public (format-mark-circle-numbers mark context)
> (define-public (format-mark-box-barnumbers mark context)
> (define-public (format-mark-circle-barnumbers mark context)
>
> The documentation in Documentation/notation/rhythms.itely doesn't seem to
> have been updated since these were introduced. I'm already 5 minutes late
> for a meeting, otherwise I would have fixed it myself, but perhaps some frog
> can do it.

CC-ing to the frogs list.

Cheers,
Valentin

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: Re: format-mark-* Was: \set vs \override

Carl Sorensen



On 12/2/09 2:47 AM, "Valentin Villenave" <[hidden email]> wrote:

> On Wed, Dec 2, 2009 at 9:04 AM, Mats Bengtsson <[hidden email]>
> wrote:
>> Running the command "grep format-mark- scm/translation-functions.scm" in
>> Linux gives the following list of functions:
>>
>> (define-public (format-mark-alphabet mark context)
>> (define-public (format-mark-box-alphabet mark context)
>> (define-public (format-mark-circle-alphabet mark context)
>> (define-public (format-mark-letters mark context)
>> (define-public (format-mark-numbers mark context)
>> (define-public (format-mark-barnumbers mark context)
>> (define-public (format-mark-box-letters mark context)
>> (define-public (format-mark-circle-letters mark context)
>> (define-public (format-mark-box-numbers mark context)
>> (define-public (format-mark-circle-numbers mark context)
>> (define-public (format-mark-box-barnumbers mark context)
>> (define-public (format-mark-circle-barnumbers mark context)
>>
>> The documentation in Documentation/notation/rhythms.itely doesn't seem to
>> have been updated since these were introduced. I'm already 5 minutes late
>> for a meeting, otherwise I would have fixed it myself, but perhaps some frog
>> can do it.

I started doing this, but got off it for some other reason (I can't remember
why).

Doing this right probably means a careful explanation of a few of these in
the NR, and an appendix showing all of the possibilities.

Thanks,

Carl


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: Re: format-mark-* Was: \set vs \override

Valentin Villenave
Administrator
On Wed, Dec 2, 2009 at 5:38 PM, Carl Sorensen <[hidden email]> wrote:
> Doing this right probably means a careful explanation of a few of these in
> the NR, and an appendix showing all of the possibilities.

I was about to suggest something like that, but aren't appendices
automatically generated? How would you implement that?

Cheers,
Valentin

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: Re: format-mark-* Was: \set vs \override

Mats Bengtsson-3
Why not simply extend the current example so that it shows all the
possibilities? No need to explain in words, especially since the names
are more or less self-explanatory.

     /Mats

Valentin Villenave wrote:

> On Wed, Dec 2, 2009 at 5:38 PM, Carl Sorensen <[hidden email]> wrote:
>  
>> Doing this right probably means a careful explanation of a few of these in
>> the NR, and an appendix showing all of the possibilities.
>>    
>
> I was about to suggest something like that, but aren't appendices
> automatically generated? How would you implement that?
>
> Cheers,
> Valentin
>  


--
=============================================
        Mats Bengtsson
        Signal Processing
        School of Electrical Engineering
        Royal Institute of Technology (KTH)
        SE-100 44  STOCKHOLM
        Sweden
        Phone: (+46) 8 790 8463
        Fax:   (+46) 8 790 7260
        Email: [hidden email]
        WWW: http://www.s3.kth.se/~mabe
=============================================


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: Re: format-mark-* Was: \set vs \override

Carl Sorensen



On 12/2/09 1:40 PM, "Mats Bengtsson" <[hidden email]> wrote:

> Why not simply extend the current example so that it shows all the
> possibilities? No need to explain in words, especially since the names
> are more or less self-explanatory.

Because it's too many things to list in the body of the NR.  We try to keep
the body of the NR as short as feasible, and put exhaustive lists in the
appendices.

>
>      /Mats
>
> Valentin Villenave wrote:
>> On Wed, Dec 2, 2009 at 5:38 PM, Carl Sorensen <[hidden email]> wrote:
>>  
>>> Doing this right probably means a careful explanation of a few of these in
>>> the NR, and an appendix showing all of the possibilities.
>>>    
>>
>> I was about to suggest something like that, but aren't appendices
>> automatically generated? How would you implement that?
>>

You make a .ly file that shows everything you want, then include a reference
to that file in Documentation/notation/notation-appendices.itely.

Or alternatively, you make your own table to show things in
Documentation/notation/notation-appendices.itely.


Thanks,

Carl


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: Re: format-mark-* Was: \set vs \override

Mats Bengtsson-3
Carl Sorensen wrote:

>
> On 12/2/09 1:40 PM, "Mats Bengtsson" <[hidden email]> wrote:
>
>  
>> Why not simply extend the current example so that it shows all the
>> possibilities? No need to explain in words, especially since the names
>> are more or less self-explanatory.
>>    
>
> Because it's too many things to list in the body of the NR.  We try to keep
> the body of the NR as short as feasible, and put exhaustive lists in the
> appendices.
>  
Really? We already include many LSR snippets that are fairly large. Why
not do it that way?

   /Mats

---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: Re: format-mark-* Was: \set vs \override

Carl Sorensen



On 12/2/09 2:58 PM, "Mats Bengtsson" <[hidden email]> wrote:

> Carl Sorensen wrote:
>>
>> On 12/2/09 1:40 PM, "Mats Bengtsson" <[hidden email]> wrote:
>>
>>  
>>> Why not simply extend the current example so that it shows all the
>>> possibilities? No need to explain in words, especially since the names
>>> are more or less self-explanatory.
>>>    
>>
>> Because it's too many things to list in the body of the NR.  We try to keep
>> the body of the NR as short as feasible, and put exhaustive lists in the
>> appendices.
>>  
> Really? We already include many LSR snippets that are fairly large. Why
> not do it that way?

We don't include any LSR snippets in the main body of the manual.

Snippets in the main body of the manual are inlined in the manual.

LSR snippets appear in the "Selected Snippets" section (following the main
explanation).

Exhaustive lists are in the appendices.

We could certainly create an LSR snippet that listed all the possibilities,
and have that show up in the Selected Snippets section instead of in the
appendix.

But I think it's more consistent with the GDP manual ordering to do it with
an Appendix.


Graham, what do you think?  You're the last word on documentation standards.

Thanks,

Carl


---
----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: Re: format-mark-* Was: \set vs \override

Graham Percival
On Wed, Dec 02, 2009 at 03:41:06PM -0700, Carl Sorensen wrote:

>
> On 12/2/09 2:58 PM, "Mats Bengtsson" <[hidden email]> wrote:
>
> >> Because it's too many things to list in the body of the NR.  We try to keep
> >> the body of the NR as short as feasible, and put exhaustive lists in the
> >> appendices.
> >>  
> > Really? We already include many LSR snippets that are fairly large. Why
> > not do it that way?
>
> We don't include any LSR snippets in the main body of the manual.
>
> Snippets in the main body of the manual are inlined in the manual.

That's not _entirely_ true; there's the maoing
Documentation/included/.  I'd like to get rid of it, but that
would be a 1- or 5-hour (me vs newbie) task that has relatively
little payoff.

> We could certainly create an LSR snippet that listed all the possibilities,
> and have that show up in the Selected Snippets section instead of in the
> appendix.
>
> But I think it's more consistent with the GDP manual ordering to do it with
> an Appendix.

After counting the items in the original email, it's literally 12
of one, and a dozen of the other.

Appendices are generally for large lists; as far as I see, all the
appendices have at least 100 items in them.  I don't know quite
where the ideal cutoff would come, but my initial feeling is that
it'd be somewhere around 30.

So I think in this case, a snippet is appropriate.

Cheers,
- Graham

---
----
Join the Frogs!