Fossil Forum

fetching a preview of an edit without having to reload the whole page

Hi, personally I'm fine with the current behavior, and would expect the redesign to continue to work without JavaScript.

personally I'm fine with the current behavior,

That brings up an interesting point, actually...

The recent motivation for this work has been to make it easier for the folks who are posting tons of LLM-assisted tickets in the SQLite bugs forum. To that end, we recently added support for attachments in the forum and have just reworked the attachment process to support multiple attachments at once (which requires JS). One of the ways we can make it easier is to enable attachment of files at the same time the post is created, instead of having to wait until the post has been saved. Integrating that requires JS/ajaxing-ifying forum editor because file attachments cannot work together with the current preview/save process.

That's the motivation, anyway. Whether the result will genuinely, and significantly, improve usability is admittedly an open question, and we probably won't know for sure until we've tried it.

and would expect the redesign to continue to work without JavaScript.

Whether or not a no-JS form would continue to be supported depends on (A) how much effort it is to test and maintain and (B) someone being willing to do both.

Preview isn't necessary on same page, even GitHub has it as tab-switching - editing or viewing, not both.

What is really needed is syntax highlighting (that is, markdown's lang name after opening backticks), especially for long badly formatted queries on main forum.

My $0.02, I assume file attachment are permanent (except for shunning), I think a little friction is a good thing. Rather than adding the file at the time of writing, would attaching the file(s) after the message is edited/saved be a good workflow?

This wouldn't work if you expect links in the message to point to the file though. But I am not sure if that's in your use case.

I did something similar (file attachment preserved across a verification step in the middle). It did require javascript be enabled, but it submitted the files with the form using a file input rather than async posting. Given the difficulty of removing a file attachment in Fossil, might this be the better way to do it?

The basic idea was:

1. user enters data into for and fills file inputs
2. data is sent to back end for review
3. the returned page displays the preview and filled in regular form field it base64 encodes file attachments and places them in pre blocks with attributes like data-filename.
4. when the page is displayed on the user's device, javascript reads the contents of the <pre data-filename="example1.sql"> and reattaches them to the file input.

I didn't incorporate any file preview or anything, just reattched the files under their original names.

Rather than adding the file at the time of writing, would attaching the file(s) after the message is edited/saved be a good workflow?

That's the current process. It works, especially now that you can attach multiple files at once (as well as paste from the clipboard), but it's a bit awkward and leaves a window between the time a post is made and when its attachments show up.

Preview isn't necessary on same page, even GitHub has it as tab-switching - editing or viewing, not both.

A tab-styled interface, like in github issue comments, is what /wikiedit and /fileedit have, but the forum currently uses a top/bottom split view with the preview on top. /wikiedit is a larger version of what i think i'd like for forum editing but am as-yet undecided whether a tabbed view is more usable than a split view (and will probably experiment with both).

What is really needed is syntax highlighting (that is, markdown's lang name after opening backticks), especially for long badly formatted queries on main forum.

That's a topic beaten to death elsewhere, so i won't go into details, but the summary is that Fossil can't do that without third-party software on the server and/or client. Client-side highlighting can be plugged in via JS and skins, but server-side would require major additions and future maintenance to the C code.

It's long been the intent to modernize the forum editor

Please don't. The modern web is just a mess, largely stemming IMHO from publishers trying to impose a one-size-fits-all UI on the whole world. To the extent that Fossil must be modified to support more dynamic features, I would highly suggest the architecture be more about exposing an API that can generally be used by "anyone" (including the AI slop bots) who would benefit from a more specialized interface.

fetching a preview of an edit

That (Markdown/Wiki to HTML transformer) would be wonderful standalone microservice to offer, including for general use at the command line. I'm not sure if there's any overlap between how Fossil parses/generates that data and how SQLite supports html and markdown modes, but to my mind they all fall under the same sort of import/export abstraction.

From the UI perspective, though, instead of hitting your server, I'd rather be able to use my local Markdown editor of choice, be it a desktop app or a Node library or whatever, optionally with whatever style sheets will make it match the look of the site. They'll give me a preview as I type, too; no need to bother the server with anything until it's ready.

Should replying to a post

Again, as you note with the potential for issues on smaller screens on phones, there's no one right answer. Heck, even the current Reply button is "broken" in that it won't let me open my reply in a new tab, so I can't easily refer back to the entire discussion rather than just the post being replied to. I say leave the effort of trying to please all the people all the time up to all those people.

Should the edit/preview pair be "tabbed"

If an interaction with the server is necessary to update the preview, it makes the most sense to have the UI hide/switch between the two versions. I hope it's obvious that a more desirable UI would be to have a preview that updates as you type, which many existing editors already do.

And from a different reply:

The recent motivation for this work has been to make it easier for the folks who are posting tons of LLM-assisted tickets in the SQLite bugs forum.

It makes zero sense to do UI updates for that purpose. Just point them to the API and everyone wins.

That's the motivation, anyway. Whether the result will genuinely, and significantly, improve usability is admittedly an open question, and we probably won't know for sure until we've tried it.

To the extent access controls allow it, there's really no reason that a fancy editor must be provided by Fossil itself.

Whether or not a no-JS form would continue to be supported depends on (A) how much effort it is to test and maintain and (B) someone being willing to do both.

I'm not sure where the "both" comes in. The API is the API. The UI you put in front of it, be it a web page or agentic LLM or a curl request, should make no difference.

Please don't.

It's going to happen sooner or later. To be clear, though, "modernizing", in this context, means using AJAX/XHR for communication, not adding a bunch of bling to the UI. JS-based communication allows us to update pieces of a page without having to completely reload it, and that's a must for things like an editor form which supports both attachments and a preview. (We can do one or the other without JS, but we cannot combine them without JS, for long boring $REASONS.)

... trying to impose a one-size-fits-all UI on the whole world

It's fair to say that none of us are particularly gifted in UI design, so ours won't look like everyone else's ;).

I would highly suggest the architecture be more about exposing an API that can generally be used by "anyone" (including the AI slop bots) who would benefit from a more specialized interface.

That was the intent of the JSON API but (A) it's never really caught on and (B) it's a bit out of date, with no significant changes in roughly 10 years. "It would be cool" to see the JSON API completely rearchitected and built upon SQLite's JSON support (which the current JSON pieces predate by several years), but experience tells me that it would require a month or two of work at my age-40 energy levels and much more than that at my current mid-50s energy levels :/, so that's a task i'd rather see someone else take on :).

From the UI perspective, though, instead of hitting your server, I'd rather be able to use my local Markdown editor of choice,

That's not really feasible because fossil does no small amount of custom link generation. e.g. [some-hash] looks for a matching hash.

Heck, even the current Reply button is "broken" in that it won't let me open my reply in a new tab,

FWIW, i feel your pain but that's a limitation we currently have to live with.

Reply button is "broken" in that it won't let me open my reply in a new tab, so I can't easily refer back to the entire discussion rather than just the post being replied to.

That's why i'd like to do the replies inline. That, however, brings its own usability issues and solving them will require some exploration.

If an interaction with the server is necessary to update the preview, it makes the most sense to have the UI hide/switch between the two versions.

I hope it's obvious that a more desirable UI would be to have a preview that updates as you type, which many existing editors already do.

That only works with client-side rendering. We can't implement fossil's resolution of hashes, wiki pages, etc. client-side, so a client-side solution isn't possible here. Recall too that a forum post can have one of three formats (markdown, fossil-wiki, or plain text) so we would need two separate impls. (Sidebar: the forum does not have an automatic "quote" feature is because it supports multiple formats. We can't sensibly quote a markdown-format post in a fossil-format post, or vice versa.)

Sidebar: is an example of where we were able to remove the server round-trip, and implement as-you-type updates, by building the pikchr component in WASM. We looked into doing that for fossil itself so that we could do client-side rendering of anything, but (A) it would be a huge, huge WASM file and (B) it requires having access to the whole repo, and we can't just download whole repos to every user.

It makes zero sense to do UI updates for that purpose. Just point them to the API and everyone wins.

Building APIs is part of the process of updating the UI, but we're not currently focused on public APIs. Our current security model won't accept POSTed data from arbitrary sources - it requires that the POST have originated from the same HTTP origin - which makes public remote APIs which post data (as opposed to simple GET requests) a non-starter.

To the extent access controls allow it, there's really no reason that a fancy editor must be provided by Fossil itself

"Fancy" is overstating it, but i'd like something a bit more modern than what we have. At a very minimum, i want it to stash my being-edited post into localStorage as i type so that i don't lose it by accident (like /wikiedit does, and which makes /wikiedit useful for drafting longer posts).

I'm not sure where the "both" comes in.

Old and new input forms, that is. Nobody really wants to support two different implementations of the forum editor, so retaining the static form will require either a volunteer to do so or pressure from either the project lead or a sponsor (e.g. an SQLite Consortium member).

Well, from the C side it's enough to provide proper Markdown parsing, as e.g. in GFM info strings are not limited to just identifier, and to pass them to HTML as proper attributes to which JS/CSS could then be plugged in. That is, to provide a "socket", may be an example JS which will use them to show how user could do this.

Or another alternative, fossil binary could call e.g. vim - which has :TOhtml to dump syntax highlighting to HTML file, this could be scripted and returned on page. Other tools to provide coloring to HTML also exists, e.g. old good Colorer...

In any case, this should be minimal inside C code, and not for the reasons of C side maintainability, but for the reasons of pluggability and customizability - it's much better to keep highlighting in separate repositories, to be able to add another language, etc.

But in any form, the feature is needed, and not only in forum, but in showing artifacts also - this is (together with pull request analogs / code review) where Fossil seriously lags behind GitHub, preventing many to switch to it "alternative to Git".

That (Markdown/Wiki to HTML transformer) would be wonderful standalone microservice to offer, including for general use at the command line. I'm not sure if there's any overlap between how Fossil parses/generates that data and how SQLite supports html and markdown modes, but to my mind they all fall under the same sort of import/export abstraction.

From the UI perspective, though, instead of hitting your server, I'd rather be able to use my local Markdown editor of choice, be it a desktop app or a Node library or whatever, optionally with whatever style sheets will make it match the look of the site. They'll give me a preview as I type, too; no need to bother the server with anything until it's ready.

Huh, that's the same thing I tried to say above in #10 post. Put the formatting outside, to let users do themselves if they want more customization, leaving just a glue code framework in C.

It's going to happen sooner or later. To be clear, though, "modernizing", in this context, means using AJAX/XHR for communication, not adding a bunch of bling to the UI.

Well, then my assumption would be use of fetch as the "modern" client-side JS. But my point remains that I wouldn't aim to make that a core functional requirement to use the forum. Sure, it sounds like a nice-to-have feature, but to my mind it is mostly independent of what the backend is actually doing. I mean, it could instead (very abstractly) be implemented as a browser extension, say, that added an extra Markdown preview pane/tab for any chosen text field on any site, along with syntax highlighting and whatever other bells and whistles the developer was interested in. A quick search shows some very similar extensions do already exist, but none looked exactly like I could just start using it to edit this page.

It's fair to say that none of us are particularly gifted in UI design, so ours won't look like everyone else's ;).

You misunderstand my complaint (from the reverse direction :-). The problem to me isn't that everyone's web site looks identical, it's that all the visitors must put up with the designer's "pixel perfect" choices, which are unlikely to suit all comers. This used to mainly be an issue only in an accessibility context, but the wide variety of devices that are on the market these days make it increasingly difficult to support (directly) every option out there. I skinned my blog's Fossil repo, but only really tested it with my desktop browser for that very reason.

That was the intent of the JSON API

I haven't dug into that as much as I should; I think I'll play with it a little over the weekend. I don't see anything that screams forum support, but I did notice that wiki/preview exists, so I'm going to see how easy it would be to use it to replace the markdown command I use for generating some static pages on one of my sites. I'm also going to poke around with timeline, because I want more information than what the RSS feed of it provides.

it's a bit out of date, with no significant changes in roughly 10 years

Again, I don't understand this. I know C isn't a dynamic language that gives you a lot "for free", but to me the architecture should all be working with the same core calls/data structures, and it's just a question of pushing it through some generic wrappers to get it in JSON or HTML or XML or whatever.

That's not really feasible because fossil does no small amount of custom link generation.

Clearly it couldn't locally do a final preview, but how much can be done client-side all comes down to what sort of interactions the API supports. I've used rich text editor libraries that provide a "Link" button that could be hooked into a microservice that did that hash lookup (or whatever). It all comes down to where the line gets drawn for what is core to Fossil, and I still very much like the approach that doesn't lean too much on what the "modern" browser can support.

which makes public remote APIs which post data (as opposed to simple GET requests) a non-starter

The JSON API docs seemed to imply that an authenticated user could do a POST. If not . . . that's why it never really caught on! :-/

At a very minimum, i want it to stash my being-edited post into localStorage as I type

See, that's another great idea for a browser extension and/or basic feature. I want that on every web form I have to fill out not just for Fossil. Truth is, though, for longer Markdown posts, I usually prefer to use a desktop app and then copy-paste.

Nobody really wants to support two different implementations of the forum editor

I'm still not getting it. From the server's standpoint, there isn't any editor. It's all just about how the data is packaged/encoded. When I have endpoints that want "form encoding", that's what I have my JS give them.

The problem to me isn't that everyone's web site looks identical, it's that all the visitors must put up with the designer's "pixel perfect" choices, which are unlikely to suit all comers.

Similarly, the current forum doesn't suit all comers ;). We can't please everyone, and the priority with regards to preferences goes to those who are doing the work ;).

