Discussion:
Syntax Highlighting
(too old to reply)
Lester L. Martin II
2018-06-26 18:02:17 UTC
Permalink
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
Offray Vladimir Luna Cárdenas
2018-07-04 00:12:47 UTC
Permalink
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
Post by Lester L. Martin II
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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Lester L. Martin II
2018-07-04 14:30:05 UTC
Permalink
Post by Offray Vladimir Luna Cárdenas
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.
Offray,
Not only did I do that, I went ahead and created 2 patches for
Fossil.

The first one enabled syntax highlighting in general however
syntax highlighting engines would have been broken when line numbering
came into play.

The second patch got syntax highlighting with line numbers working and
provided a way for the theme to handle when JS for line numbering and/or
highlighting is enabled/called.

See the other Syntax Highlighting related emails by me for more info.

For the JS source that enables line numbering see:
https://code.amlegion.org/hljs_line_numbers/ (Fossil repo with it)

For a showcase of it doing its job and doing it well since I've recently
got it up to par with the C source's selection code:
https://code.amlegion.org/hljs_line_numbers/

The home page gives some links to test selection with line numbering,
multi-selection, and scroll to top. As time permits I'll also create
(and link to from the home page) wiki documents describing the setup
of this for one's own Fossil Repo.

Feel free to help me improve the documentation as to doing this.

--
Lester L. Martin II
John P. Rouillard
2018-07-04 15:03:21 UTC
Permalink
Post by Lester L. Martin II
https://code.amlegion.org/hljs_line_numbers/ (Fossil repo with it)
For a showcase of it doing its job and doing it well since I've recently
https://code.amlegion.org/hljs_line_numbers/
The home page gives some links to test selection with line numbering,
multi-selection, and scroll to top. As time permits I'll also create
(and link to from the home page) wiki documents describing the setup
of this for one's own Fossil Repo.
There is something odd happening with the history buffer. Start at:

https://code.amlegion.org/hljs_line_numbers/

click on "Single line selection". You end up at:

https://code.amlegion.org/hljs_line_numbers/artifact?udc=1&ln=on&name=b5869c31fbae9ca0#L2

bur rather than 2 items in the history, there are 4 items in my
history:

4 https://code.amlegion.org/hljs_line_numbers/artifact?udc=1&ln=on&name=b5869c31fbae9ca0#L2

3 https://code.amlegion.org/hljs_line_numbers/artifact?udc=1&ln=on&name=b5869c31fbae9ca0#

2 https://code.amlegion.org/hljs_line_numbers/artifact?udc=1&ln=on&name=b5869c31fbae9ca0#L2

1 https://code.amlegion.org/hljs_line_numbers/doc/trunk/README.md

I have to hit the back button 3 times to move back to the original page.
It looks like URL's 2 and 4 are the same.

Any idea what's happening here?

Have a great day.

--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
Lester L. Martin II
2018-07-04 15:20:53 UTC
Permalink
Post by Lester L. Martin II
https://code.amlegion.org/hljs_line_numbers/
https://code.amlegion.org/hljs_line_numbers/artifact?udc=1&ln=on&name=b5869c31fbae9ca0#L2
bur rather than 2 items in the history, there are 4 items in my
4
https://code.amlegion.org/hljs_line_numbers/artifact?udc=1&ln=on&name=b5869c31fbae9ca0#L2
3
https://code.amlegion.org/hljs_line_numbers/artifact?udc=1&ln=on&name=b5869c31fbae9ca0#
2
https://code.amlegion.org/hljs_line_numbers/artifact?udc=1&ln=on&name=b5869c31fbae9ca0#L2
1 https://code.amlegion.org/hljs_line_numbers/doc/trunk/README.md
I have to hit the back button 3 times to move back to the original page.
It looks like URL's 2 and 4 are the same.
Any idea what's happening here?
Have a great day.
Hey Mr. Rouillard,

I bet I know what that is. The code uses window.location.hash to
establish where the URIs will link to by doing something that is
partially destructive. Something like:

var uri = window.location;
var old_hash = window.location.hash;
window.location.hash = "";
uri = window.location.href;
window.location.hash = old_hash;

So now I need to figure out how to reset history to where it should
be after those operations. I'm welcome to ideas (that I'll review
later on and push up a fix to the repo and then pull into the
static files for my repos so that it can be tested.)

Thanks for letting me know this, I'm by far not great at JS and
am subject to making a myriad of mistakes by not looking for things
that would be as non-obvious as this due to the side effect being
far elsewhere than related easily to the operations of the code
at hand.

--
Lester L. Martin II
John P. Rouillard
2018-07-04 15:53:54 UTC
Permalink
Post by Lester L. Martin II
Post by Lester L. Martin II
https://code.amlegion.org/hljs_line_numbers/
https://code.amlegion.org/hljs_line_numbers/artifact?udc=1&ln=on&name=b5869c31fbae9ca0#L2
bur rather than 2 items in the history, there are 4 items in my
4
https://code.amlegion.org/hljs_line_numbers/artifact?udc=1&ln=on&name=b5869c31fbae9ca0#L2
3
https://code.amlegion.org/hljs_line_numbers/artifact?udc=1&ln=on&name=b5869c31fbae9ca0#
2
https://code.amlegion.org/hljs_line_numbers/artifact?udc=1&ln=on&name=b5869c31fbae9ca0#L2
1 https://code.amlegion.org/hljs_line_numbers/doc/trunk/README.md
I have to hit the back button 3 times to move back to the original page.
It looks like URL's 2 and 4 are the same.
Any idea what's happening here?
Have a great day.
Hey Mr. Rouillard,
I bet I know what that is. The code uses window.location.hash to
establish where the URIs will link to by doing something that is
var uri = window.location;
var old_hash = window.location.hash;
window.location.hash = "";
uri = window.location.href;
window.location.hash = old_hash;
So now I need to figure out how to reset history to where it should
be after those operations. I'm welcome to ideas (that I'll review
later on and push up a fix to the repo and then pull into the
static files for my repos so that it can be tested.)
Maybe:

https://stackoverflow.com/questions/8969878/in-javascript-how-do-i-clear-the-back-history-1

which offers:

window.location.replace("path/to/target/page");

as way to fix?

Have a great day.

--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
Loading...