The 2020-10-09 prerelease snapshot of Fossil contains 459 check-ins from 2.12. Most releases occurs with between 400 and 500 check-ins. The change log for 2.13 does not have that many bullet points relative to prior releases, however the points that it does have are significant. Furthermore, development velocity has slowed significantly relative to a few weeks ago.

So, I think that we should call the 2020-10-09 snapshot a release candidate and push out the 2.13 release in a few days if there are no serious issues.

Please reply with objections or concerns to this proposal.

This might be a good point to introduce the suggestion from Dan Shearer that each release get a nickname - something befitting the fossil/fossilized theme.

Have you seen these? Are they problematic?

fossil clean follow symlinks. bug? Bug report, unexpected tilde non-replacement

When was Stephan's line number copy feature added?

I think "Reintroduced the legacy wysiwyg" could be added to the changelog.

Maybe something like "various documentation and bug fixes" can be mentioned as well.

When was Stephan's line number copy feature added?

IIRC, without having checked the timeline, it was shortly after 2.12.

I think "Reintroduced the legacy wysiwyg" could be added to the changelog

Kinda. It's there, but activating it requires a "back door" approach via a skin edit, as opposed to a simple button press. My preference would be to not emphasize its availability, as it's not really a feature anyone has stepped up to maintain. i re-added it only because one (and only one) of our long-time users expressed some woe at its demise.

it was shortly after 2.12.

Yep, that's right. The branch you created was line-number-selection.

Can this be added to the changes.wiki?

My preference would be to not emphasize its availability

Works for me. I was just skimming the timeline and noticed it was added back in.

Can this be added to the changes.wiki?

Sure. It's not really a new feature, though, just a reformulation of an old one. i'm off of the computer until Saturday sometime but will get that added and will rename the wysiwyg file so that its extreme length doesn't force the /dir view into only 2 columns (that was something you noticed a couple/few weeks ago).

just a reformulation of an old one.

I agree, but it's a nice enhancement and some folks may not be aware of it without skimming the changes.wiki page, or what their OS package manager may list as changes.

i'm off of the computer until Saturday sometime

Good enough! I bet the new puppy is keeping you busy.

the /dir view into only 2 columns

Ah, that's right. I had forgotten about that. Thank you.

1. I suggest to reserve Y card for digital signatures.
   Ubiquitous artifact signing might be a very useful feature. For a time being we do not have a solid proposal for that. So let Fossil 2.13 just recognize and ignore Y cards.

2. Could you please revert this check-in? I believe it makes whistory page inconvenient.
   A time ago I suggested a small improvement which (unfortunately) was not mainlined. I still maintain a branch (because I need this feature).

3. More predefined TH1 variables would be nice.
   The $CURRENT variable is nice but does not fill the gap (both check-in's and document's hashes are unavailable within the header/footer of a custom skin). Therefore another "out-of-tree" branch.

Could you please consider adding to the pikchrshow help page that text files can be dragged and dropped into the input area? It's not self explanatory by viewing the page.

Perhaps some text could be added to the verbiage that's also present on pikchrshow as well.

Could you please consider adding to the pikchrshow help page that text files can be dragged and dropped into the input area? It's not self explanatory by viewing the page.

That's in one of the "?" help buttons.

Yes, it's mentioned in the auto preview section, which was not my first guess.

edit...Since the drag/drop feature is mentioned in pikchrshow, does that mean it can't/shouldn't be mentioned in the help page?

https://fossil-scm.org/fossil/help?cmd=/pikchrshow

Maybe handle *.pic files in the same way as *.md and *.wiki files are handled (i.e. return a rendered image/svg)?

Maybe handle *.pic files...

If we're going to do that, i would prefer to see the extension be .pikchr, to avoid any potential breakage with hypothetically existing pic files and to be unambiguous about the dialect of pic supported.

That said, do we really expect, outside of pikchr's own repo, standalone pikchr files to be something people commonly check in to repositories? They're generally going to be embedded in other docs.