I haven't dug into that as much as I should; I think I'll play with it a little over the weekend. I don't see anything that screams forum support,

The forum was added long after the last significant changes to the JSON API, so it doesn't deal with them.

so I'm going to see how easy it would be to use it to replace the markdown command I use for generating some static pages on one of my sites.

i tried using it that way some 10 years ago but quickly found that its processing of links interfere with out-of-fossil use.

but to me the architecture should all be working with the same core calls/data structures, and it's just a question of pushing it through some generic wrappers to get it in JSON or HTML or XML or whatever.

It's unfortunately not that simple with fossil, where presentation code and app logic are frequently closely mixed.

I've used rich text editor libraries that provide a "Link" button that could be hooked into a microservice that did that hash lookup (or whatever). ... I still very much like the approach that doesn't lean too much on what the "modern" browser can support.

i'm getting mixed signals there. One says use a microservice (a JavaScript-driven call) and one says don't JS-ify the forum?

i agree that "it would be cool" to have such a thing, but we don't and adding something like it is arguably way out of scope in that we're focused on fossil's UI and not generic applications which talk to it.

Sidebar: one of the reasons for creating libfossil was to support the creation of specialized apps like microservices.

The JSON API docs seemed to imply that an authenticated user could do a POST. If not . . . that's why it never really caught on! :-/

