Hello David,
thanks for your reply and opinion.
It helped me to think a little bit deeper about the problem.
Am 04.01.26 um 00:21 schrieb David Kastrup:
People often are confused, that the \keepWithTag filter leaves the
content with its tag.
Adding another command will not change the confusion.
Jep, that is probably right.
Why would it be difficult to use? The whole point of \tagGroup is to
support independent tag schemes.
That's right. My problem is, that the tag-groups are global
and could not be modified after creation.
There is already an issue discussing the addition of tags to an existing group:
https://gitlab.com/lilypond/lilypond/-/issues/6702
My use case is, that I generate a song book with pure lilypond.
Every song has its own lilypond file, is included in the song book
and results in a bookpart of the final book.
It would be cool to use \tagGroup for different purposes inside
the lilypond song files, but if a tag is defined in one of the files
it could not be in another tag-group in another file, because
after the inclusion in the song book there would be an error:
"conflicting tag group"
One simple solution, that I have tested just now, is to call something
like #(hash-clear! tag-groups) after every bookpart inclusion.
(I had to make tag-groups public to get this to work).
So my use case would totaly work, if we just provide a
\clearTagGroups command (and take care of the internal tag-groups)
or provide some other things to modify existing tag-groups.
Another idea could be to specify the scope of tag-groups (book, bookpart,
score, ...)
but that sounds more complicated to me.
I want to introduce another idea that came to my mind.
We could have an \untag command that just removes the tags, but keep
the content.
In our example we could write
fooMusic = \untag \keepWithTag #'foo \music
barMusic = \untag \keepWithTag #'bar \music
fooMusic is now the same as { c } and the tag used for filtering is gone.
If we do
\score {
\keepWithTag #'one \test
}
it works as expected and leaves the { c }.
"as expected" if you understand the problem in the first place. But why
else would you be using \untag ? And this absolutely does _not_ work
with independent tag schemes because once you have used \untag, you can
no longer apply either \keepWithTag or \removeWithTag from a different
scheme.
I think \untag only makes sense after filtering. I don't have other use cases
in mind.
You could express:
"The filtering of this music snippet is done and I don't want other
modifications here
on tags at a later processing."
Even if you understand the problem in the first place there is no way to reach
this atm.
But yes, all use cases I can think of could also be build with tag-groups.
Does this make sense to you?
I don't see it being of much help, to be honest. It doesn't allow for
multiple independent tag schemes. It will cause tag-based commands to
stop working on tagged music because of independent code removing tags.
That will lead to users not understanding why their tagged music is not
being operated on as expected when it actually stopped being tagged
because of unrelated code.
I don't think users will have a problem, because the use of \untag is an
active decision. If you don't use it, everything works like now.
If you use it, you maybe have a use case and should not wonder about removed
tags.