Yes, .pikchr might be better.
Regarding the future of standalone .pikchr files - hard to predict. Perhaps it can help with deduplication, server's load (via caching) and (maybe one day) syntax highlighting. Not at all urgent though.

i would prefer to see the extension be .pikchr,

Yes: ".pic" is taken, four times over. Of those, one was common enough that a lot of programs will still associate themselves with that file format (GRASP) and another is quite common in the high-end VFX world (Houdini). Thus chances are non-negligible that a given Fossil user will run into a conflict.

Besides which, Pikchr isn't PIC.

They're generally going to be embedded in other docs.

Hopefully we'll get a feature in Fossil that lets them be stored in a separate file and then included into the output document in an SVG-like fashion to get around an unfortunate duplication in is own docs necessitated by converting one of the SVG diagrams to Pikchr.

Test out *.pikchr file rendering on the SQLite Documentation source repository:

• https://www.sqlite.org/docsrc/dir/art/syntax?ci=trunk
• https://www.sqlite.org/docsrc/file/art/syntax/select-stmt.pikchr?ci=trunk

(Edit) Now also:

• https://pikchr.org/home/dir/tests?ci=trunk

Nice. Is there a way to fetch just a rendered SVG image? Like for plain image files.

https://pikchr.org/home/raw?... provides underline .pikchr file.
https://pikchr.org/home/doc/... provides the whole web-page (with header/footer).

UPDATE: Richard, this is absolutely astonishing to see all these pikchrs! Couple months ago I would hardly believe that it's feasable.

Click on the "Text" option in the submenu.

I don't think that's what George meant. I've created a new branch to show what I assumed this feature would allow, namely references to *.pikchr docs from Markdown files with image links either of the form:

    ![some image alt text](./diagram.pikchr)

…or…

    ![alt text](/raw?ci=tip&filename=diagram.pikchr)

I'd prefer the former, but I'd settle for the latter.

When you do the first, you get text/html page back. For the latter, text/x-pikchr. We need a way to get image/svg+xml instead, without the HTML page wrapper.

With this done, the rebase doc will refer to the fourth diagram only once, as an external image, rather than have its Pikchr code duplicated in both places where the same diagram is needed.

On reflection, /raw just isn't going to work. It's right to return text/x-pikchr rather than SVG.

I should also point out that /file and /artifact aren't what I want because those are difficult to use with embedded docs.

Really what I want is for URLs with a /doc element to render SVG, not raw Pikchr text or HTML.

Let /info continue to do what it currently does with Pikchr files; that's fine.

