Merge branch 'master' into master

Author: tarleb

.circleci/config.yml

@@ -0,0 +1 @@
+github: [tarleb, jgm]

.github/FUNDING.yml

@@ -0,0 +1,36 @@
+name: CI
+
+on:
+  pull_request:
+    branches:
+      - master
+    paths-ignore:
+      - '**/README.md'
+      - CONTRIBUTING.md
+      - LICENSE
+      - .editorconfig
+  push:
+    branches:
+      - master
+    paths-ignore:
+      - '**/README.md'
+      - CONTRIBUTING.md
+      - LICENSE
+      - .editorconfig
+  schedule:
+    # At 4:17am each Monday
+    - cron: '17 4 * * 1'
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+
+      - name: Build Docker image
+        run: make docker-test-image
+
+      - name: Run tests in Docker image
+        run: make docker-test

.github/workflows/ci.yml

@@ -0,0 +1,65 @@
+name: Release
+
+on:
+  workflow_dispatch: {}
+  schedule:
+    # At 4:17am each day
+    # If this is changed, also change the 'yesterday' variable below.
+    - cron: '17 4 * * *'
+
+jobs:
+  release:
+    name: Release
+    runs-on: ubuntu-18.04
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+
+      - name: Configure
+        id: config
+        run: |
+          last="$(date --date='4:17am yesterday' '+%s')"
+          commitdate="$(git log -1 --format='%cd' --date=unix)"
+          authordate="$(git log -1 --format='%ad' --date=unix)"
+          release_date=""
+          if [ "$commitdate" -gt "$last" ] || [ "$authordate" -gt "$last" ]; then
+              release_date="$(date '+%F')"
+          fi
+          printf "release_date=%s\n" "$release_date"
+          printf "::set-output name=release-date::%s\n" "$release_date"
+
+      - name: Build collection
+        run: make archives
+
+      - name: Create release
+        if: ${{ steps.config.outputs.release-date != '' }}
+        id: create_release
+        uses: actions/create-release@v1
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          RELEASE_DATE: ${{ steps.config.outputs.release-date }}
+        with:
+          tag_name: v${{ env.RELEASE_DATE }}
+          release_name: Lua Filters v${{ env.RELEASE_DATE }}
+          draft: false
+          prerelease: false
+
+      - name: Add zip archive to release
+        uses: actions/upload-release-asset@v1
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          upload_url: ${{ steps.create_release.outputs.upload_url }}
+          asset_path: ./.build/lua-filters.zip
+          asset_name: lua-filters.zip
+          asset_content_type: application/zip
+
+      - name: Add tar archive to release
+        uses: actions/upload-release-asset@v1
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          upload_url: ${{ steps.create_release.outputs.upload_url }}
+          asset_path: ./.build/lua-filters.tar.gz
+          asset_name: lua-filters.tar.gz
+          asset_content_type: application/x-gtar

.github/workflows/collection.yml

