Long ago, a wysiwyg editor was added to the wiki but has, to the best of my knowledge, not been maintained and may even currently be completely unused.

It's now a topic because i'm starting work on the Ajax-powered version of the wiki editor and, to be honest, don't really want to have to integrate that bit into it :/.

If you happen to use that component, can you please let us know? If nobody claims to still be using it, it will very likely disappear during the Ajax-based editor port.

Hi Stephan,

I'm pretty interested in Wysiwyg wiki editing, mainly for my students with no tech background, but I have not used it (as semester is over here).

Thanks for your work the Ajax one and for making Fossil more (non tech) user friendly. Once it is done, let me know. I hope to have a little more time to test it at the end of August (yep... that long).

Cheers,

I've never liked the look of the default editor but did add support for Trumbowyg in a repository once. It was fairly easy to do (just modifying the Skin's scripts to add it in, with the javascript of the actual editor stored as a wiki attachment), but took a bit more TH1 scripting to scope it in the correct places (ticket/wiki/etc. edit pages).

I've never liked the look of the default editor

That one's just a plain textarea element. That part isn't changing, but the new implementation provides, like /fileedit, an API which enables clients to replace that widget with their own. See the bottom section of:

https://fossil-scm.org/fossil/doc/trunk/www/fileedit-page.md

for what that looks like. The wiki editor's counterpart API works the same.

As I recall, that editor is an HTML editor. That's the most likely reason for me to not use it.

A few years ago, when a friend was looking for a quick and easy wiki solution, I offered to set up a Fossil repository on my server, where he could use Fossil's wiki functionality. Not being very tech savvy, he routinely used the WYSIWYG editor. I think it actually was that (and the ease of setup) that convinced him, though he did run into a few problems with it (most notably problems with handling multibyte characters -- his wiki is mainly about Buddhism, and contains quite a few words from the pāḷi language).

I didn't have time to read this forum for the past fews months, and it's only just now when I updated that server's version of Fossil, that I noticed the WYSIWYG editor had disappeared.

Does anybody know of an easy way to restore it, or implement an alternative one?

My quickest workaround for now is for him to run an older version of Fossil locally, and use its WYSIWYG editor, then sync with the server.

Otherwise, I completely understand the decision. An HTML editor never struck me as being a necessary part of a version control system, and a wiki editor should generate wiki (or Markdown) code, preferably not HTML. :-)

Does anybody know of an easy way to restore it, or implement an alternative one?

There is currently neither, but a seemingly workable solution is described below. The new wiki editor has an API hook which will allow a user to plug in their own editing widget via the skin, but it's only been tested as a proof of concept, not in a real-world setting. See the bottom-most section of the fileedit docs - the wiki API for that is identical.

If that looks like it might be an option for you i'd be interested in helping to get that working, as that would give me an excellent opportunity to try out that API and hammer on it if needed. If so, go find us a suitable 3rd-party wysiwyg widget and i'll see if i can get it talking to the editor.

Looking at TinyMCE:

https://www.tiny.cloud/docs/general-configuration-guide/use-tinymce-classic/

Notice that the setup essentially amounts to:

tinymce.init({
  selector: 'textarea#wikiedit-content-editor'
});

i just tinkered with this on their demo site, and tinymce hides the original textarea and replaces it with its own widget. That means that wikiedit cannot simply access the wiki page content via its own handle to the textarea.

That's okay, though, because what the "content hook" API allows a user to do is tell wikiedit and fileedit how to fetch and set content from/in a custom widget. That demonstrated in the fileedit docs, and would hypothetically look something like the following for tinymce:

