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".

In the absence of comments, I guess it's up to me to pick my favorite.

For /forumthread and /forumpost, I propose three checkboxes:

Label	Desktop Default	Mobile Default
Threaded	✅	❌
Raw	❌	❌
History	❌	❌

To not break existing URLs, the "t" query parameter will continue to be read (though no longer generated) and will be mapped as follows:

Platform	t	Threaded	Raw	History	Single
Desktop	a	✅	❌	❌	❌
Mobile	a	❌	❌	❌	❌
Any	h	✅	❌	❌	❌
Any	c	❌	❌	✅	❌
Any	r	❌	✅	✅	❌
Any	y	❌	✅	✅	✅

[Edit: I enabled Raw and History for c and r because that is current behavior.]

[Edit: Oops, y actually means the history of a particular comment, not the whole thread. Thus, the "Single" column. Oops #2: `y displays in raw mode.]

Also to preserve existing URLs, in addition to "t" I will keep the "raw" and "hist" query parameters. All I do is add "hier".

(Hmm, "hist" doesn't seem to be implemented, only documented. Oh well, keep it anyway!)

Legacy/New	Parameter	Description
Legacy	t	Mode selection, as above
Legacy	raw	Show a single raw comment with no border
New	single	Show a single comment rather than the whole thread
New	hier	Show hierarchical threads, boolean
New	hist	Show edit history, boolean
New	plain	Show raw comments, boolean

[Edit: Uh oh, raw is actually rawer than raw, in that it doesn't even display the frame around the post. Thus, I will go with plain instead, letting raw continue to do what it's been doing.]

Sound good? I don't have time to implement now, but it's better that we come to an agreement before I write code. (In fact, time got away from me and I'm now at risk of being late for an upcoming meeting. Oops!)

[Edit: All these edits are getting messy! Time to reply instead. But at least I'm making a good test case thread!]

[Edit: This is a test edit whose sole purpose is to see what happens when old posts get edited after newer posts which themselves have been edited.]

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:

Mode	Raw	History	Description	Default For
Threaded	☐	☐	Normal threaded mode	Desktop
Threaded	☐	☑	Threaded with edit history
Threaded	☑	☐	Threaded without formatting
Threaded	☑	☑	Threaded with edit history and no formatting
Chronological	☐	☐	Normal chronological mode	Mobile
Chronological	☐	☑	Chronological with edit history	Mobile (old)
Chronological	☑	☐	Chronological without formatting
Chronological	☑	☑	Chronological with edit history and no formatting
Single	☐	☐	Single comment
Single	☐	☑	Single comment edit history
Single	☑	☐	Single comment without formatting
Single	☑	☑	Single comment unformatted edit history

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:

Platform	Query	Description	t	plain	hist
Desktop	t=a	Same as t=h	N/A	Effective	Effective
Mobile	t=a	Same as t=c	N/A	Effective	Effective
Any	t=h	Threaded mode	N/A	Effective	Effective
Any	t=c	Chronological mode	N/A	Effective	Effective
Any	t=s	Single mode	N/A	Effective	Effective
Any	t=r	Same as t=c&plain&hist	N/A	Ignored	Ignored
Any	t=y	Same as t=s&plain&hist	N/A	Ignored	Ignored
Any	raw	Like t=s&plain, no border	Ignored	Ignored	Ignored
Any	plain	Unformatted	Effective	N/A	Effective
Any	hist	Edit history	Effective	Effective	N/A

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.

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.

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.

Typos:

editted => edited

See src/forum.c

5 instances altogether