On Wed, 2015-05-06 at 06:55 +0200, Éloi Rivard wrote: > [...] > > > I thinked a bit, and that sounds very weird to me. My believe is that > scripts languages should be there to handle features for very ad-hoc > cases. One persons ad-hoc case is another's daily use. Music typesetting is a vast territory most of which is of no interest to any one user, but only a little is of interest to a large number of users. There are an enormous number of programs for creating music notation that have set off hard-coding everything that anyone wanted and ended up dead in the water.
> But coding new features with a script language, without having any > control on it with the native language, well I think it is a very > strange design. If think I encounter difficulties with my importer > because a lot of things needs to be done with scheme, they don't *have* to be done in scheme, there are underlying primitives to create Denemo Directives from C, but it would be a nightmare to use them. > and paradoxally it lacks some "scriptability". well, that would be a paradox if it were true. But, of course, it isn't, as you can modify and fill-out any missing features in any script, without asking the developers to create a new binary for you. > > For example the OpenFirstTimeBar command works well, but what if I > want to open the second time barline, or the third, or the first and > second, or the Xth ? You invoke the command OpenNthTimeBar with suitable parameters. Looking at the script it would seem that it hasn't been scripted to take an arbitrary text (only to get one interactively), but it could be - something like (d-OpenNthTimeBar "(list (cons 'text \"3rd time\"))) then the script would process the params as it does the data field in the case where an Nth time bar is being edited. (That would be the elegant solution, a dirty method would be simply to make the script expect some nth time text as a parameter following some ad hoc prescription, but the use of alists for parameters to scripts is something that I'm doing with all new scripted commands). > Currently for instance, how to parse every objects in the score to > create an exporter for instance, since there are a lot that are > lilypond directives inserted with some scheme code ? To create an Exporter you would look at the tag of the lilypond directive and decide what it is for - such an exporter would be best written in Scheme as a script as it would be easier to maintain consistency between the scripts on the use of the tags. Of course, people are entitled to write any LilyPond syntax they wish into a Denemo file, and there is no way that an exporter could be written that would be able to interpret what consequence that bit of syntax has for the music and then to find constructs in the output language to express it. Really, though, the bottom line is that there is no-one writing new hard-coded primitives in C for Denemo, the lack of a good api would make it soul-destroying to try. All we would end up is a bug-ridden program that no-one could fix. But there are people writing little Scheme scripts that do useful tasks, even starting with no experience of Scheme. Richard _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