@@ -0,0 +1,123 @@
+Contributing to lua-filters
+===========================
+
+Happy to have you here! Below you can find guidance on the
+best way to contribute to this collection of Lua filters.
+Contributions are welcome!
+
+Bugs reports and feature requests
+---------------------------------
+
+We are happy to receive feature request or bug reports on the
+GitHub [issue tracker].
+
+Please note that all filters *usually* target the latest pandoc
+version, although we may lag behind sometimes. It is considered a
+bug if a filter produces wrong results for the latest pandoc
+version; older pandoc versions are not necessarily supported,
+although we usually strive to do so.
+
+A bug report is most useful if it gives detailed, *reproducible*
+instructions. Additionally, it should include
+
+  * the pandoc version,
+  * the exact command line used,
+  * the exact input used,
+  * the output received, and
+  * the output you expected instead.
+
+This will allow us to help you more quickly.
+
+Pull requests
+-------------
+
+Whether a small patch or a full new filters, we love getting pull
+requests. Consistency is important, especially for a project with
+multiple parts written by many contributors. That's why PRs should
+follow the filter structure outlined below.
+
+Filter Structure
+----------------
+
+The filters come with these components:
+
+- `README.md` describing the filter; if the filter depends on
+  additional programs, the document should list those requirements
+  and describe how they can be installed.
+
+  Please keep in mind that a key design goal of Markdown was
+  readability. The README should be pleasant to read even as plain
+  text. This includes keeping lines below 80 chars or, better yet,
+  below 66 chars.
+
+- The main Lua filter script; besides the code, it should also
+  contain a small header with author, copyright, and licensing
+  information. All filters must be licensed under the MIT license.
+
+  Lua code should follow the HsLua [Lua style guide]. The
+  tl;dr is: use snake_case for most names and keep lines below 80
+  chars.
+
+- `Makefile` to run the tests. The only hard requirement is the
+  existence of a `.PHONY` target named `test` which can be used to
+  test correctness.
+
+- `sample.md` or a similar file demonstrating how the filter can
+  be used. The sample file doubles as test input.
+
+- A file containing the expected output when using the filter on
+  the sample input. Multiple such files can be provided if
+  different filter configurations are to be tested.
+
+All components should be bundled in a single directory.
+
+Text and source files should always be terminated by a final
+newline character. The repository comes with a `.editorconfig`
+file which helps to adhere to this and similar conventions. Please
+consider installing [editorconfig](https://editorconfig.org) if
+you editor supports it.
+
+### Configuration
+
+Filters are expected to be readily usable by a wide range of
+users. It should not be necessary to edit any source files, so it
+often makes sense to keep a filter configurable.
+
+There are two main methods to configure a filter: environment
+variables and special metadata values. The `diagram-generator`
+filter supports both and can serve as a good reference.
+
+Tests
+-----
+
+We currently test filters under two aspects on different CI
+systems:
+
+- *Travis CI*: filters are tested against the latest pandoc
+  version as available from pandoc's download page. The build is
+  configured via `.travis.yml`.
+- *Circle CI*: tests are run in the latest pandoc/ubuntu Docker
+  image. The config is in `.circleci/config.yml`.
+
+Both systems contain all software necessary to run the tests. Some
+filters require additional software to be installed. Please make
+sure that all requirements are satisfied in both build
+environments and that the builds finish successfully.
+
+Commits
+-------
+
+Please follow the usual guidelines for git commits: keep commits
+atomic, self-contained, and add a brief but clear commit message.
+This [guide](https://chris.beams.io/posts/git-commit/) by Chris
+Beams is a good resource if you'd like to learn more.
+
+However, don't fret over this too much. You can also just
+accumulate commits without much thought for this rule. We can
+squash all commits in a PR into a single commit upon merging. But
+we still appreciate it if we don't have to rewrite the commit
+message.
+
+
+[issue tracker]: https://github.com/pandoc/lua-filters/issues
+[Lua style guide]: https://github.com/hslua/lua-style-guide

.github/workflows/release.yml

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2017-2020 John MacFarlane and contributors
+Copyright (c) 2017-2020 pandoc Lua filters contributors
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

CONTRIBUTING.md

@@ -1,6 +1,6 @@
 FILTERS=$(wildcard $(shell find * -type d | grep -v '[/\\]'))
 FILTER_FILES=$(shell find * -name "*.lua" -type f)
-LUA_FILTERS_TEST_IMAGE = tarleb/lua-filters-test
+LUA_FILTERS_TEST_IMAGE = pandoc/lua-filters-test
 
 .PHONY: test show-args docker-test docker-test-image archive
 
@@ -9,6 +9,8 @@ test:
 
 archive: .build/lua-filters.tar.gz
 
+archives: .build/lua-filters.tar.gz .build/lua-filters.zip
+
 show-vars:
 	@printf "FILTERS: %s\n" $(FILTERS)
 	@printf "FILTER_FILES: %s\n" $(FILTER_FILES)
@@ -27,16 +29,30 @@ docker-test-image: .tools/Dockerfile
 .PHONY: collection
 collection: .build/lua-filters
 
-.build/lua-filters: $(FILTER_FILES)
-	mkdir -p .build/lua-filters
-	cp -a $(FILTER_FILES) .build/lua-filters
-	cp -a LICENSE .build/lua-filters
+.PHONY: docs
+docs:
+
+.build/lua-filters: $(FILTER_FILES) docs \
+		CONTRIBUTING.md LICENSE README.md
+	mkdir -p $@
+	mkdir -p $@/filters
+	mkdir -p $@/docs
+	cp -a CONTRIBUTING.md LICENSE README.md $@
+	cp -a $(FILTER_FILES) $@/filters
+	for filter in $(FILTERS); do \
+	    cp $$filter/README.md $@/docs/$$filter.md; \
+	done
 	@printf "Filters collected in '%s'\n" "$@"
 
 .build/lua-filters.tar.gz: .build/lua-filters
 	tar -czf $@ -C .build lua-filters
 	@printf "Archive written to '%s'\n" "$@"
 
+.build/lua-filters.zip: .build/lua-filters
+	rm -f $@
+	(cd .build && zip -r -9 lua-filters.zip lua-filters)
+	@printf "Archive written to '%s'\n" "$@"
+
 clean:
 	rm -rf .build
 	$(foreach f,$(FILTERS),make -C $(f) clean;)