It seems to me that a submenu of a /rptview page lacks a hyperlink to either /ticket or /reportlist page (or maybe both, if they differ). Does somebody feels the same? Is somebody againsts? Maybe add one? If so how to name it (them)? For the sake of screen space saving (think mobile) what about fancy unicode symbols: ⚹ ⚙ ☰ ★ ?

It seems to me that a submenu of a /rptview page lacks a hyperlink to either /ticket or /reportlist page (or maybe both, if they differ).

It should definitely get a link to /reportlist, but /ticket is a search page, so that link should probably only appear if search indexing is enabled.

what about fancy unicode symbols: ⚹ ⚙ ☰ ★ ?

🤷

It's been my (admittedly limited) experience that some seemingly common symbols don't work in one browser or another or may be missing only on a given platform. i recall recently missing some on FF on Raspberry Pi OS and missing others in Chromium.

It comes down to Unicode versions and font support.

Symbols and emoji that have been in Unicode for many versions should appear on any reasonably up-to-date GUI.

You can’t count on any particular presentation, but the meaning should come through.

An excellent resource for all of this is Emojipedia, run by one of the voting members on the standards committee.

Please take a look at this check-in.
A concept of SubMenu's Parametric Link may find utility at other pages too.

Does somebody see any security flaw there?

Does somebody see any security flaw there?

What were the problems with %h and %T? Too many layers of encoding?

IIRC (but might be wrong), the QUERY_STRING value is provided URL-encoded by the web server? If so, using %h or %T on it would be the wrong thing to do (but might work for single-parameter query strings).

Today i learned that fossil has a function named fossil_no_strange_characters(). But... this project is full of strange characters ;)!

problems with %h and %T? Too many layers of encoding?

Yes.

... this project is full of strange characters ;)!

Hmm... a partial fix is just around the corner :)

Apart from the above, I'm curious if it makes any sense to keep the second parameter ("nMaxDigit") of the introduced style_submenu_parametric() function. The sole purpose of this parameter is to reduce the amount of invocations of cgi_parameter() function. But it seems that it is a useless micro-optimization because cgi_parameter() is well optimized and the time of 10 or 20 subsequent invocations can be easily ignored compared with the overall time of handling /rptview or /wiki (or pretty any other) page requests.
Am I right? If so then I'll remove this parameter.

Am I right? If so then I'll remove this parameter.

After reading through it i'm still unclear exactly what that parameter is for and where the magic values for it in the various links come from.

But it seems that it is a useless micro-optimization because ...

As a rule of thumb, any type of small computation like that will be absolutely swamped by the db-related overhead, to the point where a difference between 1 call or 100 will likely not be measurable without running it through valgrind and measuring instructions (as opposed to execution time).