It supports POST but requires (for most purposes) that the POSTer be one of fossil's own pages, for security reasons. The main reason it never caught on, i opine, is because it requires a custom fossil build. It's never been part of a default build so has never seen much use (which is arguably a good thing because it's way over-engineered). In any case, though, future JSON-based APIs really ought to be implemented on top of sqlite's JSON pieces instead of the pseudo-third-party API it uses now. (Heck, it might even make sense to go ahead and deprecate/remove the legacy JSON API and remove the not inconsiderable code it brings along.)

Truth is, though, for longer Markdown posts, I usually prefer to use a desktop app and then copy-paste.

provides a dummy wiki page which cannot be saved remotely but is stashed locally whenever the input field loses focus.

Nobody really wants to support two different implementations of the forum editor

I'm still not getting it. From the server's standpoint, there isn't any editor.

Ah, see, that would be the case for a generic framework, or an app which supports third-party plugins, but is not for fossil. Fossil closely ties the HTML and app logic for the editor (indeed, for most apps) for the simple reasons that (A) it's easy to do and (B) it serves fossil's own needs. IIRC, /wikiedit and /fileedit are the only two fossil pages which do not closely wed the app logic and the presentation.

The problem to me isn't that everyone's web site looks identical, it's that all the visitors must put up with the designer's "pixel perfect" choices, which are unlikely to suit all comers.

Similarly, the current forum doesn't suit all comers ;). We can't please everyone, and the priority with regards to preferences goes to those who are doing the work ;).

I haven't dug into that as much as I should; I think I'll play with it a little over the weekend. I don't see anything that screams forum support,

The forum was added long after the last significant changes to the JSON API, so it doesn't deal with them.

so I'm going to see how easy it would be to use it to replace the markdown command I use for generating some static pages on one of my sites.

i tried using it that way some 10 years ago but quickly found that its processing of links interfere with out-of-fossil use.

but to me the architecture should all be working with the same core calls/data structures, and it's just a question of pushing it through some generic wrappers to get it in JSON or HTML or XML or whatever.

It's unfortunately not that simple with fossil, where presentation code and app logic are frequently closely mixed.

I've used rich text editor libraries that provide a "Link" button that could be hooked into a microservice that did that hash lookup (or whatever). ... I still very much like the approach that doesn't lean too much on what the "modern" browser can support.

i'm getting mixed signals there. One says use a microservice (a JavaScript-driven call) and one says don't JS-ify the forum?

i agree that "it would be cool" to have such a thing, but we don't and adding something like it is arguably way out of scope in that we're focused on fossil's UI and not generic applications which talk to it.

Sidebar: one of the reasons for creating libfossil was to support the creation of specialized apps like microservices.

The JSON API docs seemed to imply that an authenticated user could do a POST. If not . . . that's why it never really caught on! :-/

It supports POST but requires (for most purposes) that the POSTer be one of fossil's own pages, for security reasons. The main reason it never caught on, i opine, is because it requires a custom fossil build. It's never been part of a default build so has never seen much use (which is arguably a good thing because it's way over-engineered). In any case, though, future JSON-based APIs really ought to be implemented on top of sqlite's JSON pieces instead of the pseudo-third-party API it uses now. (Heck, it might even make sense to go ahead and deprecate/remove the legacy JSON API and remove the not inconsiderable code it brings along. Edit: nope - i make use of it to embed timeline snippets in remote sites, e.g. here)

Truth is, though, for longer Markdown posts, I usually prefer to use a desktop app and then copy-paste.

provides a dummy wiki page which cannot be saved remotely but is stashed locally whenever the input field loses focus.

Nobody really wants to support two different implementations of the forum editor

I'm still not getting it. From the server's standpoint, there isn't any editor.

Ah, see, that would be the case for a generic framework, or an app which supports third-party plugins, but is not for fossil. Fossil closely ties the HTML and app logic for the editor (indeed, for most apps) for the simple reasons that (A) it's easy to do and (B) it serves fossil's own needs. IIRC, /wikiedit and /fileedit are the only two fossil pages which do not closely wed the app logic and the presentation.

That (Markdown/Wiki to HTML transformer) would be wonderful standalone microservice to offer, including for general use at the command line.

One imagines that you are at least aware of the (unsupported, test) markdown render command?

Hi Stephan,

Thanks for taking the time to modernize the forum for Fossil. I know it's been brought up over the years, so thanks for working on it.

I personally like the idea of a tabbed view of preview. Not necessarily because that's how it is on github, but it just seems like a cleaner implantation, and it's already present on the two pages you mentioned. Would this also mean you can save posts in your browser cache before posting? I think /fileedit has the in it, right?

If you want to go the inline route, were you thinking of a design similar to /pikchrshow, except below the post?

Thanks!

I personally like the idea of a tabbed view of preview.

That's my current direction of exploration. So far, so good:

(That "toggle header" button hides the page header, effectively making the editor full-screen. It does not yet adapt to the window size like /chat does but i'll experiment with that at some point.)

Once it's properly plugged in and the new/reply/edit pages are working, "inline" edits and responses will be explored.

Would this also mean you can save posts in your browser cache before posting?

It's actually doing that already, the same way /wikiedit and /fileedit do. Testing would be way too tedious if the editor had to be populated each time the page was reloaded.

If you want to go the inline route, were you thinking of a design similar to /pikchrshow, except below the post?

My current thinking is that for edits, the current post view would be replaced by an editor, but also shifted all the way to the left of the screen so that it cleanly fits on the screen in hierarchical view. Similarly, for replies, a new response widget would appear directly below the being-responded to post. That post would be left-justified and the response would be left-justified immediately below it.

All subject to change as experimentation suggests better approaches.

We can't please everyone, and the priority with regards to preferences goes to those who are doing the work ;).

Sure; I'm certainly not trying to say you can't scratch your own itches! My itch tends to be optimization and architecture, so I'm just trying to see if there isn't some easier path. None of this still makes any sense to me in the context of automated bug reports, which should not involve the UI layer at all.

It's unfortunately not that simple with fossil, where presentation code and app logic are frequently closely mixed.

I get the historical reasons for that, but it seems pretty clear that it might finally be time for some kind of abstraction layer to at least some parts of the system. Yes, it'll probably be a bit of extra work to disentangle existing code, but the results would end up being cleaner and more future-proof.

i'm getting mixed signals there. One says use a microservice (a JavaScript-driven call) and one says don't JS-ify the forum?

A server (micro or otherwise, CGI or otherwise) has nothing to do with JavaScript, or any browser interaction at all. That's ultimately what you get when you start to remove the client requirement/expectation of doing nothing but rendering HTML. Or, put another way, once you choose to make the browser use JS to properly display your page, it calls into question any HTML generation by the server. If it seems like a mixed signal, I would say that's because it represents a choice that needs to be made.

The main reason it never caught on, i opine, is because it requires a custom fossil build.

Yeah, that became a bit of a sticking point when I went and tried to play with it. ;-) But absent the JSON API, it would be a good idea to document the API that is implicitly being used for automated server interactions. Because it's really, really stupid for wannabe-AI to be using a UI.

/wikiedit/sandbox provides a dummy wiki page which cannot be saved remotely but is stashed locally whenever the input field loses focus.

As a fun little experiment, I am composing this reply in the Fossil site's Sandbox. Since localStorage is shared with the Forum, I am able to insert it into the page using:

document.forms[0].content.value = localStorage.getItem('HIDINGTHISVALUEINCASEITSHOULDBESECRET::wikiedit/Forum Editor Test')

I could easily turn that into a bookmarklet if I wanted to do this a lot. Maybe the thing to do is take the editor(s) Fossil already has and turn them into proper "components" that can be used, ideally based on user preference, on the various pages they're needed?

Your imagination is greater than mine. :-) Thank you for that pointer! I use my currently installed tool with markdown -html5 -f fencedcode -f footnote, so I think I'm essentially using Fossil Flavored Markdown. Of the special features that might be a concern, I don't use any absolute links (I tend to use either full or relative links in my Markdown), and it looks like test-markdown-render does give me h1 elements (for now?). Fossil delivers again.

You're most welcome 👍 Z

Have you considered adding a select few emoji characters that can be inserted into the post in either view? I know you can copy and paste your own, but might be nice to have half a dozen available to choose from already.

If you want to go the inline route, were you thinking of a design similar to /pikchrshow, except below the post?

Screenshot of the current (not yet fully functional) draft:

There's lots of todos and to-fixes, but this approach doesn't seem horrible and the way it's plugged in retains the legacy behavior for no-js clients automatically.

A nice touch is that the drafts are automatically saved on a per-post basis, so you can have multiple edits going on. If they don't get saved or explicitly discarded then they'll get cleaned up after some expiry time.

Have you considered adding a select few emoji characters ...

That's a never-ending black hole of feature creep. Version 2.5, maybe (this one being 2.0) :).

A screenshot of the current state:

What we see here is:

• Edits and responses are now made without leaving the page.

• Any number of replies and edits can be active at the same time. There's a quirk here, though: saving one of them will reload the page. It won't lose any edits in the other ones, though. e.g. if we save one response, when the page reloads and we tap Edit on any post which was previously undergoing edits, any local draft edits will still be there. Old/stale drafts are reaped at random intervals so that they don't clutter up localStorage.

• During editing/replying, the being-edited/being-replied-to post is shifted all the way to the left so that the hierarchical view will fit the screen better. When the edit is saved or discarded the post is shifted back to its initial position.

A screenshot of the current state:

What we see here is:

• Edits and responses are now made without leaving the page.

• Any number of replies and edits can be active at the same time. There's a quirk here, though: saving one of them will reload the page. It won't lose any edits in the other ones, though. e.g. if we save one response, when the page reloads and we tap Edit on any post which was previously undergoing edits, any local draft edits will still be there. Old/stale drafts are reaped at random intervals so that they don't clutter up localStorage.

• During editing/replying, the being-edited/being-replied-to post is shifted all the way to the left so that the hierarchical view will fit the screen better. When the edit is saved or discarded the post is shifted back to its initial position.

• As before, Submit does not enable until Preview has been used once.

My itch tends to be optimization and architecture, so I'm just trying to see if there isn't some easier path. None of this still makes any sense to me in the context of automated bug reports, which should not involve the UI layer at all.

I agree with architecture bit, but with regard to the second part I want to pose a question: when is a UI also an API?

My answer: when you use a web engine. That is, a client application which includes within it most of a web browser implementation. It is like a web view in that it renders an HTML page into a native GUI window, but in addition it has the machinery to execute not just JS carried by the page itself but extra JS injected after the page is loaded.

To understand how that creates an API within a UI, this was my initial use of this idea: I have an application which reads a largish XML document held in a number of separate files and produces among other things a set of HTML pages. I want to be able to view the output inside the application so that when I click on some item on the displayed HTML the application fires up an editor of my choice.

As the application is in Java (and is really just a means to choose and transform the input XML, the bulk of it is XSLT), I use JavaFX WebEngine. The XSLT bit of the application adds a CSS class to the elements I want clickable along with the file/line number data in an attribute which the HTML engine will ignore. Then the Java part registers a callback with a wrapper around the web engine object. When that fires it runs a command to talk to the editor.

Translating that into Fossil context:

We may already have the 'server' (XSLT) side in the form of the work that was done to support skins.

The 'client' side is of course a whole new ball game: it's pretty heavyweight, and from my own experience the plumbing involved in that 'wrapper' isn't something you do on one cuppa. But once you have it there are all sorts of interesting options. Such as a client wrapper for Fossil (such as Fuel or Lasyfossil) which lets you select checkins to be cherrypicked or updated to by clicking on the existing Fossil UI pages. It doesn't have to be the timeline, just anything containing a checkin id that has the right CSS class on it.

Qt has a webengine (for C++) though it seems poorly supported; at least it requires MSVC which I don't use. Fuel v1 uses it but I had to strip it out to get the thing to build.

Rust also seems to have one Servo. Difficult for me to assess this one, as what little I know of Rust was acquired in just the last few days. I have known of it for a long time, just never had a reason to take it off the back burner.

Forgive the ramble please, but maybe there is a good idea in there somewhere.

Trevor

Richard just deployed the in-development forum editor bits to this forum, so this is them being tried out. There's certainly plenty of refinement and touch-ups to do but it "works for me".

Richard just deployed the in-development forum editor bits to this forum, so this is them being tried out. There's certainly plenty of refinement and touch-ups to do but it "works for me".

Edit (with the new editor):

Where this can definitely use improvement but i don't know how to do: when replying/editing, where exactly the browser will scroll it into view depends on its placement in the page and how much content is left below it. It must be possible to smoothly pop it into view without otherwise jumping around. If we don't explicitly scroll it into view then it can appear scrolled off-screen, which is a bit confusing.

Whether or not a no-JS form would continue to be supported depends on (A) how much effort it is to test and maintain and (B) someone being willing to do both.

It turns out that we can include no-JS "by default": we always (or almost always) serve the old forms, now very slightly enriched with more metadata. JS then takes over and hijacks or replaces bits and pieces (like the forum post Reply and Edit buttons). Ergo, if one has JS turned off, the new editor never plugs in and it all "should" work just like before.

I agree with architecture bit, but with regard to the second part I want to pose a question: when is a UI also an API?

In the 1990s.

Don't get me wrong, I love Web 1.0 so much that my corporate site is mostly static HTML. I have also done sites with just a smattering of JS like Fossil does, a React monstrosity that only talked JSON with the server, and everything in between.

The problem I've always found with the "we give you web pages; just use those" approach is they make automation brittle (which is why REST and other APIs were created). I've done browser-level testing/automation/scraping with tools like Selenium, and it's always a nightmare. When there is no documented API, you can't count on a call working the same way from one request to the next.

To me, the whole idea of an energy-sucking LLM wastefully firing up a browser to wastefully run some JavaScript to make a basic CGI call to report a bug is crazy.

FYI, I'm finding the JS version doesn't work for me, so I had to turn it off to write these last two posts. Error given when I try to Preview (tab or button):

Read-Wiki permissions required.

Read-Wiki permissions required.

Thank you. That's partially resolved now, in that all users on this forum now have that permission. i'll need to rework preview to use a non-wiki-specific approach so that it does not inherit wiki's access permissions.

Read-Wiki permissions required.

Thank you. That's partially resolved now, in that all users on this forum now have that permission. i'll need to rework preview to use a non-wiki-specific approach so that it does not inherit wiki's access permissions.

Edit: that's more properly fixed now with

Richard just deployed the in-development forum editor bits to this forum, so this is them being tried out. There's certainly plenty of refinement and touch-ups to do but it "works for me".

Edit (with the new editor):

Where this can definitely use improvement but i don't know how to do: when replying/editing, where exactly the browser will scroll it into view depends on its placement in the page and how much content is left below it. It must be possible to smoothly pop it into view without otherwise jumping around. If we don't explicitly scroll it into view then it can appear scrolled off-screen, which is a bit confusing. Edit: that's now mostly sorted out but if anyone has suggestions for making the animation a smoother, please let us know.

The current state of things...

The tip of the new forum feature branch has been online, in various incarnations, for a few days in all of the forums run by Richard and myself, and is expected to soon be merged to trunk. All in all, i'm pleased with the results. New capabilities include:

Editing:

• Locally-stored drafts for new posts, responses, and edits. These are saved every time a relevant editor widget loses focus. (This was long overdue.)
• Editing and replying are now "inline", no longer leave the thread. Saving has to reload the page because rendering the current state of an edited post or a new response requires a great deal of metadata which we don't have in JS and would be inordinately expensive to have in JS.
• Multiple edits and responses may be active at a time. Saving will reload the page but the local drafts of other ongoing edits and replies within that thread will be retained and the associated Reply/Edit buttons get clearly marked as having draft content.

Attachments:

• Attach files (permissions permitting) to a post while editing, even during its initial creation. The new "B" permission controls this and admins always have this capability (in contrast to the "Y" permission (uploading unversioned content)). Admins of this forum and its siblings are advised to use that capability sparingly, if at all - all of you have checkin access to the associated repos and that's generally a better approach than attachments.
• Attach files from the clipboard.
• Thumbnails of newly-attached images. We cannot thumbnail existing attachments because we cannot scale them down on the server without a third-party dependency on an image-manipulation library, which means the server would have to send the whole image and have the client scale it down.

There's certainly some refinement and improvement to do, and your input on that is welcomed.

The current state of things...

The tip of the new forum feature branch has been online, in various incarnations, for a few days in all of the forums run by Richard and myself, and is expected to soon be merged to trunk. All in all, i'm pleased with the results. New capabilities include:

Editing:

• Locally-stored drafts for new posts, responses, and edits. These are saved every time a relevant editor widget loses focus. (This was long overdue.)
• Editing and replying are now "inline", no longer leave the thread. Saving has to reload the page because rendering the current state of an edited post or a new response requires a great deal of metadata which we don't have in JS and would be inordinately expensive to have in JS.
• Multiple edits and responses may be active at a time. Saving will reload the page but the local drafts of other ongoing edits and replies within that thread will be retained and the associated Reply/Edit buttons get clearly marked as having draft content.

Attachments:

• Attach files (permissions permitting) to a post while editing, even during its initial creation. The new "B" permission controls this and admins always have this capability (in contrast to the "Y" permission (uploading unversioned content)). Admins of this forum and its siblings are advised to use that capability sparingly, if at all - all of you have checkin access to the associated repos and that's generally a better approach than attachments.
• Attach files from the clipboard.
• Thumbnails of newly-attached images. We cannot thumbnail existing attachments because we cannot scale them down on the server without a third-party dependency on an image-manipulation library, which means the server would have to send the whole image and have the client scale it down.

No-JS:

• The new pieces plug themselves in to the UI dynamically, hijacking the older widgets. Thus if JS is enabled, these features fall back to their older implementations. That was not an explicit design goal, it just worked out that way.

There's certainly some refinement and improvement to do, and your input on that is welcomed.

I managed to lose a draft reply. Possibly because I was being me and pushing the limits by trying to make two replies to the same message, but for the record this is how it went:

1. I follow posts mostly by the links I get in email. I clicked on one of these in order to reply to it, and hit Reply.
2. Seeing the new interface I wanted to make a space to keep notes about anything that might come up, and the first thought I had was make a separate reply to the same message - my second thought was that this might not work, but try it anyway. So I clicked the original message to get a new browser tab with the original message.
3. Note: I can't be certain, but I suspect at this point the first reply was still empty and thus no draft yet saved. Hence:
4. I saw the original message, hit the Reply button that was there, and began with some minor comments.
5. Return to the browser tab with the first reply and do a bit of work on that, but its getting late so shut down - being aware that my browser is set up to restore tabs the next morning.
6. Open up today, and the two tabs are there with a 'draft' button (instead of the actual text that was there at close). But both buttons return the 'real' reply rather than the one containing the notes, which I guess are gone. I suspect it is keeping only the last draft worked on,

It's probably excessive to try to support multiple simultaneous replies (implying more than one 'draft' button), but maybe use a nonce to spot when the draft you are about to overwrite doesn't match the one on screen? Or it may be enough to notice when there is already a saved draft when this should be the first.

