Hi David,
On 13/12/11 22:40, David Kastrup wrote:
> Ian Hulin <i...@hulin.org.uk> writes:
>
>> Hi all, ..snip..
>
>
>> I'd like to deprecate this as I think it's nasty, smelly, evil
>> and kludgy
>
> Care to explain why being able to use the same syntax as one uses
> in the main document is nasty, smelly, evil and kludgy? Should we
> disallow \markup syntax in the main document as well?
>
What is nasty is going back and forth between Lily and Scheme parsing
unnecessarily.
>> #(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 }#}))
^^^
The $text above LilyPond called from within Scheme called from within
LilyPond referencing a variable declared in the Scheme layer. I'm not
criticising the #{...#} stuff in itself, especially after you've been
working hard to clean this stuff up, but *here* it's adding another
layer of complexity to access the Scheme text variable.
Also the editorial thrust of the narrative in /extending/ seems to be
to use the Scheme macros.
>> and ask that users use
>>
>> interpret-markup ( markup #:markup-command 'par ... ) instead.
>>
>> We'd mark this as such in NEWS, meanwhile taking out the
>> offending examples from /extending/.
>>
>> WDYT?
>
> I think that there is nothing much out of the ordinary happening
> when the above command is being run, so it is quite likely that
> we'll get the same kind of breakage in other situations.
>
> If I call
>
> lilypond scheme-sandbox and enter (let ((text "xxx")) #{ \markup
> \override #'(box-padding . 0.4) \box \override #'(box-padding .
> 0.6) \box { $text }#})
>
> I get (#<procedure line-markup (layout props args)> ((#<procedure
> override-markup (layout props new-prop arg)> (box-padding . 0.4)
> (#<procedure box-markup (layout props arg)> (#<procedure
> override-markup (layout props new-prop arg)> (box-padding . 0.6)
> (#<procedure box-markup (layout props arg)> "xxx"))))))
>
> as result which is perfectly reasonable and does not expose the
> user to non-Lilypond syntax, let alone macro expansion.
>
> Since you are the resident expert on Guile v2, it would be nice if
> you explained just what in Guile v2 happens to turn this into
> something nasty, smelly, evil and kludgy.
>
You called me an expert, I didn't. I'm just a stubborn sucker that
would like to see LilyPond working with a supported version of Guile.
In order to get the markup stuff to compile or be interpreted
correctly with Guile V2, I had to get the procedures validating the
markup commands to look in a single module at the list where they were
held. So I chose the base (lily) module. To keep it consistent, I got
the define-markup-command and define-markup-list-command macros to
push and pop the current Scheme module by doing
(let (prevmod (current-module))
(existing declaration)
...
(existing declaration))
(set-current-module (resolve-module '(lily)))
(existing code)
( ... )
(set-current-module (prevmod))
> It is _exactly_ what the parser will deliver for this particular
> markup also in the main document, so if it breaks in #{ ... #}, it
> very likely also breaks in the main document. Should we only be
> allowed to specify markups in Scheme macro syntax in future?
>
The implication in the way /extending/ is written is that using the
macros is preferable in (define-markup-command) and
(define-markup-list-command).
What breaks is #{...#} within a #(define-markup-command ...) with the
patch. I get this scheme traceback:
Validated markup command: line
Validated markup command: draw-lineBacktrace:
In /home/ian/src/lilypond/build/out/share/lilypond/current/scm/lily.scm:
872: 10* [ly:parse-file "../programming-interface-test.ly"]
In /home/ian/src/lilypond/build/out/share/lilypond/current/ly/init.ly:
48: 11* (let* ((book-handler #)) (cond (# #) (# #)))
51: 12 (cond (# #) (# #))
In
/home/ian/src/lilypond/build/out/share/lilypond/current/scm/lily-library.scm:
...
213: 13 [ly:book-process #<Book> #< Output_def> ...]
In unknown file:
?: 14* [ly:optimal-breaking #<Paper_book>]
?: 15* [interpret-markup-list #< Output_def> ((# # # ...)) ...]
In
/home/ian/src/lilypond/build/out/share/lilypond/current/scm/markup-facility-defs.scm:
569: 16* (let* ((stencils #)) (for-each (lambda # #) markup-list) ...)
570: 17* [for-each #<procedure {#f} (m)> ((#<procedure
double-box-markup #> "A"))]
In unknown file:
?: 18* [#<procedure {#f} (m)> (#<procedure double-box-markup #> "A")]
In
/home/ian/src/lilypond/build/out/share/lilypond/current/scm/markup-facility-defs.scm:
571: 19* (set! stencils (if (markup-command-list? m) (append! #
stencils) ...))
572: 20* (if (markup-command-list? m) (append! (reverse! #) stencils)
...)
575: 21 [cons ...
575: 22* [interpret-markup #< Output_def> ((# # # ...)) ...]
566: 23 [ly:text-interface::interpret-markup #< Output_def> ((# # #
...)) ...]
In unknown file:
?: 24* [double-box-markup #< Output_def> ((# # # # ...)) "A"]
?: 25* (let* () (interpret-markup layout props ...))
In
/home/ian/src/lilypond/build/out/share/lilypond/current/scm/../programming-interface-test.ly:
8: 26 [interpret-markup #< Output_def> ((# # # # ...)) ...
9: 27* [embedded-lilypond {#f} ...]
In
/home/ian/src/lilypond/build/out/share/lilypond/current/scm/parser-ly-from-scheme.scm:
67: 28 (let* (# #) (if # #) result)
67: 29* [ly:parser-clone {#f} ((97 . #<procedure {#f} ()>))]
/home/ian/src/lilypond/build/out/share/lilypond/current/scm/parser-ly-from-scheme.scm:67:21:
In procedure ly:parser-clone in expression (ly:parser-clone parser
closures):
/home/ian/src/lilypond/build/out/share/lilypond/current/scm/parser-ly-from-scheme.scm:67:21:
Wrong type argument in position 1 (expecting Lily_parser): #f
Why would temporarily changing the current module upset the LilyPond
parser?
I accept that it's best if I can fettle this patch so that we don't
need to deprecate anything.
Cheers,
Ian
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
