lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add scheme engraver for StaffTab notation


From: David Kastrup
Subject: Re: [PATCH] Add scheme engraver for StaffTab notation
Date: Wed, 25 Feb 2015 11:25:41 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Werner LEMBERG <address@hidden> writes:

>>> that simplifies
>>>
>>>   \makeDefaultStringTuning #'guitar-tuning \stringTuning <e, a, d g b e'>
>>>
>>> to the much more readable
>>>
>>>   \T "guitar" <e, a, d g b e'>
>>
>> You can write
>>
>> \makeDefaultStringTuning guitar-tuning \stringTuning <e, a, d g b e'>
>>
>> already.  \T is not "more readable" but merely shorter.
>
> Well, `merely shorter' in this is case *is* `more readable' to me.
>
>> It would be possible to redefine \makeDefaultStringTuning to
>> _optionally_ allow
>>
>> \makeDefaultStringTuning guitar-tuning <e, a, d g b e'>
>>
>> as well.
>
> Ah, this would help a bit.
>
>> I don't believe in "increasing readability" by renaming symbols into
>> stuff that is not the same in definition and usage.
>
> OK.  What about this?
>
>   #(for-each
>     (lambda (elem)
>       (let* ((sym (car elem))
>              (chord (cdr elem)))
>         (ly:parser-include-string
>            parser
>            (string-append "\\makeDefaultStringTuning " sym "-tuning"
>                           " \\stringTuning <" chord ">"))))
>
>       '(("guitar" . "e, a, d b g e'")
>         ("guitar-seven-string" . "b,, e, a, d b g e'")
>         ("guitar-drop-d" . "d, a, d g b e'")
>         ("guitar-drop-c-tuning" . "c, g, c f a d'")
>          ...
>         )
>    )

Disagree.  The current solution has a constant visual pattern (just that
it does not use whitespace for that).  It's not significantly less
readable on a pure visual basis (one might want to block-align the
tuning names).  However, your version is utterly incomprehensible on the
basis of understanding what it does while the original version has each
line stand for itself, with a readily readable _meaning_ of the line.

All that ly:parser-include-string is actually on a level of code
ugliness even below using primitive-eval because it pieces together
stuff that is not even at a syntactical level.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]