# Suggestion for improvement: Contextual history of format strings

**URL:** https://community.mp3tag.de/t/suggestion-for-improvement-contextual-history-of-format-strings/59646
**Category:** General Discussion
**Created:** [January 8, 2023, 4:29pm UTC](https://community.mp3tag.de/t/suggestion-for-improvement-contextual-history-of-format-strings/59646 "2023-01-08T16:29:57Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [January 8, 2023, 4:29pm UTC](https://community.mp3tag.de/t/suggestion-for-improvement-contextual-history-of-format-strings/59646/1 "2023-01-08T16:29:57Z")

</div>

With the Tag-\>Tag converter and the actions of the "Format Value" type, a history is saved with the format strings, which is currently only generally displayed in its entirety for all tag fields.

I would find it useful for easier selection of an existing format string if its display of the selection was contextually limited to the currently selected tag field.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [January 8, 2023, 9:02pm UTC](https://community.mp3tag.de/t/suggestion-for-improvement-contextual-history-of-format-strings/59646/2 "2023-01-08T21:02:48Z")

</div>

I see your point ...  
and I really had to think some time whether your idea was so obvious that it is a pity that the function does not already work like it.

And then I remembered this thread:

> [@2 Actions: Append term to Genre unless term already exists and distribute terms to fields if not duplicated](https://community.mp3tag.de/t/2-actions-append-term-to-genre-unless-term-already-exists-and-distribute-terms-to-fields-if-not-duplicated/59614/1):
>
> Hello and Happy New Year!! I have a system where I have custom fields for multiple genres to attach to a song. So I have the regular %genre% along with %genre1%, %genre2%, %genre3% and so on. When I am done tagging I just append all these terms to the %genre% field using "/" as the delimiter. In order to do this, I have created this tag to tag action with the field %genre% formatted by the following string: %genre%$if(%genre1%, / %genre1%,)$if(%genre2%, / %genre2%,)$if(%genre3%, / %genre3%,)$…

The suggested format string to remove duplicates from genre was originally used for a different field.  
And then I rememberd that the suggested filter expression to find the number of genres was originally used to determine the folder depth ...  
So it is not always that the format strings are used only in 1 context.  
Which means that we end up with the unavoidable request for an "option". Or perhaps a different sorting (first those for the current field, then all the others).

---

<div class="post-metadata">

### Author: ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [January 9, 2023, 10:30am UTC](https://community.mp3tag.de/t/suggestion-for-improvement-contextual-history-of-format-strings/59646/3 "2023-01-09T10:30:34Z")

</div>

> [@ohrenkino](#):
>
> So it is not always that the format strings are used only in 1 context.

Right now I can only recall a very few instances where I've used a truly same format string for different tag fields and those were replace actions.

Personally, I would prefer the added convenience of a not endlessly long and more appropriate list to the disadvantage of copying a format string in a few cases.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [January 9, 2023, 12:25pm UTC](https://community.mp3tag.de/t/suggestion-for-improvement-contextual-history-of-format-strings/59646/4 "2023-01-09T12:25:16Z")

</div>

> [@poster](#):
>
> Right now I can only recall a very few instances

I see that also.  
As you described: most times you use the particular expressions for just one field.  
But then it could happen that you look for that one string but you don't remember for which field you used it ... And then it would be nice to see all strings again.  
Or you have such a list of user-defined fields like in the linked thread (genre1, genre2, genre3) and even if you want to apply almost identical functions to each of these fields, you either have to type them in completely or copy&paste them.

So, my fear, only an option to see the filtered or the complete list right next to the string selection would be the only way to make everybody happy.
