Hello!

Documentation on custom skinning says that

New predefined values are likely to be added in future releases of Fossil.

I suggest three additional TH1 variables for the /doc webpages. The corresponding bundle is also available.

What do you think? Please consider merging into the mainline.

Some comments on the code:

• It seems rid is only valid to use in a query if vid!=0, i.e. not for /doc/ckout/... or /uv/... pages.
• The code should conform to ANSI C-89, i.e. variables should be declared at the beginning of the scope.

Thank you for the observation. Fixed.

Meanwhile I wonder if this is a "security risk", since the information from the rcvfrom table is usually only available to setup users, and maybe administrators?

And, to give readers a better overview of the document history and contributors, linking to the /finfo page may be more useful? (Edit: because the rcvfrom table is completely different for a local clone, for example.)

Yeah. I'm inclined to avoid exposing implementation details like this without a really good reason. I'm also concerned about feature-creep.

The OP has not (yet) made an argument for why these TH3 enhancements are needed or are useful. That needs to happen prior to giving this patch deeper consideration.

I wonder if this is a "security risk"

Fair point. But the information from these variables is consumed by the header/footer of a specifically customized skin (which only the setup user can apply) or by the document itself, if th1-docs setting is switched on (in which case the author of a document should decide).

linking to the /finfo page

I do that already in my custom skin, but this is the different use-case. Consider the need to form a printer-friendly webpage that shows precise version information of the underlying source file.

A capability I would like to see added to embedded documentation is the ability to show the date and time when the document being viewed was last edited. I can think of several ways to do this:

1. This could be accomplished with a new TH1 variable that is recognized by the footer, causing the footer (or the header) to show the "last modified YYYY-MM-DD" message. Perhaps the new TH1 variable is called "document_date" and only exists when showing embedded documentation, so the TH1 code in the header and/or footer would only show the modification date when displaying embedded documentation.

2. Enhance the /doc URL handler to show the last modification date someplace (perhaps associated with the document title somehow) but only if the administrator turns on a setting. Perhaps that setting could be a GLOB pattern list specifying the specific documents to which it applies.

3. Update the convert_href_and_output() routine so that provides an additional $VARIABLE for the last modification date, or perhaps some special markup, like <last-modification-date>.

A similar nice-to-have would be the ability to have a link to the complete edit history of the document.

This could be accomplished with a new TH1 variable that is recognized by the footer

Maybe more than a simple scalar, something closer to stat(2) output, or in this case, to /info or /finfo. That is, a list or hash of data about the artifact being rendered for use in TH1.

Enhance the /doc URL handler to show the last modification date someplace (perhaps associated with the document title somehow) but only if the administrator turns on a setting.

Eh, this feels more like a skinning issue, thus something for TH1, not a checkbox to be enabled. It's akin to the current document rendering time feature.

A similar nice-to-have would be the ability to have a link to the complete edit history of the document.

That should be easy to construct in TH1 already using a /finfo?name= URL, assuming TH1 knows the current document's file name.