gt;
> vim's scheme code indenting is the same as "whatever emacs does".
AFAICT, Emacs does a bad job concerning -> articulations, probably
confusing them with < > braces.
So maybe a bit more like "whatever emacs should do".
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
fond of this name, but can't think of anything better. :)
>
> I think two-side would be at least a slight improvement.
>
> http://codereview.appspot.com/144049
If it is a flag, two-sided seems more appropriate.
--
David Kastrup
___
lily
"Bertalan Fodor (LilyPondTool)" writes:
>> Han-Wen Nienhuys wrote:
>>
>> On Thu, Nov 5, 2009 at 12:48 PM, David Kastrup wrote:
>>
>> I was wondering what the Lilypond policies are for using
>> SRFI, such as SRFI-13 for string fu
(ly:assoc-get 'reedbanks register
(result (markup #:musicglyph
(ly:assoc-get 'glyph instrument
(if (null? dots) result
(markup-builder (cdr dots)
t; to stop looking in v2.9 (hmm, maybe it thinks that v2.9 is higher
> than v2.12 ?), but I'd need to spend a few minutes looking it up,
> and this is really far down on the priority list.
But it's a good idea. Some installers for Lilypond apparently don't
install any kind of info
finitely more suitably done on the
developer list.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Jan Nieuwenhuizen writes:
> I'm not sure the solution to remove al older v2.9 etc. from google is
> a smart thing to do.
I think it is much better than the alternatives.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@g
and rather than needing to be compiled in.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Jan Nieuwenhuizen writes:
> Op donderdag 12-11-2009 om 08:41 uur [tijdzone +0100], schreef David
> Kastrup:
>> Carl Sorensen writes:
>
>> _Addressing_ the actual problems is definitely more suitably done on the
>> developer list.
>
> So what are the actual pro
Jan Nieuwenhuizen writes:
> Op donderdag 12-11-2009 om 08:55 uur [tijdzone +0100], schreef David
> Kastrup:
>> Jan Nieuwenhuizen writes:
>
>> > I'm not sure the solution to remove al older v2.9 etc. from google is
>> > a smart thing to do.
>>
>&g
ers are
passionate enough about it, they will do a better job than you can.
Lilypond is a batch processing system. You can use whatever editor you
like with it. If there are people who like Emacs, that does not change
Lilypond to the better or worse.
--
David Kastrup
__
ge
> Lilypond to the better or worse.
>
> I'm talking about developer tools. For example, some months ago I got
> the advice to use "grep" to browse LilyPond source code.
So what? If you have a better tool, by all means use it. Emacs does a
pretty good job for me, but yo
declined to participate even in LilyPondTool.
All others participate with LilyPondTool? That's actually an absolutely
amazing quota.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
>
> On Mac OS X 10.5.8, I can see it using 'less'; it looks like:
> \version "2.12.1"
>
> { c }
>
> But emacs 23.1.1 does not show it at all.
C-h C RET RET
gives
Coding system for saving this buffer:
U -- utf-8-with-signature-unix
Notice the "with-signat
t;BBEdit Jr.", freeware) also has this wonderful feature.
As does M-x grep RET in Emacs. And it's variants like M-x grep-find RET
and similar. But Emacs can also navigate using tags tables, which is
more direct and makes it easier to find definitions.
--
David Kastrup
__
Jesús Guillermo Andrade writes:
> El 12/11/2009, a las 04:11 a.m., David Kastrup escribió:
>
> Jan Nieuwenhuizen writes:
>
>
> As a new contributor/developer, by using a different, and a particular
>
> unfriendly platform for free software develop
Why does define-internal-markup-command have more arguments than
define-markup-command? One is the doc, but there also seem to be
default properties. Why doesn't define-markup-command have properties
to specify as well?
Thanks for insights.
--
David Ka
s thing? Or even
{ 4 }*8 ?
That would be so much more natural. The first already does something,
but not something which I would call useful. The second bombs out.
In contrast, q feels rather hackish.
--
David Kastrup
___
lilypond-devel mailing l
Marc Hohl writes:
> David Kastrup schrieb:
>>>
> This is great!
>>> I've chosed arbitrary defaults, which may be changed:
>>> - the shortcut is `q';
>>> - the function copying the previous chord only copies the chord pitches,
>>>
ours or more. Again, I can't see that trade-off being
> worth it.
For me, "visual tools" are a setback, actually.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
ces, but without all the complexity of actually writing
> multiple voice constructs.
Why couldn't you write
4 s4*3
or similar?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Marc Hohl writes:
> David Kastrup schrieb:
>> [...]
>> But *4 is _logical_. You can guess what it does without looking it up
>> in the manual.
>>
> No. Since it looks like a multiplication, it treats the number, not
> the notes (at least for me). So < c e
possible with something like
>
>4*8
OTOH, something like
{ 8-. -^ }*2
is not doable with the q approach.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Graham Percival writes:
> On Fri, Nov 13, 2009 at 11:33:55AM +0100, David Kastrup wrote:
>> In fact, I was quite surprised at what 4*4 does currently. Makes
>> no sense to me. Can't imagine what it would be good for.
>
> \time 5/8
> R8*5
>
> I used it
wing out q. But I
have to say that an unadorned / would seem more logical than q.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
dicated in
@var{pedal-list}."
--
1.6.5.1.36.g54298
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
mand macro as well.
Do I overlook something important?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
? rest)
(or (car rest)
- (apply functional-and (cdr rest)))
+ (apply functional-or (cdr rest)))
#f))
(define (functional-and . rest)
--
1.6.5.1.36.g54298
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel
Kieren MacMillan writes:
> Hi David,
>
>> OTOH, something like
>> { 8-. -^ }*2
>> is not doable with the q approach.
>
> Of course it is:
> \repeat unfold 2 { 8-. q-^ }
Well, not exactly a shortcut for
than willing to listen. If
> their proposal includes a relatively minor amount of work from the
> core developers, I'm willing to do it. If the proposal boils down
> to "hey, how about you guys rewrite it in visual basic, while I
> continue to complain about bugs and the lack of a wiki"... then
> they won't get anywhere.
Sure.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reinhold Kainhofer writes:
> Am Sonntag, 15. November 2009 20:16:51 schrieb Nicolas Sceaux:
>> Le 14 nov. 2009 à 09:29, David Kastrup a écrit :
>> > Now the harp-pedal command defines the property signature
>> >
>> > ((size 1.0)
>> > (harp-pedal-
Carl Sorensen writes:
> On 11/14/09 1:29 AM, "David Kastrup" wrote:
>
>>
>>
>> Ok, I am digging through harp-pedals.scm and looking at
>> define-builtin-markup-command.
>>
>> Now from the definition of define-builtin-markup-command it lo
ation. For
readability and efficiency, I'd really prefer replacing
'(apply functional-or' with '(any'
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Carl Sorensen writes:
> On 11/15/09 11:15 PM, "David Kastrup" wrote:
>
>> Carl Sorensen writes:
>>
>>> The property signature is a documentation-only convention. It has
>>> no functionality except for producing documentation.
>>
>
Nicolas Sceaux writes:
> Le 16 nov. 2009 à 20:32, David Kastrup a écrit :
>
>> With very few exceptions (about 2 or 3, one being the harp-pedal
>> code), all the commands appear to use the let-binding mechanism.
>
> Indeed, when I introduced the property binding thing
The already outcommented problematic \harp-pedal-verbose markup is
removed completely. Inlining make-harp-pedal makes it possible to use
the property binding mechanism of define-builtin-markup-command in
order to minimize inconsistencies between documentation and behavior.
---
scm/harp-pedals.scm
---
scm/define-markup-commands.scm |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/scm/define-markup-commands.scm b/scm/define-markup-commands.scm
index 08c24bb..fec895d 100644
--- a/scm/define-markup-commands.scm
+++ b/scm/define-markup-commands.scm
@@ -732,7 +732,6 @@
other 95%. Even then, starting from a consistent state does not
much harm.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Patrick McCarty writes:
> On 2009-11-16, David Kastrup wrote:
>>
>> It still suffers from not doing short-circuit evaluation. For
>> readability and efficiency, I'd really prefer replacing
>> '(apply functional-or' with '(any'
>
>
. And a few other things. No idea just how much
something like Gerrit would help.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
(ly:assoc-get x reedbanks)))
(ly:assoc-get 'reedbanks register
(result (markup #:musicglyph
(ly:assoc-get 'glyph instrument
(if (null? dots) result
(markup-builder (cdr dots)
(markup #:co
resulting chord name output in list form and do something else
with it, resulting in new voices and annotations.
Ideas?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
David Kastrup writes:
> I have no idea what I am doing here. In particular not with the
> \override, and the set-object-property!. Can somebody explain to me
> just what data structures I happen to manipulate, and how a user is
> actually _supposed_ to be mangling them?
We
DOC string can be added on an
as-needed base.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Carl Sorensen writes:
> On 11/21/09 12:55 AM, "David Kastrup" wrote:
>
>> Well, given my apparent discrepance between coding and social
>> interaction skills, the resulting dearth of actually useful advice
>> and other things (recently a patch of mine was re
Carl Sorensen writes:
> On 11/21/09 9:35 AM, "David Kastrup" wrote:
>
>> Carl Sorensen writes:
>>
>>> I would like to suggest that you post patches on Rietveld, rather
>>> than directly to the -devel list. That's the current recommended
Carl Sorensen writes:
> On 11/19/09 5:20 PM, "David Kastrup" wrote:
>
>>
>>
>> I have no idea what I am doing here. In particular not with the
>> \override, and the set-object-property!. Can somebody explain to me
>> just what data struct
Nicolas Sceaux writes:
> Le 21 nov. 2009 à 17:32, David Kastrup a écrit :
>
>> Carl Sorensen writes:
>>
>>> I still don't like the divergence between define-markup-command and
>>> define-internal-markup-command.
>>
>> Agree. I think d
Graham Percival writes:
> On Sat, Nov 21, 2009 at 08:55:20AM +0100, David Kastrup wrote:
>> Well, given my apparent discrepance between coding and social
>> interaction skills, the resulting dearth of actually useful advice and
>> other things (recently a patch of mine was r
Neil Puttock writes:
> 2009/11/21 David Kastrup :
>
>> Yes, but that is no fun since I need _new_ internals local to the staff.
>
> If you're happy just using \markup, then you can add the new property
> to instrument-specific-markup-interface (see
> define-gro
Graham Percival writes:
> You're welcome to write up documentation about the current
> architecture; you're probably one of the top 10 people in the
> world when it comes to knowledge of lilypond architecture.
I very much hope you are wrong. At least yet.
Neil Puttock writes:
> 2009/11/21 David Kastrup :
>
>> Modifying Lilypond, then recompiling and reinstalling. That's not the
>> most hack-friendly way. I am still finding my way around.
>
> You're only modifying .scm files, so there shouldn't be any
>
Reinhold Kainhofer writes:
> Am Sonntag, 22. November 2009 01:17:10 schrieb David Kastrup:
>> Neil Puttock writes:
>> > 2009/11/21 David Kastrup :
>> >> Modifying Lilypond, then recompiling and reinstalling. That's not the
>> >> most hack-
the head).
>
> It's no problem at all, if you do it that way.
Hello merge conflict, my old friend, I've come to talk with you again...
If you have ever worked in a project with a central ChangeLog file, you
know the permanent hassle with switching branches when some changes
require
Nicolas Sceaux writes:
> Le 22 nov. 2009 à 00:00, David Kastrup a écrit :
>>
>>> I'd be insterested to see an implementation of a single
>>> `define-markup-command' for builtin and user defined markups, where
>>> user defined commands d
ou recognize
a problem and have already seen or worked out a solution will help a
lot. If you find problems reoccuring and/or you not being happy with
the solutions suggested so far, you might want to suggest documentation
or code changes on the developer list."
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
y
> lilypond user can learn how to fix bugs.
How about "interested"? It is not quite the same, but I think it has a
more positive ring to it.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
The already outcommented problematic \harp-pedal-verbose markup is
removed completely. Inlining make-harp-pedal makes it possible to use
the property binding mechanism of define-builtin-markup-command in
order to minimize inconsistencies between documentation and behavior.
---
scm/harp-pedals.scm
---
scm/define-markup-commands.scm |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
This patch series makes the syntax of builtin markup
commands upwards compatible with the user level ones.
diff --git a/scm/define-markup-commands.scm b/scm/define-markup-commands.scm
index 449f3c7..0
All markup commands defined with these macros must be adapted to the
new syntax.
---
scm/define-markup-commands.scm | 449
scm/fret-diagrams.scm | 18 +-
scm/harp-pedals.scm|8 +-
scm/tablature.scm |3 +-
4 files
The specification of category and properties makes the *-builtin-*
variants diverge syntactically from the user specified markup. Moving
those specifications into keyword arguments makes the builtin defining
macros upwards compatible with the user specified ones.
---
scm/define-markup-commands.sc
Han-Wen Nienhuys writes:
> On Thu, Nov 19, 2009 at 10:20 PM, David Kastrup wrote:
>>
>> I have no idea what I am doing here. In particular not with the
>> \override, and the set-object-property!. Can somebody explain to me
>> just what data structures I happen to ma
Han-Wen Nienhuys writes:
> On Sat, Nov 21, 2009 at 8:42 PM, David Kastrup wrote:
>>> I'll make one last suggestion, which you are free to ignore.
>>>
>>> I'd suggest a message to -devel and to Han-Wen and Jan, with a simple
>>> subject requesti
Patrick McCarty writes:
> On Tue, Nov 17, 2009 at 11:24 PM, David Kastrup wrote:
>> Patrick McCarty writes:
>>
>>> On 2009-11-16, David Kastrup wrote:
>>>>
>>>> It still suffers from not doing short-circuit evaluation. For
>>>
Han-Wen Nienhuys writes:
> On Sun, Nov 22, 2009 at 4:49 AM, David Kastrup wrote:
>>> It's no problem at all, if you do it that way.
>>
>> Hello merge conflict, my old friend, I've come to talk with you again...
>>
>> If you have ever worked i
Reinhold Kainhofer writes:
> Am Sonntag, 22. November 2009 07:49:04 schrieb David Kastrup:
>> Carl Sorensen writes:
>> > And if you have the source tree in a git repository, then it's trivial to
>> > make branches, and checkout the appropriate branch. That
. Maybe Vincent didn't write this because "ordinaire" in French
> can also mean "vulgar" or "common-as-muck". I'm sure Vincent would
> never dream of writing something like that about is Frogs. . .:-}.
I prefer "interested". Avoids lo
Reinhold Kainhofer writes:
> Am Montag, 23. November 2009 01:03:10 schrieb David Kastrup:
>> ---
>> scm/define-markup-commands.scm |3 +--
>> 1 files changed, 1 insertions(+), 2 deletions(-)
>>
>> This patch series makes the syntax of builtin markup
>&g
doing.
Being cleverer than the platform one is working on is a recipe for
unmaintainability. It will also get in the way of using Scheme
compilers, debuggers and similar tools.
So where do I get to know about the design goals and benefits?
Thanks,
--
David Kastrup
___
Han-Wen Nienhuys writes:
> On Mon, Nov 23, 2009 at 4:02 AM, David Kastrup wrote:
>>>> I have no idea what I am doing here. In particular not with the
>>>> \override, and the set-object-property!. Can somebody explain to me
>>>> just what data structures
Han-Wen Nienhuys writes:
> On Mon, Nov 23, 2009 at 11:56 AM, David Kastrup wrote:
>>
>> Hi,
>>
>> in the course of seeing how much code can be shared between
>> define-builtin-markup-command and define-markup-command, the main
>> difference appears
Han-Wen Nienhuys writes:
> On Mon, Nov 23, 2009 at 1:21 PM, David Kastrup wrote:
>
>>> lilypond a.ly b.ly
>>>
>>> we want to reuse the built-in definitions, without changes effected
>>> in a.ly leaking into the processing of b.ly
>>
>> W
Nicolas Sceaux writes:
> Le 23 nov. 2009 à 01:03, David Kastrup a écrit :
>
>> The specification of category and properties makes the *-builtin-*
>> variants diverge syntactically from the user specified markup. Moving
>> those specifications into keyword arguments ma
didn't read the rest of your message, I got bored meantime.
If you are not interested in the answers, don't ask questions.
Han-Wen already posted "LGTM", and the patches include patches to the
documentation of the changed macro
in the apparently only
acceptable manner with tools that don't work for me and which I have not
the time for to fight as well), but I don't see myself up to defending
them. And there is no point in doing so anyway: the last thing Lilypond
needs is more code that can't
Nicolas Sceaux writes:
> Le 23 nov. 2009 à 19:03, David Kastrup a écrit :
>
>> Han-Wen Nienhuys writes:
>>
>>> On Mon, Nov 23, 2009 at 1:21 PM, David Kastrup wrote:
>>>
>>>>> lilypond a.ly b.ly
>>>>>
>>>>>
ommm again until it helps.
I think I'll try reading the guile manual instead.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Carl Sorensen writes:
> On 11/23/09 2:05 PM, "David Kastrup" wrote:
>
>> Nicolas Sceaux writes:
>>
>>> Le 23 nov. 2009 à 01:03, David Kastrup a écrit :
>>>
>>>> The specification of category and properties makes the *-builtin-*
&
Han-Wen Nienhuys writes:
> On Mon, Nov 23, 2009 at 7:45 PM, David Kastrup wrote:
>> Han-Wen already posted "LGTM", and the patches include patches to the
>> documentation of the changed macros.
>>
>> I don't think that I can contribute much more to you
Joe Neeman writes:
> On Tue, 2009-11-24 at 01:03 +0100, David Kastrup wrote:
>> Carl Sorensen writes:
>> > IIUC, our policy is that *every* patch that is applied should result
>> > in a buildable LilyPond. If not, it's a bad patch.
>>
>> I don'
defined in one included file shall be accessible
> from another included file.
The above approach would give that. I am not saying that it is the best
possible approach.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
David Kastrup writes:
> Nicolas Sceaux writes:
>
>> Please ignore this case, it's broken. What I had in mind a bit more
>> complex, and probably does not really matter.
>>
>> The two important points to keep in mind are:
>>
>> 1) user defined
60048/diff/1/5
> File scm/markup.scm (right):
>
> http://codereview.appspot.com/160048/diff/1/5#newcode74
> scm/markup.scm:74: [ :category category ]
> Does this need to be [ #:category category ] ?
Yes. Sorry.
--
David Kastrup
___
lilypond-d
Han-Wen Nienhuys writes:
> On Mon, Nov 23, 2009 at 1:21 PM, David Kastrup wrote:
>
>>> lilypond a.ly b.ly
>>>
>>> we want to reuse the built-in definitions, without changes effected in
>>> a.ly leaking into the processing of b.ly
>>
>> W
David Kastrup writes:
> Nicolas Sceaux writes:
>
>> I'd be insterested to see an implementation of a single
>> `define-markup-command' for builtin and user defined markups, where
>> user defined commands do not pollute the (lily) module, and still are
>>
Neil Puttock writes:
> 2009/11/24 David Kastrup :
>
>> After applying http://codereview.appspot.com/160048> first,
>> indeed the following diff that throws out all the toplevel scoping
>> constructs and separate definitions of define-markup-command and
>> defi
David Kastrup writes:
> Neil Puttock writes:
>
>> 2009/11/24 David Kastrup :
>>
>>> After applying http://codereview.appspot.com/160048> first,
>>> indeed the following diff that throws out all the toplevel scoping
>>> constructs and separate def
Reinhold Kainhofer writes:
> Am Mittwoch, 25. November 2009 10:02:55 schrieb David Kastrup:
>> It would have helped if the code I threw out had contained any
>> comments as to what problem it tried to fix, and what symptoms were
>> involved.
>
> Yes, that's als
Neil Puttock writes:
> 2009/11/24 David Kastrup :
>
>> After applying http://codereview.appspot.com/160048> first,
>> indeed the following diff that throws out all the toplevel scoping
>> constructs and separate definitions of define-markup-command and
>> defi
John Mandereau writes:
> Le mercredi 25 novembre 2009 à 10:48 +0100, David Kastrup a écrit :
>> Sounds like a dependency impacting developers rather severely.
>
> Are you joking?
I do not know the matter enough to tell funny from serious suggestions.
And "Sounds like...&qu
John Mandereau writes:
> Le mercredi 25 novembre 2009 à 11:41 +0100, David Kastrup a écrit :
[...]
>> Or any configure or error messages or error catching that will give a
>> useful information linking this failure of the test suite with the
>> Texi2HTML version?
[...]
&
Graham Percival writes:
> On Wed, Nov 25, 2009 at 12:08:28PM +0100, David Kastrup wrote:
>> I am talking about "make test" here. I think that catching this error
>> and producing "
>> Texi2HTML call failed, maybe because of a mismatch in required
>>
Han-Wen Nienhuys writes:
> On Wed, Nov 25, 2009 at 8:19 AM, David Kastrup wrote:
>
>> I have my doubts that Lilypond can develop into a sustainable project
>> from the current state of core mind and code. Projects like the frogs
>> are nice for recruiting people, but i
Han-Wen Nienhuys writes:
> On Wed, Nov 25, 2009 at 12:53 PM, David Kastrup wrote:
>> Undocumented code is not maintainable. Throwing it out is a matter of
>> sanity if it can't get documented, and it apparently can't. It
>> apparently can't even get qu
uot;.
> As more and more of these bug-fixing patches get accepted, you'll
> learn more and more about lilypond, and can hopefully write some docs
> to explain what you've learned.
What is in it for me?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Neil Puttock writes:
> 2009/11/24 David Kastrup :
>
>> After applying http://codereview.appspot.com/160048> first,
>> indeed the following diff that throws out all the toplevel scoping
>> constructs and separate definitions of define-markup-command and
>> defi
David Kastrup writes:
> Neil Puttock writes:
>
>> 2009/11/24 David Kastrup :
>>
>>> After applying http://codereview.appspot.com/160048> first,
>>> indeed the following diff that throws out all the toplevel scoping
>>> constructs and separate def
ng
out of time. And maybe he does not know the answers himself, but just
prodded something until it worked.
Things like that happens, probably quite more with commercially
developed software, in particular closed source.
But an opportunity for improving such a state should not be lightly cas
the CG.
But I'd like to see an identical comment in every engraver _linking_ to
the right section in the CG. If reading the code does not tell me the
story, it should at least tell me _where_ I get to read the story
instead of assuming that I have already learnt all documentation by
heart and
aster is not to spend any serious
amount of time on the items of the list itself. Just to add items.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
101 - 200 of 6220 matches
Mail list logo
