Hi Carl et al,
> I believe that this indentation scheme is more consistent with standard
> Scheme indentation than the other. (parser location args) is at the same
> list level as (arg-type-predicates) so it should have the same or higher
> indentation, not lower.
>
> I like this, and would be v
On 4/27/10 1:44 AM, "Nicolas Sceaux" wrote:
>
> Actually, a nice indentation would be:
>
> #(define-music-function (parser location args)
> (arg-type-predicates)
>body)
>
> or:
>
> #(define-music-function
> (parser location args)
> (arg-type-predicates)
>body)
>
I
Nicolas Sceaux wrote:
> Actually, a nice indentation would be:
>
> #(define-music-function (parser location args)
> (arg-type-predicates)
>body)
>
> or:
>
> #(define-music-function
> (parser location args)
> (arg-type-predicates)
>body)
I much prefer the second of these two
Le 26 avr. 2010 à 19:46, Carl Sorensen a écrit :
> The problem is that the #{ throws off the emacs Scheme editor (at least I
> assume that's what happens).
>
> So there are two reasonably compliant choices for indentation.
>
> #(define-music-function (parser location args)
>
On 4/26/10 11:19 AM, "Graham Percival" wrote:
> On Mon, Apr 26, 2010 at 5:49 PM, Carl Sorensen wrote:
>>
>> On 4/26/10 10:21 AM, "Graham Percival" wrote:
>>
>>> I object to the scheme indentation -- to the extent that we have a
>>> standard for lilypond input files (which isn't much), we f
On Mon, Apr 26, 2010 at 5:49 PM, Carl Sorensen wrote:
>
> On 4/26/10 10:21 AM, "Graham Percival" wrote:
>
>> I object to the scheme indentation -- to the extent that we have a
>> standard for lilypond input files (which isn't much), we follow
>> normal scheme indentation.
>
> The new patch actual
On 4/26/10 10:21 AM, "Graham Percival" wrote:
> On Sun, Apr 25, 2010 at 06:34:53PM -0700, Mark Polesky wrote:
>> Notwithstanding that specific issue, any suggestions,
>> objections, etc?
>
> I object to the scheme indentation -- to the extent that we have a
> standard for lilypond input files
On Sun, Apr 25, 2010 at 06:34:53PM -0700, Mark Polesky wrote:
> Notwithstanding that specific issue, any suggestions,
> objections, etc?
I object to the scheme indentation -- to the extent that we have a
standard for lilypond input files (which isn't much), we follow
normal scheme indentation.
An
On 4/26/10 9:47 AM, "Mark Polesky" wrote:
> Just noticed some markup type-predicates not listed in
> type-p-name-alist:
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=scm/markup.scm;h=d
> fa349e;hb=HEAD#l458
>
> Should I define-public them and add them to the alist?
In my opinion
Just noticed some markup type-predicates not listed in
type-p-name-alist:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=scm/markup.scm;h=dfa349e;hb=HEAD#l458
Should I define-public them and add them to the alist?
- Mark
___
lilyp
Carl Sorensen wrote:
>> Here's a patch to reorganize the music functions [...]
>
> Can you post it on Rietveld? It's much easier to review
> there.
Sure. I accidentally left out a file in the previous patch
anyway. Here it is on Rietveld:
http://codereview.appspot.com/970044
- Mark
On 4/25/10 7:34 PM, "Mark Polesky" wrote:
> Here's a patch to reorganize the music functions material in
> Notation and Extending. This also includes (finally) some
> code to auto-document the available type predicates in
> type-p-name-alist.
>
> Before I finish the re-editing, however, I'd
PATCH] Doc: Reorganize music functions material.
* Remove nodes from Extending that are covered in
Notation:
2.1.1 Music function syntax
2.1.2 Simple substitution functions
* In Extending 2.1, move `Void functions' to end
of section, so `Functions without arguments'
comes first.
13 matches
Mail list logo
