Re: Allows for easier creation of many Lilypond objects via Scheme. (issue 7009047)

[address@hidden]

On 24 déc. 2012, at 15:55, David Nalesnik <address@hidden> wrote:

> On Mon, Dec 24, 2012 at 7:22 AM, address@hidden
> <address@hidden> wrote:
>> On 24 déc. 2012, at 10:36, address@hidden wrote:
>> 
>> On 2012/12/24 07:28:17, mike7 wrote:
>> 
>> On 24 déc. 2012, at 01:10, mailto:address@hidden wrote:
>> 
>> 
>>> All of this is absolutely devastatingly horrible code that is not
>>> reconcilable with sane per-session semantics and tampers with
>> 
>> LilyPond
>> 
>>> internals in a way that has bleed-over effects into future files in
>> 
>> the
>> 
>>> same command line.
>>> 
>>> In addition, the interfaces into the exposed internals are
>> 
>> absolutely
>> 
>>> horrific and cryptic and don't make any sense as a user interface.
>>> 
>> 
>> 
>> I agree that the innards I'm exposing are not coded particularly
>> well
>> 
>> 
>> You don't get the point.  A user interface is not supposed to "expose
>> innards", it is supposed to provide functionality.  Pulling data
>> structures and some of the code accessing them into the open is not a
>> user interface.
>> 
>> 
>> I am certainly not saying that this type of task is for every user, but
>> someone comfortable enough to do this should not have to copy and paste from
>> define-*.scm every time.
>> 
>>> This is taking everything that is broken with
>>> input/regression/scheme-text-spanner.ly, magnifies it to a number of
>>> other cases, and gives it a bad interface.
>> 
>> 
>> 
>> I am of the opinion that it is better to have stuff like this that
>> allows people to do creative and interesting things with LilyPond
>> than not have it at all.
>> 
>> 
>> But those "creative and interesting things" will break frequently on
>> update.  We already have quite a bit of "why doesn't this stuff I
>> based on [some version of] scheme-text-spanner.ly not work in my
>> version of LilyPond?" questions.
>> 
>> 
>> It seems like you'd rather not make something accessible rather than making
>> it accessible in a fragile state.  I certainly prefer the latter, as it
>> allows more people to experiment.  For example, David's work on the frame
>> engraver would be a great trial ground for this sort of thing.
>> 
> 
> I've gotten a lot of use out of techniques in
> scheme-text-spanner.ly--that's probably very evident--and I'm quite
> appreciative that it's there.  I understand the problems that it
> causes--I've seen evidence of bleed-over.  However, I'm using these
> techniques as a convenient aid to developing new features.  I could
> certainly work directly in LilyDev and alter the necessary files in
> the proper way, but then I'm unable to get feedback from those users
> who would actively use the new features but aren't comfortable
> applying patches.

[responding to Werner too] I completely see where you're coming from - this is 
how I've gone about work with a lot of features.  This is why I think the idea 
of a git branch, while good for development, is not necessarily possible for 
the average user to access.

> You can see just how much user feedback I got
> during the creation of the measure counter (issue 2445).  As far as
> the frame engraver goes, I've gotten a good sense of what such a thing
> ought to do, and corrected several problems based on input from
> lilypond-user.  My efforts here are still quite a way from producing a
> formal patch and putting it up for review, but that is the end goal.

I'm positive you'll get there.  The frame patch, when submitted, should be able 
to use in-house grob-creation and event-creation mechanisms instead of copying 
and pasting out of Scheme files.  My goal with the present patch is to get 
LilyPond to a state where you and others can do this.  Any feedback on how to 
control the bleed-over mechanisms that you, Mark and David K. have identified 
would be very helpful.

Cheers,
MS