I'm confused by the thread view modes. There appear to be three mutually-exclusive modes:

• Chronological
• Hierarchical
• Unformatted

What surprises me is that, functionally speaking, unformatted mode implies chronological mode. I would have thought chronological/hierarchical and formatted/unformatted to be orthogonal settings.

Furthermore, chronological (therefore also unformatted) mode implies showing the edit history inline rather than hiding it behind the [history] link. Again, I would have thought "show/hide edits" would be a third orthogonal setting.

Thoughts? As much as I'm tempted to change this, it's a bad idea to dig in and start making changes here without knowing the context of why things are the way they are.

I agree with you. Like on Sesame street one of these things doesn't belong here.

The first two are ordering operations. Unformatted has nothing to do with ordering (per se). It's display and we could in theory have an unformatted hierarchical (really threaded displayed as a heirarchy) display showing edits as well.

That said, I am not quite sure how to group/differentiate these. I could see unformatted being a checkbox but that would mean that there should be an unformatted threaded display which AFAIK doesn't exist.

I think unformatted rose up because of unterminated html tags in the text making it impossible to view some threads. Using unformatted resulted in everything going into pre blocks that stops the mismatched html from being a problem.

This is why "unformatted" is not a per entry/response item.

"Formatted" or "Unformatted" could be a checkbox, need to decide which sense we prefer.

Ditto "Chronological" or "Threaded".

Ditto "Show Edits" or "Hide Edits".

I fear I got everything muddled up, but being able to safely do that is the point of thinking everything through before trying to code anything. Turns out this is rather hard!

Having four booleans implies sixteen combinations, but it makes no sense to combine hier with single. That brings us back to modes. There are three primary modes (Threaded, Chronological, and Single), plus two remaining booleans (raw and history), for a total of twelve combinations. Do they all make sense? Let's see:

Looks like yes, they do all make sense. However, what doesn't make sense is picking Single from a listbox. Single mode can only be entered in combination with selecting a particular comment, which is done by clicking the [History] and [Source] links in the border of that comment. This leaves us with Threaded and Chronological, which I'm going to have to keep as separate links in the page header so the user can change modes. When in Threaded, display Chronological. When in Chronological, display Threaded. When in Single, display both.

Okay, now I'm going to chart everything out using this revised perspective:

Now we're getting somewhere!

The [History] link, which currently points to t=y, will change to t=s&hist or t=s&plain&hist, depending on whether or not in formatted mode.

The [Source] link will continue to point to raw.

Yup that looks like a reasonable matrix.

What controls are you planning? Are these all links, or do you you have a form with history and raw checkboxes?

The nice part about links is it will work without javascript. The bad part is you would need three clicks (and page loads) to get (on desktop) starting in threaded mode with links:

  chronological, history, raw

Click one changes to chronological mode; click 2 to chronological with history and click 3 to enable raw mode. So after three clicks, you end up with links:

   threaded, no history, formatted

while displaying in chronological, history and raw mode.

With a form, you could check history and raw and have chronological be a submit button (or have a separate submit/Apply button). One submit/round trip and you get to the desired state.

IMO the number of times history and raw will be used, there is no issue with using links. Each link sets/unsets its one option, but it's just my uninformed opinion.

However this is something to consider before start of coding.

I'm planning to display "Chronological" and/or "Threaded" as links, followed by "History" and "Raw" as checkboxes.

When in threaded mode, the "Chronological" link is shown.

When in chronological mode, the "Threaded" link is shown.

When in source mode (reachable via a [Source] link), both "Chronological" and "Threaded" links are shown, and the checkboxes are hidden.

To be honest, I feel I should say "Hierarchical" rather than "Threaded" and "Unformatted" rather than "Raw" to match the existing UI. Is that okay with everyone?

At this moment, I'm happily hacking away in my andygoth-forum-refactor thread. It's turning out to be a huge effort, but one I find well worth my time. Much refactoring is required to get the forum code into a condition that can support this new functionality. Because this is a refactoring process, I'm trying to make each change be its own check-in so that they can be examined separately, proving the correctness each step of the way. Otherwise it'll look like I just rewrote the whole thing all at once, which will make code inspection vastly more difficult.

I have a seemingly-working version now. Please try out the andygoth-forum-refactor branch and post about your experiences.

In addition to the already-discussed changes, when a post is edited, its serial number now includes a revision number. For example, "4.3" means the third edit to "4.0". Posts that have never been edited don't show a revision number at all.

