Recently I had the pleasure of succeeding in enabling syntax highlighting. Even with that success I still found some things that could make the process easier
and more robust.

One major issue would be that fossil by default inserts the following in the

<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: 'unsafe-inline'">

This is fairly prohibitive towards trying to get outside resources included so as to allow syntax highlighting. The solution? Download jquery, highlightjs, and a CSS file to the directory that fossil server is serving up and tell it with the "--files" glob pattern to serve those sorts of files. Even so, I understand
it's perhaps useful when running as it's own http server during local
development but truthfully when ran with say the "--scgi" parameter I'm unsure that it does any good setting things that can be set in headers by the http server that is proxying it. In my case I use nginx and had my own set of CSP headers defined that I use across quite a few different resources. This confused
me for a good minute when trying to use a CDN for highlightjs.

The next major issue is that the "Artifact Content" pages use
"<blockquote><pre>" instead of "<pre><code>". This means that there are quite a few syntax highlighting tools that will absolutely not work. These tools insist on the latter (think prism.js). Luckilly highlightjs doesn't insist. Regardless, even if its "<blockquote><pre><code>", utilizing "<pre><code>" would be far better. I've looked at the function in "src/info.c" and I also notice one other area where this could be improved if it were to move to "<pre><code>". The function already knows the file name and thereby could ascertain the file's extension quite easily. That said, say the file name is "bla.lua", it could detect the extension "lua", and set the class of the code block to it like
"<pre><code class="lua">".

Having the ability to utilize syntax highlighting would greatly enhance fossil and I'd love to see the previous paragraph's proposal implemented because most syntax highlighting detection engines will be more than horribly incorrect (I've
played with highlightjs and have had nothing but incorrect detection).

Finaly, I'd love to contribute, and had thought to go ahead and write a probably horrible patch considering I haven't read the entirety of the code base and am ultimately not up to speed with the project from a programming perspective. I saw on the site that a contributors agreement is needed but I also didn't see a way to submit the agreement even if I did fill it out. I at the moment believe someone other than myself could implement this feature correctly and less horribly than I could before I could manage to appropriately submit such an agreement. Even so, I'd like to get a contributors agreement on file so if
anyone can help with that.

Lester L. Martin II
fossil-users mailing list

Reply via email to