Thanks for taking the time to implement this prototype, and for putting up an alternative Fossil repo to demostrate it!

This is not a rejection of your idea, merely an exploration of alternatives: Have you considered trying to show the Wiki history in the timeline format so that the display is consistent with other history displays in Fossil?

... show the Wiki history in the timeline format ...

No, I did not consider that. It seems to me that it would require more invasive code changes (I may be wrong on that).
But it went through several iterations before I've got something that satisfies me. I considered to use a second set of radio buttons or dynamic hyperlink substitution - both had a usability drawbacks.

I beleive, that there is still a room for wiki improvements. Among other things, I wish there were:

1. ability to specify which types of wiki (plain,branch,commit,ticket...) to show on the /wcontent page
2. line-by-line annotations (a.k.a. "blame" feature)
3. possibility to supply a comment about the edit

The last one may need to change the format of wiki artifacts (which seems to be a show-stopper).

possibility to supply a comment about the edit

That is, quite unfortunately, not possible without a backwards-incompatible change to the wiki artifact format. It would require adding a C-card to the wiki artifact syntax, which would break wiki pages for all fossil versions built prior to that change. :/

We can make the C-card optional for Wiki pages. In fact, I just checked in a change to do exactly that. I don't think I broke anything in the process - please correct me if I'm wrong and I will back out the change.

What it does mean is that if some future version of Fossil generates a wiki artifact that includes a C-card, then older versions of Fossil will reject that artifact as being malformed and will thus ignore the change to the wiki page. So, perhaps we should let Fossil go through several releases so that most users have upgraded to a version that is able to parse a C-card on a wiki artifact before we add support for generating and using that C-card. Otherwise we can expect lots of bug reports along the lines of "I made a change to a wiki page but that change is not showing up on the server!"

What it does mean is that if some future version of Fossil generates a wiki artifact that includes a C-card, then older versions of Fossil will reject that artifact as being malformed and will thus ignore the change to the wiki page.

What does it mean for later versions of that page, even if they don't have such a card? Does the introduction of a single C-card somewhere in the history invalidate (via interrupting the blockchain lineage) versions after that for clients which can't read the C-card?

And what happens to the page lineage during a rebuild on a client which doesn't yet know the wiki C-card?

Yeah - it would cause problems for older clients if they tried to process a repo that contained wiki pages with C-cards. It would be as if some of the artifacts in the lineage of the wiki page had been shunned. On the other hand, the problem is easily resolved by upgrading the local Fossil to the latest version and then running rebuild.

Perhaps the best approach is to leave in the patch from earlier today that makes C-cards optional on wiki artifacts, but don't add code to actually generate or use C-cards on wiki artifacts until after the passage of time when nearly everyone has updated to a version of Fossil that knows that C-cards on wiki are permitted.

Perhaps the best approach is to leave in the patch from earlier today that makes C-cards optional on wiki artifacts, but don't add code to actually generate or use C-card...

That would be my personal preference. C-cards on wiki pages are long overdue, but i'd hate to see it get rushed and cause clients to misbehave. If a page has a C-card, great - display it in the relevant places, but adding an edit/entry field for it should be delayed "a year or so."

line-by-line annotations (a.k.a. "blame" feature)

This is hard for wiki because the input is markup. With code, lines are normally length limited to about 80 bytes or so. (In theory, code lines can be as long as you want, but in practice most people keep lines of code relatively short.) The blame algorithm breaks up the file by lines, and so having reasonable-length lines is an important part of the algorithm.

But with wiki, because it is markup with auto-wrapping lines, sometimes an entire paragraph will be written as a single line in the source text. This is a problem for the blame algorithm. It is also a problem for diff.

But if you are willing to ignore the problem of very long lines, it might not be too much trouble to implement blame for wiki.

It seems to me that [timeline format Wiki history] would require more invasive code changes (I may be wrong on that).

I don't think it would require any changes to existing code. It would require you to dig into the the existing timeline code, though, and to gain a good understanding of how it works.

There are some higher-level routines for generating timelines that I do not think would be usable with Wiki page, at least not without extensive modification. But if you go with a lower-level implementation that makes direct calls to graph_init(), graph_add_row(), and graph_finish(), I don't think any code modifications would be necessary, only code additions, which could all be local to (that is to say, have file scope in) the wiki.c source file.

Are there any objections against merging this brunch into trunk?

Are there any objections against merging this brunch into trunk?

Good morning!

The clickable dots don't seem to do anything for me. Presumably they're intended to work like the dots on the timeline? They're clickable, but clicking them does nothing beyond activate their checked state.

The new JS script is loading, there are no errors in the dev console in both FF and Chromium. i'll take a whack at figuring out the problem, but wanted to report it first.

The clickable dots don't seem to do anything for me.

Nevermind - a usability misunderstanding on my part. Selecting a radio buttons changes the version which clicking a "diff" link will diff against. That wasn't immediately obvious.

Regarding this comment from the JS header:

 * For the sake of compatibility with ascetic browsers the code tries
 * to avoid modern API and ECMAScript constructs. This makes it less
 * readable and may be reconsidered in the future.

Fossil already requires an HTML5-compliant browser, and HTML5 compatibility implies "modern" JS support, so there's no need to hold back. e.g. some of those for() loops can be simplified considerably with modern JS:

document.querySelectorAll("input[name='baseline']").forEach(function(r,ndx){
  wh_radios.push( r );
  r.indx = ndx;
  r.addEventListener( "click", wh_onRadio, false );
  r.disabled = false;
  var td = r.parentElement.nextElementSibling;
  r.iterspan = td.getElementsByTagName("span")[0];
});

but i'll resist the urge and keep my fingers off of it for the time being.

radio button changes the version which clicking a "diff" link will diff against

The underline rationale was to preserve the overall UI appearance for both enabled and disabled JavaScript modes of the browser.

wasn't immediately obvious

For the sake of usability there are other not-very-obvious things (-:

• Clicking anchor sign (⚓) clears selection of radio button

• Clicking recycling sign (♲) hides rows with "preliminary edits" - those that are "amendments" made by the same user.
  The rationale is that if the edits happen frequently then a person typically remembers his/her own edits and wants to know what others have introduced.

• If selected row is recycled (hidden) then the diff link leads to the comparison against the visible row

can be simplified considerably with modern JS

Yes. My intent was to make this feature work on old browsers; such as Replicant v6 which has webview version 43 (summer 2015). As far as I remember it worked :)

Clicking recycling sign (♲) hides rows with "preliminary edits" - those that are "amendments" made by the same user. The rationale is that if the edits happen frequently then a person typically remembers his/her own edits and wants to know what others have introduced.

That explains why that button's use seemed inexplicable on my repo, where nobody else has made edits. The anchor button's use, and its meaning as a column header, became clear after i figured out that the radio buttons do indeed change the diff behaviour.