lilypond-devel
[Top][All Lists]
Advanced

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

Re: Issue 4083: Implement \tagGroup command (issue 137920043 by address@


From: dak
Subject: Re: Issue 4083: Implement \tagGroup command (issue 137920043 by address@hidden)
Date: Sat, 06 Sep 2014 19:45:40 +0000

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/



reply via email to

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