Re: Autobeaming

[Joe Neeman]

On Tue, 2009-12-29 at 11:27 -0700, Carl Sorensen wrote:
> 
> 
> On 12/29/09 8:41 AM, "Carl Sorensen" <address@hidden> wrote:
> 
> > 
> > 
> > 
> > 
> > On 12/29/09 4:48 AM, "Trevor Daniels" <address@hidden> wrote:
> > 
> >> Hi Carl
> >> 
> >> This looks like a much better approach.  It means the
> >> special \overrideTimeSignatureSettings will be required
> >> only rarely, and setting autoBeamRules for just the
> >> current time signature should have a much simpler
> >> format as the time signature is known - is that right?
> > 
> > Sort of.
> > 
> > I wouldn't recommend setting autoBeamRules for the current time signature,
> > because that setting will disappear if the time signature changes.
> > 
> > I think that proper way to get new autoBeamRules is to override the
> > timeSignatureSettings.
> > 
> > But if one wants to avoid that complication, one can just set autoBeamRules
> > for the current time signature.
> > 
> 
> I think I've got a consistent idea now.  I think I can add a property
> (probably 'details to avoid namespace pollution, but maybe
> timeSignatureDefaults) to the TimeSignature grob.

I much prefer leaving it as a context property. Grob properties of the
TimeSignature grob should be things that affect the appearance of the
TimeSignature grob, not the creation of beams.

If you were to use a context property, why would you need the special
command \overrideTimeSignatureSettings to change it? That is, why
couldn't people just use \set? If it helps, we could extend \set to
allow nested properties (the same thing that
http://codereview.appspot.com/182042/show does for paper-block
variables).

Joe