Han-Wen Nienhuys <hanw...@gmail.com> writes: > On Tue, Dec 13, 2011 at 5:56 PM, Ian Hulin <i...@hulin.org.uk> wrote: > >> I pulled out and tested the examples in separate .ly file and the >> format that fails is >> #(define-markup-command (double-box layout props text) (markup?) >> "Draw a double box around text." >> (interpret-markup layout props >> #{\markup \override #'(box-padding . 0.4) \box >> \override #'(box-padding . 0.6) \box { $text }#})) >> \markup \double-box A > > Since the person writing the code is writing Scheme already, requiring > the inner markups to be in Scheme is a reasonable restriction, IMO.
With that kind of logic, #{ ... #} should be removed altogether. And while we are at it, Scheme macros along with them. Since the person writing the code is writing Scheme already, requiring the inner markups to be in Scheme rather than being actually written by a system of Scheme macros would be quite in the same book. > That said, it would be nice if #{ #} could be made to work, but I not > enough insight into how it works. There does not appear to be any problem apart from "parser" not being defined in the module that Ian switches to. Since other user-defined variables and functions would be similarly afflicted, it would not appear that throwing the functionality of #{ ... #} overboard would solve the underlying problem to a degree where the user won't get to see it anyway as soon as he tries working with variables. > What is the rationale for putting the markups in a separate module? Right question. As an illustration of why I consider your sentence Since the person writing the code is writing Scheme already, requiring the inner markups to be in Scheme is a reasonable restriction, IMO. as not being founded in a reality composed of users with a bell-shaped distribution of skill sets, compare the appended version of a Bach prelude written in the current version of LilyPond (actually, I am cheating here since this will require a patch to parallelMusic that I am going to commit after the doc run finishes successfully) with the version you'll find at <URL:http://nicolas.sceaux.free.fr/prelude/prelude.html>. In both cases, the user is in the situation of "writing Scheme already", and so the "reasonable restriction" of requiring the inner music expressions to be in Scheme would apply. When I first encountered Nicolas' example of Lilypond programming on the Web, I was in awe. This showed a mastery of LilyPond that I considered to be beyond me. Compare this to the rather bland version that I append at the end of this mail. It is just a straightforward assembly of standard LilyPond functionality, and there is nothing frightening about the Scheme code. And actually, if you retrace the systematic approach of Nicolas in a few months from now, you'll find that \displayMusic and its friends will produce quite simpler output, and even doing it in the analytic and Scheme-centric manner that he employed will lead to quite simpler code. Much of my ongoing work will appear as a waste of time to the LilyPond masters like you and Nicolas as one can't do anything one could not do before. And one still needs to use Scheme. But I trust that there will be users who appreciate it. This is _my_ way of advertising LilyPond. And I have a reasonable amount of confidence that it forms an essential part of lowering the barriers of entry in a manner that will raise the absolute number of contributing LilyPond power users while lowering their percentage of the whole user base. Because it will no longer require a power user to do comparatively simple tasks. Yes, one _still_ needs to use Scheme. But not to a frightening degree. GUILE lists LilyPond as one of three long-running success projects of GUILE on <URL:http://www.gnu.org/s/guile/>. And what does GNUCash, one of the other two, has to say about it? See <URL:http://wiki.gnucash.org/wiki/Roadmap#Scheme_minimization> and the next item. I want Scheme to be a _strength_ of LilyPond, not a liability. And that means simple tasks should be simple to do and work in predictable ways. And if you don't notice a qualitative difference in required skills between the above example from Nicolas and the below example from me, I am not worried. Because there _are_ people that will. And their number will only increase over time. Of course, it took Nicolas less time and skills to compose his example than it did me to compose mine. Because most of my actual work on it is not in the example, but in LilyPond. Not likely work that you would find worth paying for. But I am banking on hoi polloi.
\version "2.15.22" \header{ title = "Preludium" opus = "BWV 846" composer = "Johann Sebastian Bach (1685-1750)" } \paper { indent = 5\mm } #(set-global-staff-size 13) ph = #(define-music-function (parser location p1 p2 p3 p4 p5) (ly:pitch? ly:pitch? ly:pitch? ly:pitch? ly:pitch?) #{ \repeat unfold 2 { r8 $p3 16 $p4 $p5 $p3 $p4 $p5 } | \repeat unfold 2 { r16 $p2 8. ~ $p2 4 } | \repeat unfold 2 { $p1 2 } | #}) \parallelMusic #'(high middle low) { \voiceOne | \voiceTwo | \oneVoice | \ph c' e' g' c'' e'' \ph c' d' a' d'' f'' \ph b d' g' d'' f'' \ph c' e' g' c'' e'' \ph c' e' a' e'' a'' \ph c' d' fis' a' d'' \ph b d' g' d'' g'' \ph b c' e' g' c'' \ph a c' e' g' c'' \oneVoice | \change Staff = "down" \voiceOne | \voiceTwo | \ph d a d' fis' c'' \ph g b d' g' b' \ph g bes e' g' cis'' \ph f a d' a' d'' \ph f aes d' f' b' \ph e g c' g' c'' \ph e f a c' f' \ph d f a c' f' \ph g, d g b f' \ph c e g c' e' \ph c g bes c' e' \ph f, f a c' e' \ph fis, c a c' ees' \ph aes, f b c' d' \ph g, f g b d' \ph g, e g c' e' \ph g, d g c' f' \ph g, d g b f' \ph g, ees a c' fis' \ph g, e g c' g' \ph g, d g c' f' \ph g, d g b f' \ph c, c g bes e' } \score { \new PianoStaff << \context Staff = "up" { << \high \\ \middle >> r8 f16 a c' f' c' a c' a f a f d f d r8 g'16 b' d'' f'' d'' b' d'' b' g' b' d' f' e' d' <e' g' c''>1 \bar "|." } \context Staff = "down" { \clef bass \low << { r16 c8. ~ c4 ~ c2 r16 b,8. ~ b,4 ~ b,2 c1 } \\ { c,2 c, c, c, c,1 } >> } >> \midi { \context { \Score \with \settingsFrom { \tempo 4 = 80 } } } \layout { \context { \Staff \with \settingsFrom { \accidentalStyle modern } } } }
-- David Kastrup
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel