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
head:
<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
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
