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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
