2018-01-16 14:37 GMT+01:00 Urs Liska <li...@openlilylib.org>: > But you should also look into the openLilyLib files, create a copy of the > function and try removing the \markup wrapper. This \markup is added > explicitly so it seems more efficient not to do that in the first place > instead of removing it afterwards. >
Indeed, leads to: \version "2.19.65" #(use-modules (ice-9 popen)) #(use-modules (ice-9 rdelim)) #(define (strsystem_internal cmd) (let* ((port (open-input-pipe cmd)) (str (read-delimited "" port))) (close-pipe port) (if (eof-object? str) "" str))) #(define (some-git-info-string cmd) (car (string-split (strsystem_internal (string-append "git " cmd)) #\newline))) \bookOutputName "CommitishExample" \bookOutputSuffix #(some-git-info-string "rev-parse --short HEAD") { c'1 } Btw, I had a look at https://github.com/openlilylib/snippets/blob/master/editorial-tools/git-commands/definitions.ily In the definition of `gitCommand' I read (make-column-markup (first result) ...) While `result' is (string-split ...). If I'm not mistaken, `result' is always a flat list of strings, it's first element always a _single_ string. So I wonder how make-column-markup (expecting a markup-_list_) ever worked here. Also, I have an (likely) older coding of `gitCommand' found on my computer without make-column-markup (and a few other differencies). Cheers, Harm _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user