lilypond-devel
[Top][All Lists]
Advanced

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

Re: Document all outside-staff-priority values; neaten table (issue 2805


From: Phil Holmes
Subject: Re: Document all outside-staff-priority values; neaten table (issue 280580043 by address@hidden)
Date: Fri, 1 Jan 2016 16:26:27 -0000

----- Original Message ----- From: "Carl Sorensen" <address@hidden> To: <address@hidden>; <address@hidden>; <address@hidden>
Sent: Friday, January 01, 2016 4:14 PM
Subject: Re: Document all outside-staff-priority values; neaten table (issue 280580043 by address@hidden)




On 1/1/16 5:43 AM, "address@hidden on
behalf of address@hidden"
<address@hidden on behalf of
address@hidden> wrote:

Reviewers: ,

Message:
Please review.

Description:
Follows on from a question on -user.  There aren't that many values of
outside-staff-priority, so it seems easiest to list them all if we're
going to list most.  The adjustments to the column widths get rid of
unnecessary line wrapping.

After much tutoring from Graham, I believe this is the wrong thing to do,
for two reasons.

1) An exhaustive table that is manually, not automatically, generated is a
maintainability nightmare.
2) If an exhaustive table exists, it belongs in the NR, not the LM.

I believe the proper way to respond to the issue is the following:

Definitely right now:
A) In the LM, clarify the sentence on looking up OttavaBracket as follows:
"All we need to do is look up the outside-staff-priority of a TextSpanner
in the IR, and then set the outside-staff-priority of the OttavaBracket to
a slightly smaller value."

Optionally, based on some advanced texinfo magic:
B) Create an appendix in the NR that automatically finds all default
values of outside-staff-priority and creates a table.
C) Refer to this automatically-created table in the LM.

In my opinion, absent the automatically-created table, the right thing is
to strengthen the ability of the user to find the outside-staff-priority
of the relevant objects, not to create a potentially wrong table.

Thanks,

Carl
==============================================

I've been careful not to claim it's an exhaustive list, and following Trevor's comment have put back the pointer to the IR for any that isn't in the list above. I've also made it possible to find in the NR.

It may be that other mechanisms are possible, but it does seem that having a sorted ordered list of those that are currently available is better than having half a list of some of them and making everyone repeat what I had to do to get this list: plough through the IR?


--
Phil Holmes



reply via email to

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