Added support for custom tags in template input with regex conversion

[sumana-2705]

Description

What is this PR

• Bug fix
• Addition of a new feature
• Other

Why is this PR needed?
This PR adds support for custom tags in template inputs following the first suggested option in the issue (#351), allowing users to define and use predefined placeholders (<ANY_DIGIT>, <ANY_STRING> and ANY_CHAR) that automatically convert into corresponding regex patterns. This improves flexibility when defining naming conventions.

What does this PR do?

• Implements a convert_custom_tags_to_regex function to replace custom tags with regex patterns.
• Integrates this function into set_name_templates to ensure correct transformation of input values.
• Ensured that users can enter name templates in regex format without encountering any errors.

References

closes #351

How has this PR been tested?

Tested Locally

CustomTagsToRegex.mp4

Is this a breaking change?

No

Does this PR require an update to the documentation?

Yes, documentation need to be updated when this addition works fine.

Checklist:

• The code has been tested locally
• Tests have been added to cover all new functionality
• The documentation has been updated to reflect any changes
• The code has been formatted with pre-commit

[sumana-2705]

Hello @JoeZiminski,

I have a small doubt can you please help me. I encountered an error when setting the template validation to sub-.*, as shown in the attached image. Based on the documentation, .* should allow any sequence of characters, so I wanted to check if I might be making a mistake in the implementation. Based on the observed behavior, I wanted to clarify whether this restriction is intentional (allowing only integers) and the documentation needs an update, or if this is a bug.

If it is indeed a bug, I’d be happy to address it in this PR itself. Looking forward to your guidance on this!

[adamltyson]

Hi @sumana-2705, just FYI @JoeZiminski is away, so it may be some time until someone can get back to you.

[sumana-2705]

Hi @sumana-2705, just FYI @JoeZiminski is away, so it may be some time until someone can get back to you.

Yeah, no problem @adamltyson! I’m aware that @JoeZiminski is currently away. I just opened the PR so that he can review the implementation when he returns. Thank you for your time! 😊

[JoeZiminski]

(main comments below)

[JoeZiminski]

I think this function can be moved for format.py

[JoeZiminski]

Hi @sumana-2705 thanks for this! This is really good, a clean implementation and intuitive for users. I'm trying to think if any small improvements can be made (e.g. a tag less verbose than <ANY_STRING>) or we had discussed previously a widget in which could be clicked to insert the placeholder into the input. But I think the former would come at the expense of clarity and the latter would clutter the interface too much. @adamltyson what do you think?

For merging, this would require update to docs and tests. Feel free to work on the tests, this would be something simple just to check the conversion is happening as desired, from stored name templates. Because this is happening at the level of the python API it is not necessary to explicitly test the TUI.

Good question, in this case the error is a bit subtle. The problem is that the names must be made of key-value pairs separated by underscores, and keys cannot be integer. So for the name sub-21-23 it is treating the key as sub and the value as 21-23 which cannot be converted to integer.

[adamltyson]

But I think the former would come at the expense of clarity and the latter would clutter the interface too much. @adamltyson what do you think?

I think I agree. We can't just add loads of buttons for every possible option.

[sumana-2705]

Thanks for your review @JoeZiminski I will work on it.