Re: [Lilypond-auto] Issue 2503 in lilypond: Patch: Move add-grob-definition from a snippet to scm/translation-functions.scm

[lilypond]

Comment #8 on issue 2503 by address@hidden: Patch: Move add-grob-definition  
from a snippet to scm/translation-functions.scm
https://code.google.com/p/lilypond/issues/detail?id=2503

all-grob-descriptions is partly no longer a problem since it has been  
defined using define-session-public and consequently is restored at the end  
of session.  I'd refrain from sorting the list, however: just adding at the  
front seems to be sufficient and will not require copying substantial  
amounts of the data.

The current code destructively modifies its input (see the various  
assoc-set!) which tends to be given as constants in code.  That's bad but  
fixable and I seem to remember that our original code does something  
similar (and may for that reason bomb out with GUILEv2 eventually).

What is however a problem is the use of set-object-property! here.  That is  
not getting reverted at the end of the current session.  Whether or not  
some object property (and consequently the identification of a grob, in  
conflict to what may be in all-grob-descriptions) disappears at the end of  
the session depends on whether the grob name is incidentally used as a  
symbol anywhere in our code base.  If it is, symbol identity will survive  
across sessions, and that lets the object properties survive as well.

That's probably fixable as well nowadays by recording all grobs added in a  
session (and making sure that they don't collide with existing grobs) and  
then clearing out all of those recorded object properties at the session  
end by registering a hook with `call-after-session' for that.

That's easily butt-ugly, in particular since actually removing object  
properties seems to be only possible by using set-object-properties! on the  
whole object property alist.

It would be nicer to migrate away from the use of object properties here  
and move to an actual API for checking and setting those properties (such  
that one can move to a different implementation eventually).  But that's a  
different task.

What is involved for this issue if it is to be tackled independently is to  
clean the effects at the end of each session.  That was the original  
showblocker.  However, the tools for fixing that, even without changing the  
rather ugly organization internals, are available by now.

However, the add-grob-definition interface also is more a hook into  
internals than a proper user interface.  Just adding -public to some  
internal function does not turn it into a user interface: that kind of  
definition is not likely to be remembered easily, and it is not likely to  
remain supported across reorganizations of the code and/or internals.   
Particularly the organization with "meta" is bleeding internals all over.

So one should figure out just what are the salient elements going into a  
grob definition, how to organize them best when a user wants to specify  
them, and then putting the definition together should be the task of the  
function.

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings