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 just whatever highlights.js emits, I'm sure
we'll find that they are
somewhere between similar and identical.
You'll I guess be happy to know that since hljs's line numbering
extension follows this "standard" that means that what I submit will
oddly enough follow it too. I'm not sure this "standard" is the best
solution, but at the moment what I care about is that it works.
----
I'm working on a solution that involves both the C part of the code base
along with some JS resources. When I finish I'll submit a patch. It
should
keep all current features working. The JS resources will be made
available
but not included in the patch (or the Fossil repo) unless specifically
requested for since doing so means a few more things would need to be
done
and there's no guarantee that everyone would want these files included
by default. The only reason for inclusion of the files mentioned is if
there is an easy way to enable this, versus one doing some configuration
of their own repo. I would say adding an easy option would be grand.
The issue with only doing things like GitHub does with the hash part at
the end of the URI is that doing so would break links within Fossil
repos
on wiki pages, tickets and so forth, that use the current linking
format.
So, supporting both is grand, and the right thing to do.
The reason the patch I'm working on would introduce this as a supported
feature is because I intend to create a new Fossil setting or settings.
I'm still working out how this will work due to trying to ascertain the
best way to move the resource loading and calling out into the theme,
versus being built into the code, to allow for continued flexibility.
The settings needed:
1. syntax-hl (Is syntax highlighting enabled)
2. syntax-hl-call (what javascript function to insert a call for when
doing line numbering)
3. syntax-hl-easy (Do the hard work for you?)
I'm unsure if they should be combined into a single setting. If so I'd
go for "syntax-hl-call" and the easy setting would be a JS included
with Fossil that would be "fossil_easy_syntax_hl" or similar.
If I'm thinking correctly, those 1 or 2 settings will allow for Fossil
to retain it's flexibility and support syntax highlighting overall
whilst remaining agnostic to how one enables their syntax highlighting.
This also means that all the old line numbering, and content rendering
will continue to work for those who do not wish to have such, whilst
making it possible, either simply, or with a bit of work on the user's
part, to add in syntax highlighting that works, and works well.
I've still yet to clean all this up and make it use-able from a general
standpoint. After this coming patch, getting syntax highlighting and
line numbering working, the next thing will be to get diffs working,
if this doesn't already fix it for them too.
--
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
