On 2014/09/06 18:55:42, Keith wrote:
The behavior of the old patch seemed better, in the case where someone
does
combine a \keepWithTags A.C with A and C from different groups. In
that case,
the user knows about both tag-groups and might be thinking of them as
a unified
group, and expect that command to keep music tagged \tag#'A \tag#'Q,
regardless
of the group membership of Q.
The rule "\keepWithTag will keep music if any tag matches" has existed
in the
past. That is, these two examples, similar to a pair you put in the
tracker,
\keepWithTag A.B \tag B.C \new Staff c'^\markup"AB_BC" \keepWithTag A.B \tag B { \tag C \new Staff c'^\markup"AB_B_C" } are treated differently in current master.
I disagree here. Point #1 to note is that symmetric behavior makes stuff easier to explain and understand. With the currently proposed implementation, like with the previous implementation which you argue for, exchanging the tags on the \keepWithTag command with those on the music itself does not change whether a match occurs. Now an essential feature of tag groups is that uses of different tag groups is supposed to be orthogonal. That means that operations based on tags will not be affected in any manner when adding tags from a different tag group. That is, \tag A { \tag B { ... } } should not in any manner behave differently from \tag A \tag B { ... } whenever A and B are from different tag groups with regard to whether or not ... will get *removed*, because removing one will effectively remove the other and vice versa either way. But _if_ we stipulate a symmetric relation between tags in \keepWithTags and on some music, that means that \keepWithTag '(A B) (with A and B in different tag groups) should also keep music only if either A or B matches. Now as opposed to the tags on music (which can be delivered by separate commands), tags from different tag groups will not creep into the same \keepWithTag command accidentally. So there is no similarly strong argument against implementing a different behavior here. However, it would come at the cost of sacrificing symmetry in the relation between \keepWithTags command and multiple tags on music. Since with the new behavior, \keepWithTag A \keepWithTag B is identical to \keepWithTag A.B when tags A and B are in different tag groups, the previous behavior offered _more_ functionality. I just don't see that it offered _relevant_ additional functionality that would offset the loss of symmetry and/or the independency of tags from different tag groups. Feel free to convince me otherwise with an appropriate use case.
The old patch allowed a description that lets us understand the basics
without
understanding tagGroups. \keepWithTag will keep music if any tag matches, removing music with unmatching tags, but ignoring tags in a different tagGroup from any of the tags to
keep. But "if any tag matches" becomes very tricky to explain when one needs to implement a behavior where \tag A { \tag B ... is supposed to be equivalent to \tag A \tag B ... while \keepWithTag A \keepWithTag B is different from \keepWithTag A.B even when A and B are in different tag groups. What do you want to sacrifice? The equivalence of \tag A \tag B ... with \tag A { \tag B ... when A and B are from different tag groups, or the equivalence of "\keepWithTag tag list matches music tag list" with "music tag list matches \keepWithTag tag list"? You don't get to keep both. https://codereview.appspot.com/137920043/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel