Lester, Thanks a lot for your efforts in that front. I'm planing into extending Fossil with Lua using javascript, so the steps you describe here are pretty useful (maybe they could be collected in some of your public repositories that serve as a showcase of your Fossil customizations). It will be my first attempt on that front and I need to finish some other stuff before, but I will try do document it as well.
Cheers, Offray On 26/06/18 13:02, Lester L. Martin II wrote: > 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 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
