As this PR changes the syntax highlighting classes, I suppose it could be tagged as a major. I've seen absolutely massive performance improvements in my workload, as can be seen in the benchmarks.

Checklist

• [x] I have read the contribution guidelines.
• [x] make test passes.
• [x] make lint passes.
• [x] Performance improvements include benchmarks.
• [x] Changes match the documented (not just the implemented) behavior of Jekyll.

(As referenced here:) tags/highlight.go won't compile in go < 1.16, because it uses "io/fs":

build github.com/osteele/gojekyll: cannot load io/fs: malformed module path "io/fs": missing dot in first path element

Previous versions used this code to test for the absence of the pygmentize command, but it does not work in go 1.16 because the error is not on the specified type:

	if e.Err == exec.ErrNotFound {

831ea53 changed to use this code, but this code does not compile in go < 1.16:

	if pathErr, ok := err.(*fs.PathError); ok {

The flag should be implemented for compatibility with Jekyll, but should do nothing. For now at least, emphasize making whole builds fast enough that it's not needed.

The server builds all the collections, but only generates non-collection pages on demand. It should build everything, so that it can report all the errors.

Implementation plan:

1. site build asks config whether the plugin is active. If so, it iterates over each page's front matter's redirect_from list

2. page load asks config whether the plugin is active. If it is and if the front matter contains a redirect_to, it changes this to a permalink and creates or appends the original page permalink to a redirect_from, so that downstream processing will do the right thing.

Some plugins (e.g. jekyll-mentions) need to operate on text inside of HTML.

Add an HTML parsing staging after Liquid and Markdown conversion, and a plugin hook for this.

Does parsing the HTML affect performance? If so, only do if one of the plugins has used this hook.

Implementation plan:

• Add a struct collectionList {collections []string} type.
• Reading config.yml unmarshals into this. If it's not empty, it creates a map and assigns the configuration from it.

The configuration struct currently specifies a map. Does this cause an error if the YAML is a list?

If so:

• mark Config.collections with yaml:"-"
• define collectionMap struct
• unmarshal into collectionMap
• assign Config.collections from collectionMap.collections

Implementation plan:

• Site.Read adds the files in $theme/assets, before adding the files in the main site (so that the latter takes precedence)
• layouts looks in $themes/_include, after looking in the main _include
• include_relative from the theme directory needs to look first in the corresponding non-theme location
• The sass copier should first copy files from $themes/_sass, then overwrite them with $site/_sass

The jekyll-github-metadata plugin should have an option to cache GitHub requests. This would make it easier to run benchmarks that (1) don't include network latency (which is large over slow network connections, and highly variable in general).

Expected behavior

Add a draft release to project releases https://github.com/osteele/gojekyll/releases.

Actual behavior

❯ goreleaser --rm-dist
   • running goreleaser dev   
   • loading config file       file=.goreleaser.yml
   • SETTING DEFAULTS 
   • GETTING AND VALIDATING GIT STATE
   • LOADING ENVIRONMENT VARIABLES
   • CHECKING ./DIST  
   • rm-dist is set, removing ./dist
   • BUILDING BINARIES
   • skipped ignored build     target=darwin/386
   • new folder                folder=gojekyll_0.0.1_macOS_64bit key=darwinamd64
   • building                  binary=dist/gojekyll_0.0.1_macOS_64bit/gojekyll
   • new folder                folder=gojekyll_0.0.1_Linux_64bit key=linuxamd64
   • building                  binary=dist/gojekyll_0.0.1_Linux_64bit/gojekyll
   • new folder                folder=gojekyll_0.0.1_Linux_32bit key=linux386
   • building                  binary=dist/gojekyll_0.0.1_Linux_32bit/gojekyll
   ⨯ release failed            error=build failed for linux/386:
go build github.com/jeffjen/datefmt: no buildable Go source files in /Users/osteele/go/src/github.com/jeffjen/datefmt
# github.com/wellington/go-libsass/libs
../../wellington/go-libsass/libs/sass_number.go:8: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:151: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:153: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:157: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:159: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:164: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:166: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:170: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:175: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:186: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:166: too many errors

Steps to reproduce the behavior

❯ go get github.com/goreleaser/goreleaser
❯ git tag -af v0.0.1 -m "First release" && git push origin +v0.0.1
❯ goreleaser --rm-dist

More info

There appear to be two distinct problems: the "no buildable Go source files" warning re github.com/jeffjen/datefmt; and the "undefined: SassNumber" errors re github.com/wellington/go-libsass.

Before I added main: ./cmd/gojekyll to .goreleaser.yml, the commands above did create a release. The gojekyll in the release zip wasn't executable, though, since the config didn't refer to a main package. The build probably was skipping all the compilation, which is why it didn't run into the errors above. This does demonstrate that the upload part is (was) working.

See ~https://ci.appveyor.com/project/osteele/gojekyll~ https://github.com/osteele/gojekyll/runs/5171787377?check_suite_focus=true.

~This issue is reported upstream at osteele/liquid#22.~

~Once the Liquid issue is fixed~, wellington/go-libsass#20 may be an issue.

Implementation plan:

Site.Read asks the config whether this plugin is present. If it is, it changes the permalink of any document with README.htmlto / before putting it in the routing table.