(Untested on a fossil installation, but derived from playing with the tinymce demo in the browser's dev tools...)

(In your fossil skin's footer, near the bottom...)

if(document.body.classList.contains('wikiedit')){
  // ^^^^ the new fossil pages tag the body with that page's name
  window.fossil.onPageLoad( function(){

    // tinymce init:
    tinymce.init({selector: 'textarea#wikiedit-content-editor'});

    // Now the fossil-specific bits:
    const widget = tinymce.get('wikiedit-content-editor'/*element ID w/o '#'*/);
    fossil.page.setContentMethods(
      function(){return widget.getContent()},
      // ^^^^ get custom content (e.g. when saving)
      function(content){widget.setContent(content)}
      // ^^^^ set custom content (e.g. when loading a new page)
    );
  })/*end of onLoad handler*/;
}

That "should", unless i've made some typos, allow wikiedit to communicate the content back and forth between itself and the custom widget.

That's all fine and good, but there is one missing piece which i simply overlooked in the design, and that is how to tell wikiedit that the custom editor has triggered the equivalent of a "change" event. Without that, the wiki editor won't let you save because it thinks there have been no changes. (Despite other developers' objections, i firmly believe that it should not allow saving when it knows there cannot be any changes, but that admittedly backfires on me in this special case.)

If you want to try out the above and report back, i can look for a solution handling the custom widget's on-change situation. i have a really silly workaround, i think, which wouldn't require any changes to fossil, by simply translating tinymce's custom change event to a change event for the builtin textarea. Something along the lines of...

  // Add this to the above onPageLoad handler...
  const ta = document.querySelector('#wikiedit-content-editor');
  widget.on('blur', function(){
    if(widget.isDirty()) ta.dispatchEvent(new Event('change'));
  });

That "should", whenever tinymce's widget is blurred, trigger a change event on the original textarea widget. That, in turn, because of an internal event handler, will set the "is-dirty" flag on the app and cause the editor to "stash" your local edits into the browser's localStorage so that they don't get lost.

Sidebar: TinyMCE also has a "change" event, but it fires far more often than the docs say it does. You could connect to that but it would stash your changes after every press of the Enter key (feature or bug? yes).

Got all that?

Otherwise, I completely understand the decision. An HTML editor never struck me as being a necessary part of a version control system, and a wiki editor should generate wiki (or Markdown) code, preferably not HTML. :-)

The wysiwyg editor was also ancient and effectively unmaintained because none of the developers use it (or none who piped up in this thread), nor did we ever get any mail/forum traffic about it.

PS: tinymce download is kinda hidden so that they can better push their cloud service:

https://github.com/tinymce/tinymce

PS2: the fileedit docs say the client should also call replaceEditorWidget(), but that's not needed in this case, as tinymce does that part. Whether or not that works perfectly in our setup remains to be seen, but i'm optimistic that it will.

(Ooops - silly user error caused me to overwrite my post with edits. This is a re-post cobbled together from the email notification content...)

Spoiler alert: it's alive!

https://fossil.wanderinghorse.net/screenshots/fossil-wikiedit-tinymce.png

if(document.body.classList.contains('wikiedit')){

It turns out that triggers too early, but i've now got a proof of concept on my machine and it can transfer edits between tinymce and the local edit stash, save and load, as if tinymce were "properly integrated." It's ugly because the JS tries to load several external CSS files which it can't reach because of CSP, but the setup looks like this...

Add this to the bottom of the skin footer, changing the paths/names to/of the JS/CSS files as appropriate:

<link href="$<home>/doc/ckout/skin.min.css" rel="stylesheet" type="text/css">
<link href="$<home>/doc/ckout/content.min.css" rel="stylesheet" type="text/css">
<script src='$<home>/doc/ckout/tinymce.min.js'></script>
<script src='$<home>/doc/ckout/theme.min.js'></script>
<script src='$<home>/doc/ckout/icons.min.js'></script>
<script nonce="$nonce">
if(window.location.pathname.indexOf('wikiedit')>0){
  window.fossil.onPageLoad( function(){
    tinymce.init({selector: 'textarea#wikiedit-content-editor'});
    const widget = tinymce.get('wikiedit-content-editor'/*element ID w/o '#'*/);
    fossil.page.setContentMethods(
      function(){return widget.getContent()},
      function(content){widget.setContent(content)}
    );
    const ta = document.querySelector('#wikiedit-content-editor');
    widget.on('change', function(){
      if(widget.isDirty()) ta.dispatchEvent(new Event('change'));
    });
  })/*end of onLoad handler*/;
}
</script>

So... if you can get a clean installation of tinymce then you can get it working with the current trunk version.

Sidebar: "Tiny"MCE my buttox: the minified core JS is 398k and it won't even display without also loading theme.min.js, which is another 407k. Then there's another 59k in icons.min.js and 60k in 2 CSS files.

That demonstrated in the fileedit docs, and would hypothetically look something like the following for tinymce:

The wikiedit/fileedit code was just updated to plug the "leaky abstraction" of connecting to the original textarea change event, and the fileedit docs (the very bottom section) now includes the simplified skin footer code needed to plug in TinyMCE (as an example, though this "should" work with any widget which can pass its content around in plain text format). Those docs reflect the trunk, though - for 2.12 and 2.12.1, the "ugly" event-refire option shown in a previous post is needed in order to tell wikiedit that the 3rd-party widget modified the doc.

If you try that, or something equivalent, out on your friend's environment, please let us know how it worked (or didn't work).

Looking at TinyMCE

That's primarily an HTML-backed editor, so I assume that works by emitting only the subset of HTML that Fossil Wiki supports?

If so, doesn't that have some undesirable side effects, like efficient [abcd1234 | link text] links needing to be expressed as less-efficient <a href="/info/abcd1234">link text</a> because the editor doesn't understand that it's actually writing for a wiki syntax, which gives Fossil's internal linking facilities some extra power?

You might even have to enable Admin → Wiki → "Use HTML as wiki markup language" to avoid syntax interpretation problems, such as with literal square brackets, asterisks, etc.

It looks like there's a Markdown syntax for TinyMCE, but then you want a way for the Fossil wiki editor to default to Markdown syntax. I suppose the JS init code could switch the <select> setting...

Understand, I've never used the WYSIWYG wiki editor. I'm just tossing out some thoughts and worries on behalf of those who might care about this change.

That's primarily an HTML-backed editor, so I assume that works by emitting only the subset of HTML that Fossil Wiki supports?

Every wysiwyg editor is full of undesired side effects :/. Presumably anyone who wants to use one knows they either have to somehow limit it (or themselves) to fossil's dialect or enable the "allow all HTML" option.

It looks like there's a Markdown syntax for TinyMCE, but then you want a way for the Fossil wiki editor to default to Markdown syntax. I suppose the JS init code could switch the <select> setting...

We could certainly consider moving markdown format to the top of the selection list so that it becomes the effective default, but i initially avoided doing so for consistency with the older editor.

One problem with JS side markdown editors is that their dialects will differ, however slightly, from ours and users will waste time tripping over/fighting with those differences. The ones i have tried out before (about a year ago) did not allow customizing the link handlers, so none of them allowed me to intercept fossil-style links to rewrite them for preview/wysiwyg purposes.

Understand, I've never used the WYSIWYG wiki editor.

That's most of us.

I'm just tossing out some thoughts and worries on behalf of those who might care about this change.

To me the activation of a 3rd-party component can be considered a "back door" which "voids the warranty." That is, it's there for those who really feel the need to make use of it, but what it injects into their repo is their own responsibility.

If someone who prefers wysiwyg wants to customize one for fossil we could look at including it as an option, but the one we just removed is, IMO, far too old/obsolete to put back in.

Every wysiwyg editor is full of undesired side effects

I assumed that the old Fossil WYSIWYG editor knew Fossil's internal characteristics and so emitted only markup that Fossil Wiki would correctly interpret, and that its clickable affordances mapped cleanly to Fossil's Wiki dialect interpretation.

It was coded specifically for Fossil, was it not?

I assumed that the old Fossil WYSIWYG editor knew Fossil's internal characteristics and so emitted only markup that Fossil Wiki would correctly interpret, and that its clickable affordances mapped cleanly to Fossil's Wiki dialect interpretation.

That's my understanding. Looking at the code, its range of tags appears to have been encapsulated in these few selection lists:

https://fossil-scm.org/fossil/info?name=f0d9c244cac6fbe2&ln=59-93

That feature, sans the actual integration into the wiki page, was encapsulated in that one file, should anyone listening in care to pull it back in:

https://fossil-scm.org/fossil/finfo?name=src/wysiwyg.c

And here's the commit where it was removed, so all of the relevant integration code is on the left side of the diff:

https://fossil-scm.org/fossil/info/336afe8e91294517

(Which is kinda funny because what's on the "left" side is what was "left" behind but it's clearly not what's "left" over (go home, English, you're drunk!).)

Hypothetically it would require about an hour's effort to port that into an optional JS file which could be plugged in to the wiki editor using the same approach as the TinyMCE demo. That's not me volunteering, but it's also not me ruling eventually volunteering for that out. (The only minorly painful part of doing the port would be moving the HTML into JS, as the new editor-injection API has no way of integrating external HTML, only JS. A few emacs macros should make short work of it, though.) Hmmm... (as if i need another pet mini-project, but #TheAddictionIsReal).

That's not me volunteering, but it's also not me ruling eventually volunteering for that out.

i locally have this working, but the legacy editor's ability to flip in and out of HTML/text modes is causing round-trip wikiedit<==>wysiwyg conversion havoc which i am not yet sure how to resolve.

http://fossil.wanderinghorse.net/screenshots/fossil-wikiedit-wysiwyg-legacy.png

Though it's functional, it currently mangles the page (too much escaping) once it's been flipped between edit modes, so i won't check it in just yet.

The old WYSIWYG editor was just some code I copied from the Mozilla website.

Another possibility is writing a fossil mode for https://prosemirror.net/.

Also https://codemirror.net/ could be programmed for fossil style markup. It already has github markdown mode. It is more of a WYSIWYM than WYSIWYG editor.

Since both of these editors are meant to be customized it may help with the mismatch Stephan noted between the markup implemented by fossil and wysiwyg editors for markdown etc.

I expect these would be able to be plugged in by editing the skin and not require changes to fossil core.

Noob here, apologies if this is redundant, I did not see anything on the wiki or recent forum posts about the protocol of private messaging users.

I have a couple of questions about a usecase for Fossil that might not be on topic for this forum.

What is the proper protocol for private messaging Stephan (or others) that have dev experience and might be open to a brief discussion?

Thank you kindly.

I did not see anything on the wiki or recent forum posts about the protocol of private messaging users.

Doesn't exist. Private messaging was discussed when the forum was first created but I don't recall anything being created out of the discussions. I believe Stephan's email address is on his website.

Aha, perfect. Thanks. Apologies for the off topic.

What is the proper protocol for private messaging Stephan (or others) that have dev experience and might be open to a brief discussion?

My contact details are all public over at:

https://wanderinghorse.net/home/stephan

With the caveat that i'm currently house-training a puppy and working an early-morning job, a combination which leaves me with little energy left over for other stuff, so i may not be as responsive as usual.

Hi, I only just now when I updated my local server's version of Fossil, that I noticed the WYSIWYG editor had disappeared.

Does anybody know of an easy way to restore it, or implement an alternative one?

My quickest workaround for now is to stay run an older version of Fossil locally, and use its WYSIWYG editor.

Does anybody know of an easy way to restore it, or implement an alternative one?

You're a bit late to the party on this one - the legacy editor is not (as of this writing) coming back as a supported feature and you're only the second person to have expressed any grief at its disappeance. However, the wiki editor has a "back door" which allows clients to replace its editor widget with one of their own, and a copy of the legacy editor is provided as an example of doing so.

See /forumpost/1a40af283e (response above) and try the SCRIPT snippets from that page (put them at the bottom of your skin's footer). That "should" do the trick, but i honestly haven't tested it since way back then and "something" "might" have changed since then. It "might" work, though.

See also the "Integrating a Custom Editor Widget" section at the bottom of:

fossil:/doc/trunk/www/fileedit-page.md

Search that page for "wikiedit" to quickly jump to the right section.

See also the responses leading up to the post linked to above.

My quickest workaround for now is to stay run an older version of Fossil locally, and use its WYSIWYG editor.

The legacy editor is not coming back unless someone (not me) volunteers to do the work of integrating it as an easily-accessible option, so staying on an older version just for that editor is (probably) a long-term losing strategy.

Edit: the post this one responds to might be a bot. Its entire text, it turns out, is ripped verbatim from Martijn's post above (/forumpost/f028a8a90e). So... something to be on the lookout for when moderating future posts. Sigh.

The legacy editor is not coming back unless someone (not me) volunteers to do the work of integrating it as an easily-accessible option, so staying on an older version just for that editor is (probably) a long-term losing strategy.

For a sufficiently long definition of "long-term" that could be true, but as long as the fossil file format doesn't change significantly, it seems like a reasonable long-term work around if one just wants to wysiwyg editing for themselves and is happy to push that to a more current, up to date fossil.

Hi Stephan,

And thanks about your answer. I foloewed this steps to activate the "Legacy Wysiwyg Editor in /wikiedit..." and worked fine to me.

See /forumpost/1a40af283e (response above) and try the SCRIPT snippets from that page (put them at the bottom of your skin's footer). That "should" do the trick, but i honestly haven't tested it since way back then and "something" "might" have changed since then. It "might" work, though.

PS: I'm not a Bot.

I was reading today, about the lawyer who got caught in a video-court session with a cat filter he couldn't turn off, the statement "I am not a cat is exactly what you'd expect a cat pretending to be a lawyer to say."

PS: I'm not a Bot.

Then for future posts, please do not rip your text 100% verbatim from other peoples' posts. Had i noticed that before approving your post i'd have deleted it on the assumption that you're a cat bot.