Re: Issue 4154: Compact Chord Symbols Patch (issue 153160043 by address@hidden)

[Richard Shann]

On Sat, 2014-10-18 at 17:19 +0000, address@hidden wrote:
> On 2014/10/09 12:02:16, richard_rshann.plus.com wrote:
> 
> > Well, that depends what I meant by the existing code - the specific
> file
> > I was modifying calls chordRootNamer which is initialized to
> > note-name->markup which is in chord-names.scm:62, and that is where
> the
> > quoted construct exists in the current lilypond code, in fact I see it
> > is repeated several times in that file.
> 
> Well, pulling code from a different file and functionality in parts into
> a different file where they are basically integrated as flat code into
> some parts of the code while other parts still call the other file --
> that's a total maintenance and reading nightmare.  If the duplicated
> code needs changes or maintenance, it is quite improbable that someone
> working on it will find and change *both* copies as needed.
as I say, it is not a question of "both", the construct is quite short
and is repeated several times. But, of course, it makes it worse to
repeat it in a different file. And more to the point, a different (if
more direct) mechanism is used for compact symbols than for the other
cases.
> 
> It would be best to extend the code to be able to do both tasks.  If
> that is not reasonably possible, it would be good to factor out common
> elements but keep the code doing the non-common parts in the same file.
> 
> https://codereview.appspot.com/153160043/

The problem with doing the compact symbols in the same file as the
others is that there seems to be no access to the context property that
gives the scaling needed. I asked about this on the mailing list,
        http://lists.gnu.org/archive/html/lilypond-user/2014-09/msg00525.html

 but it seemed this couldn't be done. It is completely unclear to me why
the creation of markup for a chord symbol is spread over several files
in the first place - it seems to result in the loss of the context
information at the point where the root name markup is being created.

Is there a way in which chordRootNamer can take an extra scale argument,
or is there, indeed a way to access this value as the context property
chordCompactScale ? If so, I could easily move that code back in to
chord-names.scm

Richard