Re: Make define-builtin-markup{,-list}-command #:category #:properties keywords (issue160048)

[dak]

Thanks for looking this over.  This patch set is sort of a moving target
due to the removal of markup-init.ly.  For example, recently
documentation about the module related definitions in markup-init.ly has
been added to the programmer's documentation.  If removing
markup-init.ly can be done successfully, this documentation could go as
well.

Unfortunately I still have no feedback about whether the last iteration
of dealing with the "memory leak" situation has been successful for
those who could see the problems.

If that could be corroborrated, investing the time for tracelessly
removing markup-init.ly would be a happier task.


http://codereview.appspot.com/160048/diff/4008/6002
File ly/markup-init.ly (left):

http://codereview.appspot.com/160048/diff/4008/6002#oldcode5
ly/markup-init.ly:5: %%;; to be define later, in a closure
On 2009/12/03 14:58:38, nicolas.sceaux wrote:
> If this file is empty, then it shall be deleted

Agreed.

http://codereview.appspot.com/160048/diff/4008/6007
File scm/markup.scm (right):

http://codereview.appspot.com/160048/diff/4008/6007#newcode101
scm/markup.scm:101: (set! body (cddr body)))
On 2009/12/03 14:58:38, nicolas.sceaux wrote:
> Why is this needed?
> Could #:allow-other-keys take care of that?

defmacro*, in spirit with Common Lisp's keyword arguments, does not
remove keywords from the "rest" argument.  Which is rather stupid, but
not in our hands.  This loop just throws any keyword/value pairs from
the start of the body away without actually looking at them.

This is feasible exactly because #:allow-other-keys has _not_ been set,
so we are sure that all keyword/value pairs we throw away have already
been legitimately parsed.

Do you want a code comment here?  Proposal for the wording?

http://codereview.appspot.com/160048/diff/4008/6007#newcode131
scm/markup.scm:131: ;; Register the new function, for markup
documentation
On 2009/12/03 14:58:38, nicolas.sceaux wrote:
> I still have the feeling that user defined commands should not modify
variables
> from (lily) module.
> Could there be e.g. a module check, so that the macro expand into the
> documentation related settings only for builtin commands?

I think it would be more transparent if the documentation selection was
turned off completely by default, and a documentation generating run
explicitly turned it on.

If a user wants to make a small manual for his private markups, being
not allowed to do so because of not being in the lily module would be a
nuisance.  As would be having all lily markups in this manual.

A reasonably easy interface would be to use hashq-set! only
when the respective entity happens to be a hashtable, or even anything
other than #f.

I have not yet done anything in that respect since I have no idea yet
where to properly place the code turning on/off the documentation
collection.

http://codereview.appspot.com/160048/diff/4008/6007#newcode168
scm/markup.scm:168: (set! body (cddr body)))
On 2009/12/03 14:58:38, nicolas.sceaux wrote:
> Same as above.

See above.

http://codereview.appspot.com/160048/diff/4008/6007#newcode199
scm/markup.scm:199: (hashq-set! markup-list-functions ,command-name #t)
On 2009/12/03 14:58:38, nicolas.sceaux wrote:
> Same as for define-markup-command

See above.

http://codereview.appspot.com/160048