Re: [GLISS] - alternative viewpoint

[Janek Warchoł]

Hi,

i'm sorry for the delay :-(  There are so many emails flying around
that i find it hard to keep up.
Don't feel obliged to reply to any "i don't understand" part - i have
so many emails to write that some of my questions may remain
unanswered.

On Sun, Sep 16, 2012 at 6:02 PM, David Kastrup <address@hidden> wrote:
> Janek Warchoł <address@hidden> writes:
>
>> On Sat, Sep 15, 2012 at 10:20 AM, David Kastrup <address@hidden> wrote:
>>> b) our C++ engravers announce to the type system (and via that, to the
>>> documentation) which context properties they read, modify and write.
>>> There is no reason that this does not also include the Grob descriptions
>>> which are even now a special case of context property.
>>
>> I didn't understand this part well, but it guess it's not that
>> important to have me understand it now (?).
>
> Take a look in the internals manual.  It knows which engravers access
> which context properties.

Hmm.  I thought that i will see chordNameLowercaseMinor listed under
Chord name engraver
(http://lilypond.org/doc/v2.17/Documentation/internals-big-page#chord_005fname_005fengraver),
but i don't.

> A Grob is actually just a (substructured)
> context property,

That's surprising to me.

> so it can be documented in the same manner.

agreed.

>> (i write this just to provide you with feedback on the difficulty of
>> some of your emails)
>
> This is the developer list, after all.

In my opinion the difference between user and developer list should be
mostly in topics discussed, not necessarily in the difficulty of the
emails.
Granted, some things are impossible to make really easy, though.

>> So,
>>   \override BarNumber #'font-size = 5
>> would actually result in
>>   \override Score.BarNumber #'font-size = 5
>> ?
>
> Yes, that's the idea.  As long as you have no engraver at Staff level
> looking at the BarNumber properties.  Maybe it would be more robust to
> explicitly declare the default context for writing each property.  After
> all, that is a one-time job.

Maybe.

> Or declare an engraver "canonical" for some properties, so that if
> _that_ engraver is moved, the default context moves along.  At the
> current point of time, an engraver declares which properties it
> reads/modifies/writes (why do we need all three?), and we might let it
> declare which it "owns" with respect to the default context.

I don't have any opinion here, sorry.

>>> Of course, this is not without drawback either: if there are multiple
>>> engravers looking at that property at multiple levels and you are
>>> interested in overriding the behavior of the engraver in an outer
>>> level, the unspecific override will be done in the inner level and
>>> again not have an apparent effect.
>>
>> I think i won't understand this w/o an example.
>
> Write an engraver at Staff level which looks at currentBarNumber, and
> \override currentBarNumber will just work at Staff level instead of
> Score level.

Ah, ok.  Thanks.

>>> One might argue that users who are able to write to a mailing list
>>> after looking for it in the manual make up for less than 1% of our
>>> targeted demographic group, users who come to LilyPond not primarily
>>> since they enjoy being in total control over the data structures
>>> their typesetting program uses.
>>>
>>> And particularly for those it makes a big selling point if naive
>>> expectations disregarding the technical necessities and
>>> implementation constraints happen to hit the mark semi-regularly.  Of
>>> course, we can't make that 100%, but 80% is a lot more encouraging
>>> than 2%.  If you get everything wrong at first try, that's a big
>>> turnoff.  Even if some smart helpful guy explains to you why
>>> everything is wrong.
>>
>> If i understand correctly, you mean that we don't have many emails
>> from people being confused by pre/postfix issues because these people
>> never make it to the mailing list (i.e. they are too discouraged by
>> their first Lily try that they quit immediately)?  I think you're
>> right.  *We* may never notice that some change simplified things
>> (because we're already used to Lily), but newcomers will.
>
> I think that if your first five attempts to do something on your own all
> end catastrophically, you'll just quit again.

I don't understand why you wrote "again" here.

>>>     a) reflection.  Should \displayLilyMusic recognize expressions that
>>>     can be produced by a wrapper and output them?  If we answer "yes" to
>>>     that question, it would make sense to provide some infrastructure
>>>     for specifying appropriate reverse engineering rules to LilyPond in
>>>     a manner that is not significantly more complex to specify than the
>>>     wrapper itself.
>>
>> I don't understand what you mean here.
>
> \displayLilyMusic \once\erase Accidental
>
> might choose to display \once\erase Accidental instead of
>
> \once\override Accidental #'stencil = ##f
>
> But for that there must be an easy way to teach \displayLilyMusic about
> \erase.

Ah, i think i understand now.  Therefore, my answer to the question
"Should \displayLilyMusic recognize expressions that can be produced
by a wrapper and output them?" is: that would be nice, but i don't
think it's necessary.

>>>     b) When and how are third-party tools supposed to learn about such
>>>     wrappers when they are supposed to be part of LilyPond?
>>
>> ditto.
>
> If we extend that language, how will Scorio, NoteEdit, Laborejo etc etc
> learn about this?

I understand the question, but i don't understand why you ask it.
With every new syntax these external tools have to be updated, it
seems to me that this is how it's like.

>>>     c) MusicXML?
>>
>> ditto.
>
> If we have a convenience macro translating a construct that is
> representable in MusicXML (overrides in general are not), how can we
> teach our MusicXML exporter to recognize and export it?

If we have something representable in MusicXML, i still don't
understand why would it matter whether it's wrapped in a convenience
macro or not.

>>> Now one might argue that this currently is rather a discussion on
>>> meta-bikeshedding, namely getting something right that will serve as
>>> a template for future bikeshedding, but it is quite clear that with
>>> convenience wrappers, everybody actually _can_ contribute his opinion
>>> without requiring much expertise.  And it makes some sense as well
>>> since we are, after all, trying to hit the sweet spot of naive
>>> expectations.
>>
>> I don't understand what you mean.
>
> You did not even quote the URL of the discussion I referred to, so I
> suppose that you are just missing the context.

Probably.  Sorry, i don't know when i'll have time to read it.

>> You mean that we should fix the "general structure" first, and then
>> everyone (i.e. beginners too) will be able to add syntactic sugar like
>> autoBeamOff = \set autoBeaming = ##f ?
>
> I don't know what you mean with "fix" here.  Most of the work I do puts
> wheels on LilyPond's syntax, making it easy for the user to go where he
> wants it to.  However, I tend to stay compatible, and I don't start on
> extensive new definitions myself.  So I am basically creating potential
> for easily extending and/or redefining LilyPond, but that does not, in
> itself, extends or changes the normal vocabulary significantly.

Well, that's roughly what i meant by "fix".

cheers,
Janek