Re: [Patch] Bugfix (Was: Re: Still missing some ancient clefs)

[Juergen Reuter]

On Thu, 29 Aug 2002, Han-Wen Nienhuys wrote:

> address@hidden writes:
>
> > +    (if (string-match "vaticana*|hufnagel*|medicaea*" style)
> > +   (cons (symbol->string style) "ancient")
> > +   (cons (string-append (number->string (max 0 duration))
> > +                        (symbol->string style))
> > +         "music")))))
>
> Do I understand correctly that this patch does a regex match for every
> note head in the default setting?

No, last year, you explained that you want the default style be set to
'default' rather than leaving it undefined (I think to avoid various
crashes, IIRC).  Consequently, this is exactly, what is currently done in
scm/grob-description.scm:

    (NoteHead
     . (
        (style . default)

As a result, the regex match only occurs, if it neither set to 'default',
nor to one of any explicitly defined style other than the
vatican/medicaea/hufnagel ones.  Hence, it will not slow down the default
case.

> Can you make a shortcut so the
> default case doesn't require the regexp; a regexp search might be
> pretty cheap (my machine takes can do 10000 in one second), but I
> still think it's overkill for a not-so-often case.  Also, the default
> style should be called '()

Hmmh.  That does not seem to work.  If I say

        \property Staff.NoteHead \set #'style = #'()

then I get lots of

Programming error: Infinity or NaN encountered,
programming error: Adding reverse spring! Setting to unit spring
(Continuing; cross thumbs),
programming error: Tie is nowhere horizontal (Continuing; cross thumbs),
and
programming error: Infinity or NaN encountered while converting Real
number; setting to zero. (Continuing; cross thumbs),

regardless if I put my patch to find-notehead-symbol in or not; i.e.
obviously there exists some other code in lily that also depends on this
thing to be set to 'default'.

> (i.e.: undefined), and not 'default ;

See above.

BTW., this bug is yet another symptom of the font-family problem.  We
*really* should do something about it, or it will hunt us forever!  I
think your recent suggestion to implement a virtual font with more than
256 characters points into the right direction (and comes effectively
close to what I vaguely suggested half a year ago).

Greetings,
Juergen