On Tuesday 07 November 2006 12:22, Han-Wen Nienhuys wrote: > Erik Sandberg escreveu: > > On Monday 06 November 2006 17:02, Han-Wen Nienhuys wrote: > >> Erik Sandberg escreveu: > >>>>> I think this will be an improvement, because we remove the concept of > >>>>> aliases, which confuses users (at least it confuses me a bit); in > >>>>> addition we don't need to do anything extra to softcode aliases. > >>>> > >>>> I don't understand. How will this work in practice? Ie. if I do > >>>> > >>>> \set Timing.measurePosition = #.. > >>>> > >>>> how will it be processed? > >>> > >>> We will have to change that to an \applyContext which finds/creates a > >>> context with the 'timing property set, something like > >>> \findContextWithPredicate #'timing \set measurePosition = #... > >> > >> I still don't understand why you want to scrap it. > > > > The main reason is to have one event less in the stream API (if we will > > keep the current alias mechanism, I will have to create an add-alias > > stream event). IWBN to keep that API minimal, and to me it seems that > > aliases aren't much used anyways. > > > > However, you have a very point that functions like \applyoutput will get > > more complicated if we want to keep full backward compatibility. > > I wouldn't say that they are not used often. Every \override and \set > would start use \findContextWithPredicate. Eg. > RhythmicStaff/RhythmicVoice has a \context Staff / \context Voice > alias. That doesn't strike me as a tight API.
Good point. \set Foo.bar where Foo as an alias is a syntactical luxury which it's unnecessary to kill. Unrelated to this, it's problematic that staff names are used as aliases: When you do \set Staff.foo=..., it may happen that you don't want to set foo if we are in a RhythmicStaff, this is difficult to achieve if RhythmicStaff has a Staff alias. IMHO, it would be nicer if context names were never used as aliases. However, aliases are not much used in the back-end; so we could still do the API minimisation (i.e., move aliases to context_handle, and make sure all alias calculations happen on the iteration side). The only problematic part I found in the back-end was the autoAccidentals list, which begins with a context alias. I don't understand that mechanism; is there a reason why we don't let the user decide which rules to apply where, by setting autoAccidentals to different values in different contexts? > Is it necessary to solve this problem now? No, I just wanted to take the discussion early. -- Erik _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
