On 24 déc. 2012, at 15:55, David Nalesnik <david.nales...@gmail.com> wrote:
> On Mon, Dec 24, 2012 at 7:22 AM, m...@mikesolomon.org > <m...@mikesolomon.org> wrote: >> On 24 déc. 2012, at 10:36, d...@gnu.org wrote: >> >> On 2012/12/24 07:28:17, mike7 wrote: >> >> On 24 déc. 2012, at 01:10, mailto:d...@gnu.org 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel