feat: Add method to map regex patterns to descriptive names

[shunlibest]

Added a getDrawValue method that translates regex patterns (e.g., \b, \d, etc.) into descriptive names (e.g., WordBoundary, Digit). This improves readability and provides a clear mapping for regex special characters.

[The-Lum]

Thanks for this PR.

Here are some open questions...

• Perhaps some peoples preferred the old behaviour... then perhaps adding a parameter to activate/deactivate this functionality
• Then another question will be the localisation (l18n)... It will be perhaps usable to translate the description and create some minimal localisation as on the gant diagram or SVG export, in order to manage some other languages.

There are only open questions...
To exchange on this topic and to plan future PR...

Regards,
Th.

[arnaudroques]

Thank you for the effort and thought put into this PR. The proposal to translate regex patterns into descriptive names is indeed an interesting idea.

That being said, I fully agree with the points raised by Th:

1. Default Behavior
   While the improvement adds value, it’s worth considering whether this should be the default behavior. Regex patterns such as \b and \d are standard and widely recognized among developers working with regex. Altering their display without explicit activation might not align with user expectations.

2. Configuration for Customization
   I believe it’s time to introduce parameters to offer display options for regex. For instance, we could allow users to activate or deactivate the descriptive name feature. A syntax like (?#use descriptive names) could also be a viable option to embed optional directive for regex displays, providing flexibility.

3. Localization (l18n)
   Supporting multiple languages is an excellent idea, especially if this feature is adopted more widely.

I would love to hear everyone's thoughts on these suggestions and how we can collectively plan the next steps for this feature. Thanks again for this valuable contribution, and I appreciate the open discussion.

[shunlibest]

@The-Lum @arnaudroques
Thank you for your kind guidance and follow your advice. I added two options:

1. useDescriptiveNames: true/false. If that is empty, it defaults to false and will not display DescriptiveNames

2. language: i18n support was added to the project for the first time, and I'm not sure if it meets the specification.

Thanks

Here are some running screenshots:

[The-Lum]

Hello @shunlibest, @arnaudroques,

Good enhancement. 👍
Another open questions... 😉

• For 2/
  language <xx> is, for example, conform to Gantt Diagram. ✔️ That is good.

• For 1/
  But for useDescriptiveNames [true|false]

Beware of how to pass parameter to plantuml:
@arnaudroques:

• What is the best practice?
  Between pragma or keyword?
  (cf. !pragma compact on EBNF diagram VS mode compact on Timing diagram)

Open to debate...
Regards,
Th.

[arnaudroques]

Yes, it might be time to standardize all of this.

Regarding !pragma, it's meant to be an internal feature, not necessarily stable over time, so I’d lean towards saying no to using it for this purpose.

What would you think about introducing a new directive at the preprocessor level?

For example:

!option language cn  
!option useDescriptiveNames true  
!option mode compact  

This could lead to something like:

@startregex  
!option language cn  
!option useDescriptiveNames true  

\b\B  
@endregex  

From an implementation standpoint, these !option directives would be handled by the preprocessor. This approach would also allow us to introduce options for the preprocessor itself if needed in the future.

What do you think?

P.S.: A big thank you to @shunlibest for kickstarting the i18n efforts. We’ll likely apply the same principles to Gantt diagrams... The TODO list keeps growing! 😊

[The-Lum]

Hi @arnaudroques,

Yes, it might be time to standardize all of this.

Good things 👍

Then:

What do you think?

That seems good. But [always] a new open question:

• How to localize this option or parameter to a specific scope?
  Especially on a global option file, or a global style file, or a theme... 😉
  (for example: only for Timing diagram and not for EBNF diagram....)

[I know, I'm demanding]

Like for style:

• How to manage locally?
• How to manage globally and for a specific scope?

Regards,
Th.

[arnaudroques]

To keep things simple for now, all options will be global. This means that a directive like:

!option language cn  

would apply to all diagram types (e.g., Gantt, Regex, Timing, etc.) uniformly.

While local or scoped options could certainly be valuable, we'll focus first on establishing a global system. This keeps the implementation straightforward and ensures consistency across all diagrams.

Of course, as the system evolves, we can revisit the idea of scoped configurations.

[The-Lum]

Hi,

That seems good for a first beginning. 👍

Regards,
Th.

[arnaudroques]

@shunlibest, thank you once again for your valuable contribution!

In the latest snapshot, we've made a slight syntax adjustment as shown below:

@startregex
!option language de
!option useDescriptiveNames true

\b\B\d\D\w\W\s\S
@endregex

We'd love to hear your thoughts! Any feedback or suggestions are welcome.

PS: The next step will be to apply a similar approach to Gantt diagrams.

[shunlibest]

@arnaudroques

I have reviewed your PR.I think your changes are wonderful and great. You've refactored a lot of code, which I'm not capable of doing.

This change, establish a unified standard, it is very important.

In the future, more experimental features can be added. More people can participate in plantUML, and plantUML will become more and more powerful.

Finally, for this useDescriptiveNames feature, I think it can be turned on by default after some time.

Thanks.

[The-Lum]

Hello @shunlibest, @arnaudroques

After new analysing...

• Why not to change ebnf to regex more accurate on this side.
  Because even if the code in on the EBNF side the usage is only for REGEX diagram...

• Do you agree with this change?

Regards,
Th.

[The-Lum]

Hello @shunlibest, @arnaudroques

Here are some tests.
That seems good on all cases ✔️

@startregex
!option language de
!option useDescriptiveNames true

\d?\D+\w*\W{1,2}|\s.\S
@endregex

But not on range: ❌

@startregex
!option language de
!option useDescriptiveNames true

\d\w|[\d\w0-9Z](\d|\w|[0-9]|Z)
@endregex

• How to manage this case?
• We must investigate and make a proposal (to allow descriptive names on range)...

Link to #1929

I can also update the doc. with this new feature (of descriptive names on REGEX diagram)...
Regards,
Th.