Re: tagGroup question

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Simon Albrecht <simon.albrecht@mail.de> writes:
>
>> Dear list,
>>
>> I have encountered some unexpected behaviour with tags and
>> tagGroups. In the following example, I thought the two staffs should
>> look the same, even without the \removeWithTag command, but they
>> don’t:
>>
>> %%%%%%%%%%%%%%%%%%%%%%%%
>> \version "2.23.5"
>> % tested with 2.23.5 (guile2-build) and 2.22.0
>>
>> \tagGroup sol,mi
>> \tagGroup withCClefs,noCClefs
>>
>> \keepWithTag mi,noCClefs
>> %\removeWithTag withCClefs
>> <<
>>   {
>>     \tag mi,withCClefs \clef alto
>>     1
>>     \tag mi,noCClefs \clef bass
>>     1
>>   }
>>   {
>>     \tag withCClefs \clef alto
>>     1
>>     \tag noCClefs \clef bass
>>     1
>>   }
>>>>
>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>
>>
>> How come the other tagGroup interferes? Is this a bug?
>
> ‘\keepWithTag’ [music] - TAGS (symbol list or symbol) MUSIC (music)
>      Include only elements of MUSIC that are tagged with one of the tags
>      in TAGS.  TAGS may be either a single symbol or a list of symbols.
>
>      Each tag may be declared as a member of at most one tag group
>      (defined with ‘\tagGroup’).  If none of a MUSIC element’s tags
>      share a tag group with one of the specified TAGS, the element is
>      retained.
>
> Essentially, \keepWithTag #'a \keepWithTag #'b is not the same as
> the more inclusive \keepWithTag #'(a b) even when a and b are from
> different tag groups.  That is in line with this documentation that is
> close to the implementation.  Whether this is in line with sensible
> expectations of what \tagGroup should achieve, I am not sure.
>
> I do think that I have at times described the effect of \tagGroup as
> making \keepWithTag #'(a b) equivalent to
> \keepWithTag #'a \keepWithTag #'b when a and b belong to different tag
> groups: that would point to even my expectations being more in line with
> yours than with what the implementation does.

Interesting: in the original issue in the bug tracker, the proposed
commit message is a lot more verbose than what ended up eventually in
the repository:

    Issue 4083: Implement \tagGroup command

    After mulling this over and figuring out that declaring a \tagGroup
    will not just keep \keepWithTag of some package unaffected by any tags
    otherwise in use but will _also_ hide the use of tags internal to the
    package from any outside use of \keepWithTag, I decided to go forward
    on this approach.

    The given implementation does "nothing special" for \keepWithTag and
    \removeWithTag when given tags from different tag groups, or when
    defining the same tag group several times (possibly by loading some
    code twice).  It is arguable that either could warrant a warning.
    However, the functionality of \keepWithTag #'(fromgroupI fromgroupII)
    cannot easily be provided by anything else.
    While I currently cannot imagine a useful application for it myself,
    the implemented behavior is logically consistent.

    Also contains:
    Basic documentation for \tagGroup command


That would imply that I was very much aware at the time of writing this
of the implications.  The question is whether

    However, the functionality of \keepWithTag #'(fromgroupI fromgroupII)
    cannot easily be provided by anything else.
    While I currently cannot imagine a useful application for it myself,
    the implemented behavior is logically consistent.

really keeps options open that anybody would use, making this behavior
(that cannot be achieved in reasonably simple other ways) desirable.

Problem is that few uses of \keepWithTag #'(fromgroupI fromgroupII) are
likely to intentionally invoke that behavior.  Indeed, in my most recent
score under work I find

  \keepWithTag layout,pizz %pause %,dingding

With layout and pizz being in different tag groups and the intent being
exactly to be equivalent to \keepWithTag layout \keepWithTag pizz .

So the question is whether retaining this subtle feature (not otherwise
available) is worth its price when not even the author of it is able to
remember how it applies in case anyone would ever need it.

-- 
David Kastrup