That is a fundamental change in the operation of ![](file). As currently implemented (and perhaps as defined by common-mark, though I will have to check on that) the ![](file construct passes the task of requesting and reading the file content back to the requesting web-browser. The change you describe would mean that Fossil itself would need to read the referenced link and insert its own interpretation instead. This is a very different behavior, and one that I do not think is necessarily a good idea. If you use the same Pikchr image twice in one document, I think you should simply duplicate the code for the Pikchr image. If you repeat the same paragraph, you have to repeat the text of that paragraph. Why should a diagram be any different? If you begin inserting interpreted Pikchr in place of ![](file) references, then shouldn't you also do the same if the referenced file is Markdown or Wiki or HTML or plain text or any other format that Fossil interprets and renders? This seems like a rabbit whole that we do not want to enter.

Please allow

CREATE VIEW IF NOT EXISTS fx_tktview AS SELECT ... ;

at the bottom of "Ticket Table Schema" setup page.
Currently Fossil drops HTTP connection and complains with

warning: SQLITE_AUTH(23): not authorized in "CREATE VIEW IF NOT EXISTS fx_tktview AS SELECT ...

This would significantly simplify SQL-code of the advanced reports (where GENERATED COLUMNS don't help much).

UPDATE: previous discussion on the topic.

The patch against the current tip is rather trivial:

--- src/tkt.c
+++ src/tkt.c
@@ -407,10 +407,21 @@
       }
       if( sqlite3_strnicmp(z1,"ticket",6)!=0 ){
         goto ticket_schema_error;
       }
       break;
+    }
+    case SQLITE_CREATE_VIEW: {
+      if( sqlite3_stricmp(z2,"main")!=0
+       && sqlite3_stricmp(z2,"repository")!=0
+      ){
+        goto ticket_schema_error;
+      }
+      if( sqlite3_strnicmp(z0,"fx_",3)!=0 ){
+        goto ticket_schema_error;
+      }
+      break;
     }
     case SQLITE_INSERT:
     case SQLITE_UPDATE:
     case SQLITE_DELETE: {
       if( sqlite3_stricmp(z2,"main")!=0

The patch against the current tip is rather trivial:

Your tip was a few hours too old ;)

https://fossil-scm.org/fossil/info/93c45cd4e04a59c6

Great! Thanks a lot!
Although UPDATE and DELETE against fx_ tables makes me worry. What if fossil config pull ticket is issued against a malicious/hacked repository? Currently it is hard to inspect what exactly is being pulled (and applied).

Although UPDATE and DELETE against fx_ tables makes me worry. What if fossil config pull ticket is issued against a malicious/hacked repository?

If you're customizing your ticket configuration, chances seem very close to 100% that you are also an administrator for the remote repository. If you're not customizing fossil then the odds seem very close to zero that you care about any fx_ tables, as that prefix is reserved for client-side custom tables. Fossil has no capabilities to say, "tables starting with fx_foo_ are allowed here and fx_bar_ are allowed over there, and the ticket system can update tables fx_baz_ but not fx_barre_."

Thus if you're adding custom tables which are not part of the ticket system, and you're concerned that someone might nuke them via a compromised ticket configuration... there's really not much we can do about that, in terms of partial protection of some fx tables. The hypothetical attacker would have to know the names of your tables in order to attack them. If those names happen to collide with legitimate custom fx names used by that repository's ticketing system, it's a case of plain bad luck, solvable only via longer/more unique table names.

That's not to say that this isn't at least a hypothetical concern, but to me it seems a case of, "it's not a problem until it is."

Aside from yourself and Andreas K., i've yet to hear of anyone using fx tables.

Please allow to DROP user-defined views, tables and indices.
Something like the following:

--- src/tkt.c
+++ src/tkt.c
@@ -403,10 +403,12 @@
   const char *z1,
   const char *z2,
   const char *z3
 ){
   switch( eCode ){
+    case SQLITE_DROP_VIEW:
+    case SQLITE_DROP_TABLE:
     case SQLITE_CREATE_VIEW:
     case SQLITE_CREATE_TABLE: {
       if( sqlite3_stricmp(z2,"main")!=0
        && sqlite3_stricmp(z2,"repository")!=0
       ){
@@ -417,10 +419,11 @@
       ){
         goto ticket_schema_error;
       }
       break;
     }
+    case SQLITE_DROP_INDEX:
     case SQLITE_CREATE_INDEX: {
       if( sqlite3_stricmp(z2,"main")!=0
        && sqlite3_stricmp(z2,"repository")!=0
       ){
         goto ticket_schema_error;

I think it might be useful to add "Restored ability to exclude SCRIPT_NAME from displayed URL when using CGI" -- or something to that effect -- to the bullet list.

I wasn't able to have Fossil serve ://example.com with <2.13. The URL had to be ://example.com/${script_name}.cgi.

Looking through the forums, it looks like I'm not the only one who had this issue with 2.11-2.12.1. To me, that's a significant drawback that's been resolved.

There is another prerelease snapshot for version 2.13 up on the download page. If there are no objections, this version will become the official 2.13 release within a day or two.

Version 2.13 seems like a landmark release.

It may be worth mentioning the enhancements to /finfo pages in the changelog.