pushing the limits by trying to make two replies to the same message

That was bound to happen sooner or later, and was foreseen but not "solved".

"The problem" is that the drafts are keyed to the ID of the post in question, so accessing them from two tabs will lose one or the other: the most recent one to lose focus will overwrite the other. The only solution which comes to mind is to use Web Locks to inform the second tab that another tab is opened and that Hilarity Will Ensue if the user attempts to use both at once. However, Web Locks are a relatively new JS addition (only in Safari since late 2024), which makes it too new for our self-imposed requirements of working for browsers at least (about) 5 years old.

It's probably excessive to try to support multiple simultaneous replies

Indeed :).

but maybe use a nonce to spot when the draft you are about to overwrite doesn't match the one on screen?

Patches would be thoughtfully considered.

The new pieces plug themselves in to the UI dynamically, hijacking the older widgets. Thus if JS is disabled, these features fall back to their older implementations. That was not an explicit design goal, it just worked out that way.

I am happy that no-js functionality still works. Progressive enhancement for the win. This also provides a fallback for screen reader users or other assistive tech.

"The problem" is that the drafts are keyed to the ID of the post in question, so accessing them from two tabs will lose one or the other: the most recent one to lose focus will overwrite the other. The only solution which comes to mind is to use Web Locks...

That is now implemented and will show up in this forum the next time Richard deploys. In the problematic case you describe, browsers which support Web Locks (all of the major browsers since late 2024, some much earlier than that) will lock a draft for a Reply or Edit and will not permit other tabs to open them. It is legal (but possibly not advised) to reply to and edit the same post in different tabs, but it disallows two edits or two replies. When the locking tab is closed, or the post discarded or saved, the lock is released and other tabs may then edit/reply to that post.

In browsers without Web Locks, the previous "most recent wins" rule applies.

Replying without being logged in...

I noticed that i can reply without being logged in and it doesn't prompt for for a login.

I noticed that i can reply without being logged in and it doesn't prompt for for a login.

i'm not terribly concerned about that but could maybe be convinced that it's a genuine issue.

How about we add a little warning when replying as the anonymous user?

How about we add a little warning when replying as the anonymous user?

That could work or "reply" could be "replying as anonymous" "or replying as stephan".

It's just not very obvious that you are or are not logged in, as was the case in legacy posting format.

Can the attach button be hidden for those who don't have the proper permissions?

Can the attach button be hidden for those who don't have the proper permissions?

That's what it's supposed to do. If it doesn't then it'll get fixed tomorrow.

Hello:

I have compiled my own version by updating to trunk [cb5edcab0] then running fossil merge forum-editor-2026. fossil status reports: MERGED_WITH 23b69d340b6385.... Then I build using make ....

I use a variation of the Eagle skin from long ago. I define my own head in the skin header. I have:

<link rel="stylesheet" href="$stylesheet_url" type="text/css" media="screen" />

which evaluates to:

<link rel="stylesheet" href="/fossil/demo/style.css/forum?id=bc79c93d" type="text/css" media="screen" />

any idea what's happening here? I am running fossil with a self-signed cert behind the pound load balancer with the latest firefox and brave browsers. I don't think the '/forum?id=bc...' is being added by my stack.

Also I don't see any edit box when I preview the forum on my server when starting a new forum thread. I just see the header and footer. No errors in the dev console.

Also I noticed that the default no-js forum entry is wrapped in noscript tags. If the javascript fails to download, doesn't that mean the user will not be able to post to the forum?

which evaluates to: ... any idea what's happening here?

That looks correct to me. What were you expecting? The name "forum?id=..." after "style.css" is a hint to the skin system that it needs to include the style for the page or feature set named "forum" (a name internally shared by all of the forum-related pages). It might be clearer if you consider that Fossil internally always translates the X part of /anypath/X to /anypath?name=X.

Also I don't see any edit box when I preview the forum on my server when starting a new forum thread.

So /forumnew is just a blank page, correct? Is JS activated or are you expecting the old form here?

Also I noticed that the default no-js forum entry is wrapped in noscript tags. If the javascript fails to download, doesn't that mean the user will not be able to post to the forum?

The idea is that if the JS fails to load, it will simply use the old forms, but my suspicion is that i've confused something with the noscript tag and that the old form is not being rendered in one case. That will be investigated fully today. Thank you for the report.

Just to be clear: is yours a no-js environment? (If so, great - we finally have someone who can test that. :) It's my full intent to keep the forum working with the old forms for such environments.

Can the attach button be hidden for those who don't have the proper permissions?

