Re: Rewrite chordnames - disentangle data from formatting (issue 223420043 by address@hidden)

[Thomas Morley]

2015-04-16 4:55 GMT+02:00 Carl Sorensen <address@hidden>:
> Hi Harm,
>
> On 4/15/15 4:30 PM, "Thomas Morley" <address@hidden> wrote:
>
>>Hi Carl,
>>
>>before going into details, let us decide how to proceed.
>>
>>The current patch was intended to be not more than maintaining the
>>stuff different.
>>First step seemed to me putting the needed data into an alist.
>>
>>2015-04-13 4:22 GMT+02:00  <address@hidden>:
>>
>>> It seems to me that this patch is mostly maintaining the mix of parsing
>>> and display; it's just putting the stuff into a list first.
>>
>>So you are absolutely right.
>>
>>I think you would prefer to dig in deeper, though.
>
> My impression (although I haven't studied it carefully as recently as you
> have, so I might be wrong) is that the current system goes through the
> chord and creates a bunch of markup information that it puts together into
> a markup.
>
> Changing it to put the markup information in an alist seems to still mix
> the markup and the parsing.  The stuff that seems to me should go in the
> alist is structural information about the chord, rather than markup
> information.

You wrote about a chord-analyzer on Rietveld.
Seems I have difficulties to fully understand what you think.

The chord-info-procedure was intended to put out an analysis of the
chord representing it in an alist.

Let's have a look at an example:

\new ChordNames
  \chordmode {
    fis1:m5-.7+.9-.11+.13-/ces
  }

chord-info would return:

(list (list 'root-info
            (cons (quote note-name) "F")
            (list 'alteration-info
                  (cons (quote alteration) 1/2)
                  (cons 'accidental-glyph
                        "accidentals.sharp")))
      (cons (quote chord-prefix-spacer) 0)
      (list 'prefixes
            (list 'minor-chord-modifier
                  simple-markup
                  "m"))
      (list 'chord-name-separator
            hspace-markup
            0.5)
      (list 'main-info
            (list 'major-seven-symbol
                  line-markup
                  (list (markup #:triangle #f))))
      (list 'alterations
            (list (list 'alteration-info
                        (cons (quote alteration) -1/2)
                        (cons 'accidental-glyph
                              "accidentals.flat"))
                  (cons (quote number) "5"))
            (list (list 'alteration-info
                        (cons (quote alteration) -1/2)
                        (cons 'accidental-glyph
                              "accidentals.flat"))
                  (cons (quote number) "9"))
            (list (list 'alteration-info
                        (cons (quote alteration) 1/2)
                        (cons 'accidental-glyph
                              "accidentals.sharp"))
                  (cons (quote number) "11"))
            (list (list 'alteration-info
                        (cons (quote alteration) -1/2)
                        (cons 'accidental-glyph
                              "accidentals.flat"))
                  (cons (quote number) "13")))
      (list (quote suffixes))
      (list (quote addings))
      (list 'bass-info
            (list 'slash-chord-separator
                  simple-markup
                  "/")
            (cons (quote note-name) "C")
            (list 'alteration-info
                  (cons (quote alteration) -1/2)
                  (cons 'accidental-glyph
                        "accidentals.flat"))))

The entries for 'minor-chord-modifier, 'chord-name-separator and a few
others contain markups. If I didn't overlook something they all are
coming from the relevant context-properties.
Those could be called later when putting together the markup.
The entries for 'accidental-glyph could be found later as well.

Is that like you'd prefer?

What about the 'note-name for root and bass?
Thea are simple strings.

>
> So for me, the alist you are creating doesn't even really pave the way for
> the kind of separation I envision.
>>>
>>>
>>>https://codereview.appspot.com/223420043/diff/20001/scm/chord-ignatzek-na
>>>mes.scm#newcode395
>>> scm/chord-ignatzek-names.scm:395: ;;;; Step 2: Define formatter for the
>>> chord-elements using this list
>>> I'm not sure how this separation between step 1 and step 2 really
>>> accomplishes the stated goal of the patch.  Can you give an example of
>>> how this makes it easier to define a new display style for a chord?
>>
>>This patch doesn't pretend to provide a user-interface for it.
>
> I wasn't asking for a user interface.  I was more just asking for a
> logical sketch of how it would work.
>
>
>
>>Already possible is the following, though.
>
>
> I couldn't make the following code work.  I don't have chord-info, or
> format-alterations, or any of the other format-*.  Are you proposing this
> as a potential way to work with the things in your patch, and that
> chord-info would result from a call to ChordNamer?  Or am I totally
> missing things here?

Sorry not making myself clear enough.
I shouldn't post anything if I'm exhausted (I was already told that
I'm hard to understand then.)

That code only works with my patch applied.

>
> And I have no desire to stand in the way of your patch, if it's moving
> things forward in a way that you have found useful.

I really hope I didn't offend you in any way!
Your input is very helpful and highly apreciated!

>
> Thanks,
>
> Carl
>

Thanks,
  Harm