On 2018-06-28 11:07, Chad Perrin wrote:
On Thu, Jun 28, 2018 at 10:40:19AM -0500, Lester L. Martin II wrote:
I've developed a way to do highlighting with line numbering...
The issues are as follows however:
1. The JS code responsible for the highlighting is external to Fossil
itself.
2. The JS code highlights <pre><code> blocks, so if there is a
`<pre><code>$line</code><code>$line2</code></pre>` each code block
is
highlighted individually.
3. Context is lost between code blocks.
Each line gets wrapped in a separate code block because you can use
css to insert a line number vs manually inserting the line number via
code per line.
That said, if you have a comment block `/* comments */` broken up over
a few lines, it won't apply the comment coloring to the lines
in-between when line numbering is enabled. Thus, I'd consider that
while it half works, such is inherently broken unless we decide to
depend upon a certain JS library to handle highlighting.
I think a cleaner approach, though it might take a bit of rewriting for
file display, would use an HTML table, possibly assembled by
JavaScript.
Note that I'm feeling a little dirty for suggesting this; it's
something
that could also reasonably be done server-side, though it would
probably
require using something server-side for the syntax highlighting, too.
Server side syntax highlighting is an excellent idea, though I'm not
quite sure at this time how to implement it. The other issue with such
being that fossil would basically need to cache the results of running
a highlight for the liftime of the program up until something
invalidates the cache. Line numbering does/will need serious work to
integrate with syntax highlighting regardless of the approach.
See if this makes sense:
Apply syntax highlighting to a block of code. Organize the code in
second column TD elements of a table. Organize line numbers in first
column TD elements of a table.
Thus, you would have HTML for a line of code that looks something like
this (using a totally made-up function as example code):
<tr>
<td class="line-no">$num</td>
<td class="code-line">
<span class="color-type">uint16_t</span> <span
class="color-label">get_next</span><span class="color-delim">()
{</span>
</td>
</tr>
Basically how GitHub and several other things implement it.
Of course, that's just off the top of my head. I don't actually know
how the HTML resulting from application of the syntax highlighting code
would look in this case. The upshot, though, is that applying syntax
highlighting to the code to be displayed first, then organizing it into
table cells with number cells, might avoid JS syntax highlighting
issues
with line numbers, including any issues around multiline highlighting.
The downside is that it would result in either having to do all line
numbering in JS or applying syntax highlighting server-side.
The issue with just applying highlights first is how will line endings
be tracked since html elements need not necessarily be rendered
similarly
by all highlighting libraries. Detecting line endings in a generic way
after markup has been applied will be very difficult and likely library
specific. I keep using Prism.js as my goto for illustration but I would
bet that the differences between hljs and prism are enough that the JS
needing to be written to (hopefully) detect marked up line endings
between them would be different and we get into a "supports $library"
case vs a generic case like it has been so far without syntax highlights
and how it'd remain if we didn't go forward with syntax highlighting
when lines are numbered.
We still would end up depending on the "Line numbers" checkbox being
a call into JS to add those in for everything but the server-side
case. I'd rather not have to write JS to try to target 2 different
highlighting engines (or possibly more dependent upon what other
users prefer). Then that means that we'd need to check the JS code
written against say... the latest 3 versions of each highlighting
engine in our "support list". At that point it could be said that our
hold ups in deploying a new version are tied up in making sure
integration with several external resources will move along properly.
We'd also get into a case of saying "supports up to $version_number
of this library" (and more of those statements for other libraries
supported). At this point I came to the conclusion it's a huge
undertaking and would require extensive long term management, and
believe at that point, it might be best to "bless" a certain syntax
highlighting library and forgo anything else. If that library was
included in fossil, then wouldn't need to worry about having to possibly
push a fix to allow the newest version to work.
So so far I see 4 "valid" options:
1. Move towards server side highlighting implementing a caching
mechanism.
2. Chase multiple versions of differing libraries and maintain our
own JS that either calls the library's line numbering function
or uses our own stuff to afix numbering after the other has been
done.
3. Bless a certain highlighting library and/or version of that library
with possible inclusion into fossil itself or a vivid notice that
only $version is supported at this point in time.
4. Relegate line numbering with syntax highlighting to a no go.
Of course we could implement our own JS (or C based) highlighting code
though I consider that a grand deal of effort that even I wouldn't
feel comfortable undertaking with either of the mentioned languages.
--
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