That is now fixed, thank you (it's not yet deployed here). The check for that was missing one condition, so it was showing you the Attach buttons for posts you own or can admin, but was not actually ensuring that the user has Attach-to-Forum permissions.

Reminder to self: muscle memory keeps expecting me to be able to tap ctrl-enter as a shortcut for Submit, like in /chat and Gemini and mewe and maybe a few other sights. Maybe we ought to add that.

Can the attach button be hidden for those who don't have the proper permissions?

That is now fixed, thank you (it's not yet deployed here). The check for that was missing one condition, so it was showing you the Attach buttons for posts you own or can admin, but was not actually ensuring that the user has Attach-to-Forum permissions.

Reminder to self: muscle memory keeps expecting me to be able to tap ctrl-enter as a shortcut for Submit, like in /chat and Gemini and mewe and maybe a few other sites. Maybe we ought to add that.

Hi Stephan:

If I disable js and reply to message 41, I am asked if I want to remain anonymous. I click through and get a page with header and footer and in the middle I see:

Much to do here.

No editing box. So I re-enabled js.

That looks correct to me. What were you expecting?

I was not expecting forum. I was expecting the ?id= as a cache busting mechanism.

/forumnew is just a blank page, correct? Is JS activated or are you expecting the old form here?

Correct a blank page except for header/footer. JS is turned off. I was expecting the original forum experience with JS turned off.

I use the NoScript plugin for firefox or the native js blocker for brave.

I am currently rewriting my skin on top of the current Eagle skin in case I am doing something stupid.

Also while I was debugging I seem to be seeing the same nonce even after a page reload. Shouldn't it be different on every page reload?

I use the NoScript plugin for firefox or the native js blocker for brave.

Thank you for that tip. Fixes for editing, replying, and attaching in a no-js environment were just checked in. That will fix the editor once it's deployed. Thank you for the feedback!

Also while I was debugging I seem to be seeing the same nonce even after a page reload.

That should probably not happen but is unrelated to the forum changes - the nonce is generated a level above where these changes were made. i'll take a look at that.

Good work! Many, many thanks for rescuing me from that particular rabbit hole.

I got as far as reading the original commit which introduced the draft storage, and cooking up a scheme involving a second bit of storage alongside the draft which corresponds to the original click of the Reply button, call this Me. Checking Me(page storage) = Owner(local storage) tells us if another tab has overwritten our previous draft.

I was already asking myself if my knowledge of JS and the environment inside a Forum page was up to this and getting a No.

Then I noticed a blooper around Reply[Draft] - just as you can get more than one copy of the same 'Reply', the Reply[draft] that just got clicked might not be a singleton, so my original idea of setting Me to Owner is wrong - you need a new Me and overwrite Owner with that. If there is a doppelganger it will find out then next time it saves a draft.

At this point I have an urge to reach for a statechart or even my old CSP book. But instead I will file this away as a possible future case study, and do a Magnussen and say you have started, so I'll let you finish. 😄

Happy to test if needed though - and I will post what I can remember of the notes that went AWOL in a separate message. Z

pushing the limits by trying to make two replies to the same message

That was bound to happen sooner or later, and was foreseen but not "solved"¹.

"The problem" is that the drafts are keyed to the ID of the post in question, so accessing them from two tabs will lose one or the other: the most recent one to lose focus will overwrite the other. The only solution which comes to mind is to use Web Locks to inform the second tab that another tab is opened and that Hilarity Will Ensue if the user attempts to use both at once. However, Web Locks are a relatively new JS addition (only in Safari since late 2024), which makes it too new for our self-imposed requirements of working for browsers at least (about) 5 years old.

It's probably excessive to try to support multiple simultaneous replies

Indeed :).

but maybe use a nonce to spot when the draft you are about to overwrite doesn't match the one on screen?

Patches would be thoughtfully considered.

Minor issues / style points / comments:

I like the dynamic loading idea for retaining the old IU. Better than YAFS.

What determines the content of the Help pane? It would be useful if the site admin or even a user could modify it: this is possible home for things like forum rules and reference material. @sean may like that 🙃.

The behaviour of the Submit and Discard buttons is inconsistent: I like Discard better because it more clearly suggests that it expects something from me. This is only a first time use issue, I wasn't expecting it to do anything but submit the post, and was still thinking what? when the timer expired and it went back to just Submit.

I would have sized the buttons to fit the larger label so they don't move about. Maybe that's just an age thing.

I am unsure of the utility of a Preview button as well as the tab. Screen reader support perhaps?

Reply [draft] and Delete appearing together could be confusing: somebody might think Delete applies to the draft reply rather than the message they are replying to. As this only happens when the user is replying to their own message (I think) maybe it makes sense not to offer Delete until the draft is discarded? As it is, does the draft get binned along with the message if Delete is pressed?

Many thanks Trevor Z

Passing thought: even just for testing, it would be handy if when there is a [draft] button somewhere on a page, there was some means to get directly to it. If it was a floating something that was always visible it doubles as a prod that there is unfinished business in the current thread that the user may have forgotten about, or thought they had already submitted.

Yes, it isn't unknown for me to find an unsent draft in my email weeks or months old.

This is a "last call" for objections before i propose merging the new forum into the trunk. It's now running on this forum and all of its siblings' forums, we've addressed the issues posted so far, are not aware of any glaring open issues, and have not (admittedly to my surprise) heard any fussing about how it's working.

If there are any strong objections to merging the new forum editor and attachments front-end to trunk, please voice them!

ON a couple occasions, when clicking on reply, I'm taken to the legacy forum post. It eventually clears up after a couple refreshes or clicking the /forum link.

Have you encountered that before?

On a couple occasions, when clicking on reply, I'm taken to the legacy forum post. It eventually clears up after a couple refreshes or clicking the /forum link.

Have you encountered that before?

There is a delete button present only when you're replying to your own post/comment.
If you type something (or nothing) into the editor and click delete, you're taking to a "delete reply" page.

I'm not sure if the delete button needs to be present.

when clicking on reply, I'm taken to the legacy forum post. It eventually clears up after a couple refreshes or clicking the /forum link.

i have indeed seen that before a couple of times, but when it happened i'd just used the Back button and blamed it some misinteraction with that. Did you happen to use the back button when you saw that?

In any case, i'll take a close look at those pieces.

If you type something (or nothing) into the editor and click delete, you're taking to a "delete reply" page.

That's a side effect of mixing both the old and the new editor pieces on the same page. The plan is to integrate the deletion into the new form but it's not a common thing to do so it's not been a high priority. The "Status" button, which only shows up for admins in forums which have statuses configured, has the same "problem" (if we can call it that, noting that it's jarring but doesn't break anything), and that one is worked around by disabling that button while the editor is open and plugging a replacement for it into the editor. (The SQLite bugs forum makes heavy use of post statuses.)

Thank you again for the continued feedback!

when clicking on reply, I'm taken to the legacy forum post. It eventually clears up after a couple refreshes or clicking the /forum link.

i have indeed seen that before a couple of times, but when it happened i'd just used the Back button and blamed it some misinteraction with that. Did you happen to use the back button when you saw that?

Edit: another case which can cause the buttons to fall back to The Olde Ways is if the JS part fails to load or if it throws an error while initialzing (in which case buttons after the error will have their legacy behavior). If you see this happen again, please open the browser's dev console (F12 on FF and Chrome/ium) and see if there's an error message. It hasn't happened to me again since before you brought it up, so it's elusive.

In any case, i'll take a close look at those pieces.

No objections, just feedback. One possible bug though: no confirm button when you click Delete.

Not having ever edited or deleted any of my own posts, I explored that.

I had not tried the Delete button before, expecting but not being certain that it would ask for confirmation before acting. It comes up with two boxes Original Post:content and Change Into:Deleted. That's it, other then the 'generated by' footer. No way out of the page that I could find other than Back. On my own repository (running 2.28 unmodified) there are OK and Cancel buttons and some checkboxes which may be there because I am admin for that site.

You can get both Reply and Edit for a post into the draft state via reloading the page. Whichever one you click the other is disabled while the new form is displayed but Delete remains active. It feels natural to me that disabling the 'other button(s)' should include Delete.

disabling that button while the editor is open

Or, if you base the decision on the system state rather than the widgets on the screen, a draft exists. That suggests the Delete button should be disabled if a draft exists, regardless if the form is open.

Related message: , which happens to be an example of somebody replying to their own post.

no confirm button when you click Delete.

The Delete button so far uses the old forms, which i have apparently broken for the Delete case when JS is on (but it works when JS of off). We'll get that fixed very soon.

You can get both Reply and Edit for a post into the draft state via reloading the page.

That won't break anything. It's only disallowed on a single page because it'd be too confusing (for me) to use.

Whichever one you click the other is disabled while the new form is displayed but Delete remains active. It feels natural to me that disabling the 'other button(s)' should include Delete.

As of a few checkins ago, all of those buttons get hidden while editing, rather than picking and choosing ones to get disabled.

That suggests the Delete button should be disabled if a draft exists, regardless if the form is open.

i'm not sure i follow. Why should having a draft prevent deletion?

Related message ...

Passing thought: even just for testing, it would be handy if when there is a [draft] button somewhere on a page, there was some means to get directly to it.

i'll be on the lookout for how such a widget might fit into the UI, but the draft capability is intended to prevent against inadvertent loss via silly things like page reloads or real-world distractions, not to provide a content manager for folks wanting to carefully curate their edits.

no confirm button when you click Delete.

The Delete button so far uses the old forms, which i have apparently broken for the Delete case when JS is on (but it works when JS of off). We'll get that fixed very soon.

Edit: that's now fixed but not yet deployed. How best (or whether) to integrate Delete into the New World View is TBD. It's an infrequent and drastic operation¹ and there arguably should be some small discomfort in the process of going through with it.

You can get both Reply and Edit for a post into the draft state via reloading the page.

That won't break anything. It's only disallowed on a single page because it'd be too confusing (for me) to use.

Whichever one you click the other is disabled while the new form is displayed but Delete remains active. It feels natural to me that disabling the 'other button(s)' should include Delete.

As of a few checkins ago, all of those buttons get hidden while editing, rather than picking and choosing ones to get disabled.

That suggests the Delete button should be disabled if a draft exists, regardless if the form is open.

i'm not sure i follow. Why should having a draft prevent deletion?

Related message ...

Passing thought: even just for testing, it would be handy if when there is a [draft] button somewhere on a page, there was some means to get directly to it.

i'll be on the lookout for how such a widget might fit into the UI, but the draft capability is intended to prevent against inadvertent loss via silly things like page reloads or real-world distractions, not to provide a content manager for folks wanting to carefully curate their edits.

Whichever one you click the other is disabled while the new form is displayed but Delete remains active. It feels natural to me that disabling the 'other button(s)' should include Delete.

As of a few checkins ago, all of those buttons get hidden while editing, rather than picking and choosing ones to get disabled.

That suggests the Delete button should be disabled if a draft exists, regardless if the form is open.

i'm not sure i follow. Why should having a draft prevent deletion?

It's not about preventing deletion, but rather avoiding possible confusion / mistakes (even though of the harmless kind). I'm thinking particularly of the case where somebody is recovering from an 'event' and gets to the screen where the new form is yet to appear. From the perspective of someone (like me a few days ago) who doesn't have a lot of experience of posting more than the odd reply the mention of the saved draft in conjunction with Delete at leasts suggests it might apply to the draft.

The feeling I have about this may be similar to yours when you say:

You can get both Reply and Edit for a post into the draft state via reloading the page.

That won't break anything. It's only disallowed on a single page because it'd be too confusing (for me) to use.

It may depend on what you think happens when you press it. I would not try to show both the reply and edit at once, but rather treat the buttons as almost tabs, i.e. switch between the two drafts. That may also be a suggestion for the future cleaned up interface: the Delete button could use the 'new' form to display what is currently put on a new page.

Use case for this BTW: I may well edit a post of mine and at the same time post a reply to explain why I did what I did. That isn't just because I sometimes miss an interesting edit: having checked my settings I realise 'All Forum Posts' may not include 'Edits to Forum Posts' so I have ticked that as well.

Best wishes, Trevor

Stephan/Joergen,

The new fossil forum is great and we are using for it a larger project set so thanks to everyone. At the risk of reopening something that shouldn't be Quickfilter type functionallity to the Forum/Bugs thing would be be useful, e.g. search for all subjects with DOE in them.

Now for the repo directory this was rejected, fair enough but it seems critical for a bug list (or perhaps not).

I know it's already merged (and works quite nice) and I hope it's not too late for a little reminder from the distant past: forking thread on reply. Maybe it could be implemented in the new UI?

forking thread on reply... Maybe it could be implemented in the new UI?

The "real work" involved with that has little to do with the UI, actually - the effort would be approximately equivalent for both UIs. The forum thread view would be disrupted a bit because it would need to know where to placeholders marking fork points. One complication is that (because this is a distributed system) we cannot enforce only a single fork - any number of replies could be forked off from a given post. (Most pressingly, though, we'd need to come up with a term other than "forked", because forking is something different in fossil parlance.)

It's not been forgotten, but energy and motivation to add it has yet to appear :/.

I've just had my first encounter with the new editor and i'm a big fan!

Like this earlier post, i liked the ability to login via the Reply button, but its lack is not a serious problem.

What i really wanted to give feedback on is the default-skin styling for non-selected tab buttons, ie. their grey text. I've been conditioned through the years to regard greyed button text to mean "disabled". Just looking now, i see that "Submit" is also greyed out because it is currently disabled.

I'm not sure what a better look for tabs would be. Changing size (text and border)? Extra bolding/underlining/italicising(/blinking?!)? Setting a different background colour?

I feel a little funny about bringing this up because i have no skill at styling and taste is such a subjective thing. I'm only just re-entering the world of webpage building and plan on putting a nice and cheesy "under construction" banner on the homepage. :)

I feel a little funny about bringing this up because i have no skill at styling...

Welcome to my world (as the one who did the tabs) :). Any suggestions or patches for improving the tab styling will be joyfully received. No blinking or pulsing or rotating, though (css can do all of that now) :).

