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

[David Kastrup]

Nicolas Sceaux <address@hidden> writes:

> Le 21 nov. 2009 à 17:32, David Kastrup a écrit :
>
>> Carl Sorensen <address@hidden> writes:
>> 
>>> I still don't like the divergence between define-markup-command and
>>> define-internal-markup-command.
>> 
>> Agree.  I think define-internal-markup-command makes for more readable
>> code.  If we can consider define-internal-markup-command to be used
>> _only_ in the distributed Lilypond tree, we can change its behavior any
>> way we like.
>> 
>>> Perhaps we should move towards required the default properties list
>>> for all defined markup commands.
>> 
>> My personal preference would be to phase out all *-internal-* commands
>> completely.  One way to do this would be a keyword based approach,
>> something like
>
> I explained why there are two commands, whereas there used to be a
> single one in the past. It's not only because of documentation
> generation. They actually do different things: look at
> ly/markup-init.ly and scm/markup.scm

Uh, I did.

> 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.

A unified syntax would mean you could painlessly transport definitions
from one realm to the other.  The syntax need not necessarily be parsed
by the same define-markup-command.

> If you can come up with one, fine, I'm not opposed to #:property or
> #:category keywords. But if that's not possible, then please stop with
> this macro unification debate. IMHO it's just waisting time, for this
> is not a problem that you're trying to solve, but at most a little
> inconvenience.

It is not a "little inconvenience" if internals are defined in a
different, undocumented way that apparently only a single developer
understands and realizes.  Every artificial boundary between
user-written and lilypond core code makes it harder to move work between
the two.

> PS: *please*, call things by there name, it's "builtin", not
> "internal".

Wouldn't it be worth it alone to do this change because of not having to
get annoyed time and again by me confusing the two?

I'll see whether I can cook up a suitable patch.

-- 
David Kastrup