Prettify.js is now abandoned/archived. highlight.js as a replacment?

[WizardGed]

As per title the google code-prettify library that is used by this project has been archived and is no longer maintained. (see https://github.com/googlearchive/code-prettify). I briefly looked at what other projects are starting to do and most seem to be moving to highlight.js, I know swapping out libraries especially libraries that affect visual styling can be controversial so I thought I'd reach out before taking a shot at swapping out the library and making a pull. Is this an acceptable replacement?, Is there a specific way you want the libraries added (clone the cdn library as a git submodule under vendors with the update script, then copy the js libraries to the relevant CSS and JS directories? just copy the min.js file and css files?) I took a look through the faq and didn't find anything regarding this and don't want to make a mess of a pull.

[elrido]

A replacement for the prettify library would be welcome and with the goal of the next release being UI change focused, we can anyway expect a few breaking changes (i.e. the upgrade of bootstrap 3 to 5 will change the default UI quite significantly).

Technically: We just put the minified (if these are offered) JS and CSS libriaries with a version identifier in the filename (so the browser cache automatically gets refreshed when a new version is used) into the relevant directories. Some users use the git repository straight on their servers and our main release method is git archive, so we try to avoid committing unnecessary bits from the libraries project (see for example the .gitignore rules to avoid committing composer artefacts that aren't used by us).

UI considerations: In my personal opinion, I'd wish for the replacement to also have some kind of support for dark themes (be that a dark-mode or via themes that need to be configured, like prettify) and more importantly, that it works without having to tell it what language the code is. If the source code type style (optionally) can be hinted, i.e. from a drop-down or such, the paste format would need to be extended to store this information (presumably via a new field at the end of the paste_meta_json list, so that older client versions can just ignore it). Pastes created before this change would not have that information and should still be displayed in some form, even if it is just line numbers or it defaults to a generic language like C or POSIX shell scripts.

Related topics, that may or may not influence this replacement:

• Turn off syntax highlighting while still keep line numbering #142 wished for being able to disable syntax highlighting, while keeping line numbers. If a highlight.js implementation adds selectable syntaxes, maybe it also includes a "plain text" mode?
• Add support to highlight diff/patch #189 asked for a syntax highlight mode for diff/patch files. Maybe highlight.js already supports this.
• Mark line(s) to share highlighted part(s) of the paste #789 works on letting paste users highlight, lines or sections in a paste. Presumably this requires the presence of line numbers.

[rugk]

First of all, @WizardGed, thanks a lot for your enthusiasm to jump in and wrap out legacy/abandoned dependencies! IMHO it is a good idea to upgrade to a proper library.

In addition to what @elrido already said, …

• Add ability to specify source code language #225 is about what @elrido explained with switching the . https://highlightjs.org/ was also suggested there.
• and we could fix Triply quoted strings break syntax highlighting in some cases #421 by doing that

[Tigerpanzer02]

Hey, what about using prism.js instead of highlight.js ?
Prsim got a lot of plugins available which would allow new features and different ways of how it is handled now.

#142 Possible by not adding x plugin as user
#189 https://prismjs.com/plugins/diff-highlight/
#789 https://prismjs.com/plugins/line-highlight/ & https://prismjs.com/plugins/line-numbers/
#225 is possible
#421 is fixed with prsimjs example on prsimjs

[elrido]

Go for it!

[rugk]

FYI in the future (with good browser support) we or libraries we use could switch to the Custom Highlight API: https://codepen.io/bramus/full/VwRqGVo https://css-tricks.com/css-custom-highlight-api-early-look/#aa-enter-the-css-custom-highlight-api

[cryptomilk]

The best syntax highlighting you get in the meantime from tree-sitter: https://tree-sitter.github.io/tree-sitter/syntax-highlighting

It is what Github is using for syntax highlighting.. For the web see: https://github.com/tree-sitter/tree-sitter/blob/master/lib/binding_web/README.md

[elrido]

A problem with a lot of these alternatives is that they don't do language auto-detection or rather do operate differently depending on selected language. This means we would almost have to extend the paste format to include a setting for the language in source code type pastes and add the languages to the format drop down (and in the background split the source code ones into two pieces of information). Existing pastes would then probably not get rendered correctly, though that is a minor issue.

At least tree-sitter does offer a regex based mechanism to configure detection patterns, but I've not found samples of how to use that or curated lists of detection patterns. So it certainly has a higher chance of developing a drop-in replacement, though it will still be a significant piece of work.

[cryptomilk]

I think this is fine. My cpaste command line client does source code language detection. So I can send the guessed language to the privatebin. Also you can just allow to change the hightlighting. Not only set it when creating the paste, allow to change it when displaying it. Then in case of the wrong highlight someone can change it on display.

[rugk]

Yeah, language detection could also be it's own library though and we just pass in the result of that detection into the highlighter lib.
Or (/And), indeed, we could provide a dropdown and a possibility to choose the language manually. (Especially as some auto detection errors are likely[?] unavoidable – for short content, at least.)

[elrido]

I'm all for user choice and this would also elegantly solve the backwards compatibility problem reg. pastes that don't include a (to be defined, future) source language attribute. Good call!