I feel a little funny about bringing this up because i have no skill at styling...

Welcome to my world (as the one who did the tabs) :). Any suggestions or patches for improving the tab styling will be joyfully received. No blinking or pulsing or rotating, though (css can do all of that now) :).

Edit: failed to notice (again) that my tablet was logged out. Need to make the "you are anonymous notice somewhat more prevalent.

i liked the ability to login via the Reply button, but its lack is not a serious problem.

When replying when not logged in, a warning now appears just above the editor field with (A) a link to the login page and (B) a reminder that any edits made before logging in will be retained in a client-local draft (i.e. they won't be lost).

That's not yet deployed but will be soon.

Need to make the "you are anonymous" notice somewhat more prevalent.

Suggestion: instead of a label which looks like a button but isn't, what about changing the label on Submit? Maybe just the text when you click it, i.e. 'Confirm submit as anonymous...'

Caveat: I don't use a phone for this, so I'm guessing what this would look like there.

Suggestion: instead of a label which looks like a button but isn't, what about changing the label on Submit?

That's not a bad idea at all. Let me play with that. My only current concern is...

Caveat: I don't use a phone for this, so I'm guessing what this would look like there.

A large portion of my forum-going is on a tablet or phone, and those buttons would be arbitrarily long, so they might be cramped.

Even so - something with trying out, thank you for the suggestion.

Suggestion: instead of a label which looks like a button but isn't, what about changing the label on Submit?

That's not a bad idea at all. Let me play with that. My only current concern is...

Caveat: I don't use a phone for this, so I'm guessing what this would look like there.

A large portion of my forum-going is on a tablet or phone, and those buttons would be arbitrarily long, so they might be cramped.

Even so - something worth trying out, thank you for the suggestion.

Edit: that's now checked in and takes up less space than before. It will show up here the next time the fossil binary is deployed.