On Thu, Jun 28, 2018 at 12:11:11PM -0500, Lester L. Martin II wrote:
> On 2018-06-28 11:07, Chad Perrin wrote:
> >
> > 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.
Yeah, that'd probably be more work overall, and would likely reduce the
customization for syntax highlighting allowed to people deploying Fossil
repositories to the web. It would make how line numbering and syntax
highlighting integrate much more "deterministic", though, in that Fossil
devs would have a clearer view of everything that happens when trying to
account for it in updates to Fossil source. It's a trade-off, as with
most such decisions.
> >
> > 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.
I guess my intuition about how to handle it is in good company, for some
definition of "good".
> >
> > 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.
If you mean that syntax highlighting libraries might insert literal
newlines into the file when marking it up for highlighting, that's
pretty awful, and could indeed screw up the whole exercise.
>
> 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.
This pretty much makes the detriments of a server-side approach that I
described earlier apply to the client-side approach, too. There are
other concerns that apply to the server-side, too, though, such as the
fact I suspect more rewriting of Fossil source would be required, though
I'm just guessing at this point. I'm beginning to think that the best
approach might be to ship a JS syntax highlighting library with Fossil,
or just bless a single library, and allow people deploying their own
repositories to the web to monkey with that at their own peril, in the
short term. Building in some server-side syntax highlighting with the
ability to ignore that and use client-side of one's own choosing (again
at one's own peril) might be the "correct" long-term approach for how to
handle syntax highlighting.
>
> So so far I see 4 "valid" options:
> 1. Move towards server side highlighting implementing a caching
> mechanism.
This seems like something that should be done eventually, while making
some intermediate approach available in the meantime with no guarantees
of future compatibility -- an optional, experimental, biohazard-warning
approach just to fill in the gap until the server side is available.
> 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.
Sorry, I'm not sure what you're saying here. If you're saying that
syntax highlighting libraries have their own line numbering
functionality, it might make sense to just defer to that in cases where
syntax highlighting is used, and thus obviate most of this discussion.
> 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.
That seems like the reasonable short-term solution, to me, but probably
not as an intended long-term official solution. There are reasons to
favor server-side functionality for these things "eventually", and avoid
pushing all this off to the end user. If syntax highlighting is
considered a nonessential option, though, a simpler solution would be to
just make some minor server-side changes to allow people deploying repos
to the web to do the work of experimenting and integrating as they feel
inclined to do so.
A solution for line-numbering in the case of "well, we use the pre-code
tag convention, and the rest is up to you" might be to just use JS to
apply a specially-styled ordered list to the entire block of code after
any hooked-in JS syntax highlighting code and call it done. When you
customize, you get what you get. Right?
> 4. Relegate line numbering with syntax highlighting to a no go.
That's definitely a short-term hack kind of "solution", and probably not
something that should be an official implementation decision five years
down the road.
>
> 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.
I'm not too keen on that idea, either.
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
