On 2018-06-29 11:24, Chad Perrin wrote:
Okay, after all that, I feel like distilling this down to its essence
(according to my own opinions, naturally) might be in order.
I feel like we basically have three sane options available:
1. Make some very minor changes to the Fossil source, where it
generates
pretty viewable web pages, to make it much easier to retrofit syntax
highlighting via JS libraries for those users who want it. Get someone
to write up a currently-effective guide to getting it set up, but make
it a sort of unofficial, community guide. Do not officially support
syntax highlighting at all. Do not bother screwing around with
anything
making line numbering play well with JS syntax highlighting unless and
until someone presents a patch that fits with this philosophy of not
supporting syntax highlighting but enabling it when easy to do so.
Patch in the works, is a matter of getting the JS code up to feature
parity with the C code since it'll be responsible now for content
selection and highlighting of said selections now, along with scrolling
content to it's line appropriately. Scrolling, and highlighting 1 line
work as of the moment, will continue until multiple line and multiple
selection work. This will bring some changes and make syntax
highlighting
support explicit. I'll address the current ideas later in the message.
It however doesn't fit with "not supporting syntax highlighting but
enabling it when easy to do so" as we'll see later.
2. Pick a single JS syntax highlighting library (highlight.js) to
bless.
Include a guide in official docs for setting it up in deployment.
Specify a supported version range for each Fossil release. Unless line
numbering is found to be easy to work in, just write it off and
officially declare that line numbering and syntax highlighting do not
play well together, but keep that on the radar for figuring out later
if
possible. Call this "officially tested, but not officially supported".
What I'm working on should retain the flexibility of Fossil to support
things other than hljs.
3. Ship that library with Fossil. There's no need for identifying a
supported range: either you use what ships with it or you're on your
own, and we don't care any longer. I think taking this approach
without
resolving the line numbering problem has some issues for purposes of
perception of the project, though, so I think one of the following two
things should happen here: either call it experimental with firm plans
to resolve the line numbering issue before calling it a release
feature,
or don't do this at all.
Assuming all goes well, one could use what I'm doing when I release the
patch and associated files and pull the extra files in making it
official
along with no line numbering problem meaning no perception issue.
While using an approach similar to GitHub's for purposes of easing
transition from GitHub to self-hosted Fossil would be nice, if it's too
much work to do so it shouldn't stand in the way of getting a good
solution for Fossil. This feels like one of those "perfect is the
enemy
of good enough" situations, for a case that is only "perfect" with
regard to ensuring people are slightly more inclined to switch from
GitHub to self-hosted Fossil. In fact, considering there's probably
nobody else providing that kind of fine-grained display characteristics
similarity with GitHub, this doesn't feel like a critical issue at all.
GitHub (and other code hosting solutions) similarity will be addressed
further down.
On 2018-06-29 12:42, Sam Putman wrote:
It's a related but distinct feature, the ability to render links like
this one:
https://github.com/jvirkki/libbloom/blob/master/bloom.c#L57-L60
Github, Gitlab, and Gogs will all correctly render that link, and
various short/relative
links of the same form.
This is a good convention for making URIs for branches, files, lines,
and the like. These
URIs get embedded into documentation and tickets, anywhere you might
want a
hyperlink in your rendered cod. The schema would work as well for
fossil as it does
for git.
Those can't be effectively migrated to fossil, which will display the
content hash of the
file being rendered as the URI.
I'm not going to work on the URI path parts feature you're intending
to describe here. That's an entirely seperate feature from syntax
highlighting and would probably require a lot more work throughout
the entirety of the codebase than anything else I could imagine
supporting or building in feature wise. It's very much outside the
scope of "let's make syntax highlighting work". It is, however, not
a bad idea.
That said, I do have to deal with 2 parts of the URI, the "&ln="
and "#" parts. We'll address this further down as well.
As for the HTML schema for marking up code, it's also a de-facto
standard. Originating
with pygments, if I recall correctly and used, with some variation, by
all the major syntax
highlighters.
If the other proposal is
