[moved from
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg25785.html]
On 08/29/17 22:55, Andy Goth wrote:
dewey.hylton says "```" imbues syntax highlighting whereas indented
lines are left plain. Fossil doesn't do any kind of syntax
highlighting at this point. Is there any interest in having this
feature? I feel syntax highlighting is both expected and bloat. We
would have to decide which we prefer: being simple or having me-too
features.
On second thought, syntax highlighting wouldn't be so bad if we
implement it client-side using JavaScript. That way it doesn't increase
load on the server computer or the network, plus (I imagine) JavaScript
is better suited than C for the sort of text processing needed to do
syntax highlighting.
We can leave it to the Fossil server administrator to decide which
syntax highlight modes to provide. Any text following the opening "```"
fence of a Markdown code block would be taken as the name of the syntax
highlight mode, whose /uv/syntax/*.js file would be loaded via <script
src> at the top of the HTML, provided an unversioned file exists with
that name.
Instead of requiring that syntax highlight script files be located in
/uv, which would prevent syntax highlighting from working in the "ui"
command for end users who don't do "uv sync", we could have a /syntax
WEBPAGE that serves the script files from configurable sources: built-in
(should we have any), checked-in (e.g. /file/syntax/*.js), unversioned
(e.g. /uv/synmode_*.js), or configured (much like /logo). Though to
reduce complexity, I would suggest supporting only built-in and
configured, omitting support for checked-in and unversioned. I'll write
another email someday with my tangential thoughts on that.
/syntax could also provide a rudimentary preprocessor-like include
system to allow common script libraries to be shared between syntax
highlight modes. Though for the sake of caching, it would be better to
implement includes by putting multiple <script src> tags in the HTML.
When viewing files outside of the Markdown renderer, there could be a
configurable table mapping from file extensions (or maybe some other
more flexible sort of pattern like globs or regular expressions) to
syntax modes. If, for the sake of the above paragraph, syntax modes
have metadata to list their common includes, they can also have metadata
saying to which extensions/globs/regexps they apply.
If we REALLY want to get bloated, we can also look at filetype= or ft=
in Vim modeline comments or Emacs local variable comments to see which
syntax mode to use.
The Tcler's Wiki provides syntax highlighting using JavaScript, though I
really don't care for the particular implementation due to it being
geared toward C and ill-suited for Tcl. I think I may take another run
at writing my own JavaScript syntax highlight system, after having tried
ages ago when I first saw how ignorant of Tcl the Wiki's highlighter
was. For example, it used the name of each man page as a keyword,
whether or not the man page even described a command. (It's been
improved since then.)
One drawback of client-side syntax highlighting is it won't work well in
combination with diffs, but the solution is simple: don't do it. Diffs
are already being highlighted in one way; let's leave them as they are.
Question: Assuming all of the above is implemented and accepted, which
(if any) syntax highlight modes should Fossil provide by default? We
could go with none, satisfied that the user can add his or her own, or
we could pick the most popular languages so that the out-of-the-box
experience is improved for marketing's sake. By "most popular" I am of
course referring to SQLite and TH1. :^)
Question: How would syntax highlight modes interact with skins? I
imagine skins could be updated to define a standard set of syntax
highlight classes, much the same as Vim or other editors have color
schemes which are independent of any particular highlighted languages.
Question: Am I sending this email to the right list, or should this
discussion stay on fossil-users so it reaches a wider audience?
--
Andy Goth | <andrew.m.goth/at/gmail/dot/com>
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
