Re: New \untag command

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.