Re: [PATCH 1/2] scm/define-markup-commands.scm: remove some unnecessary lookups

[David Kastrup]

Nicolas Sceaux <address@hidden> 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 do not pollute the (lily) module, and still are
>>> available across file includes.
>> 
>> There is no real necessity: you can perfectly well define different
>> define-markup-command versions for builtin and user defined markups and
>> put them in different namespaces.
>
> Oh, two different macros, doing different things, but with the same
> name, right, now that design seems much better indeed.

Who is talking about "doing different things"?  They are supposed to do
the same thing in the right namespaces.

>> It is not a "little inconvenience" if internals are defined in a
>> different, undocumented way that apparently only a single developer
>> understands and realizes.
>
> This comment would have been valid a few hours before, but it's not
> anymore.

Well, strike "undocumented".  You still have to realize that the problem
with documentation is that you have to find it, whereas the code is
everywhere.

If I try to write user-level code for Lilypond, the natural place for
real-life examples is of course the Lilypond source itself.  If the
source uses different functions and macros from what I can use myself, I
lose one important source of documentation.

I don't see much sense in discussing this further.  I'll try cooking up
a patch, we can have the equivalent of a vote, and we see where we get
from there.  If "somebody would have to do the work" is not an implicit
defense of the status quo, one can focus on technical merits instead.

> Any other /valid/ objections?
>
> You seem to to able to spend a lot of time in endless discussions.
> You're lucky.

If I am not clever enough to get a clue from reading the code, I have to
resort to talking with other people.  Stupidity is not the same as luck.

> That's not my case.  Now I'll be discussing patches. Only.

Which has the disadvantage that I may waste my time on creating patches
that are not applied because they would not survive a discussion due to
reasons only people more knowledgable to myself might tell.

I agree that this particular issue is at "patch appropriate" state and
am working on it.

-- 
David Kastrup