Nicolas Sceaux <nicolas.sce...@gmail.com> writes: > Le 21 nov. 2009 à 17:32, David Kastrup a écrit : > >> Carl Sorensen <c_soren...@byu.edu> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