The baseline code always displays edited posts unformatted. Do we want to leave this alone, display edited posts the same way as current posts, or add another option to control the formatting of edited posts? I chose to maintain the baseline behavior because I imagine there was some reason for it.

Thank you for making the changes! drh has pushed these changes to the hosted Fossil repo where we can all try and see the changes. I like the edited post count modification as well.

One small warning was generated when I built this morning.

cc -I. -I./src -Ibld -Wall -DFOSSIL_DYNAMIC_BUILD=1 -DFOSSIL_HAVE_FUSEFS  -g -O2 -DHAVE_AUTOCONFIG_H -D_HAVE_SQLITE_CONFIG_H -o bld/forum.o -c bld/forum_.c
./src/forum.c:772:7: warning: variable 'mode' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
      default: webpage_error("Invalid thread mode: \"%s\"", zMode);
      ^~~~~~~
./src/forum.c:794:7: note: uninitialized use occurs here
  if( mode!=FD_CHRONO ){
      ^~~~
./src/forum.c:737:11: note: initialize the variable 'mode' to silence this warning
  int mode;
          ^
           = 0
1 warning generated.

I like the change. The chronological/hierarchical links work without javascript.

However the check boxes do nothing useful and are confusing.

Should they even be displayed if js is disabled. E.G. the version graph on the timeline page isn't displayed if js is not working.

Alternatively would adding a submit button only when javascript is disabled work? It could make it look like the left hand chronological/hierarchical is covered by the submit button. Maybe adding a div with a border around the checkboxes/submit button would work to reduce confusion?

If someone wants to take that on, my recommendation is: when emitting the HTML, simply add the CSS classes "hidden" and "reveal-at-startup" to those elements, then emit a piece of JS which removes those classes from all elements matching the second class. Something like...

document.querySelectorAll(".reveal-at-startup").forEach(
  function(e){
    e.classList.remove('hidden');
    e.classList.remove('reveal-at-startup');
  } 
);

(That's tedious to type from a tablet.)

Noting that MSIE does not have forEach() but we have a polyfill for that in style.c.

That will hide the elements in non-JS environments and reveal them if the JS runs. Our CSS already defines the hidden class and the new JS code makes extensive use of it.

Note, however, that near-future plans for the forum will make writing/responding to posts impossible without JS unless someone else steps up to maintain noscript legacy versions of the affected features. (You Have Been Warned.) Reading posts won't (or shouldn't) be affected, at least not according to the current plans.

Probably outside the scope of what you wanted/considered, but I'll ask/report it anyway.

If I'm in c or h view with unformated text and reply to a post, I'm switched back to the formatted view. This is (probably) only a disadvantage me because I like to cheat and see how people are crafting their markdownn in posts. This means opening two tabs to see it and other tab to reply to it. Is it logical to assume the "replying to" text should be in the same view/mode you were viewing the thread in?

Sounds reasonable to me. I tried my best to avoid making any changes to posting, so I didn't even think about that.

Edit history not shown when not in "history" mode.

At https://sqlite.org/forum/forumpost?name=81ae398a37 is a thread on the SQLite forum started by an anonymous poster. They did not format their text very well. I tried to edit it, but now it appears that I am the original poster.

Before the refactor, it shows the post as "by" the original author with an additional notation of "edited by" for the editor. I think that would still be useful.

For now, I have revised my edit to make it clear that I am not the original poster. But I shouldn't have to put that disclaimer in the text of the post, I would think.

More formatting problems...

Again over on the SQLite Forum: https://sqlite.org/forum/forumpost?udc=1&hist=on&name=1761a34414&t=h

As before, someone submits a misformatted query, though this time their query was formatted using Fossil Wiki. I tried to correct the formatting without changing the mimetype. And it looked fine on preview. But then when after I pressed "Submit" my edits were apparently formatted as Markdown. This caused severe distortion.

I went back and did a second edit, changing the mimetype to Markdown. That fixes the display. (SQLite Forum is a production forum - I can't leave misformatted entries there, waiting on Fossil bug fixes!) But now the formatting for my first edit is correct in the history display.

I don't know where exactly the problem is or how to reproduce it, but there is still a serious issue in the refactored forum display.

Does this help?

Working concurrently, I made an alternative fix which is now on trunk and which is now installed on the server. Revisit the reference link to see the new header style.

Typos:

editted => edited

See src/forum.c

5 instances altogether