Hi Kyle, All,
As requested, here's a small documentation entry for the new setting :)
>From 636330422eef59f448a60b933be9a55818888af9 Mon Sep 17 00:00:00 2001
From: TEC <t...@tecosaur.com>
Date: Mon, 1 Feb 2021 03:01:12 +0800
Subject: [PATCH] manual, news: Document org-html-meta-tags
* docs/org-manual.org, etc/ORG-NEWS: Document and announce the new
setting `org-html-meta-tags'.
---
doc/org-manual.org | 3 +++
etc/ORG-NEWS | 7 +++++++
2 files changed, 10 insertions(+)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 20a0d1d7a..a82b0f9a4 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -12624,6 +12624,9 @@ settings described in [[*Export Settings]].
multiple =DESCRIPTION= lines. The exporter takes care of wrapping
the lines properly.
+ The exporter includes a number of other meta tags, which can be customised
+ by modifying ~org-html-meta-tags~.
+
- =HTML_DOCTYPE= ::
#+cindex: @samp{HTML_DOCTYPE}, keyword
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index ba769224f..a2f1667b2 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -81,6 +81,13 @@ block. ~org-babel-latex-preamble~, ~org-babel-latex-begin-env~ and
the user to specify the preamble and code that preceedes and proceeds
the contents of the source block.
+*** New option ~org-html-meta-tags~ allows for HTML meta tags customisation
+
+New variable ~org-html-meta-tags~ makes it possible to customise the
+=<meta>= tags used in an HTML export. Accepts either a static list of
+values, or a function that generates such a list (see
+~org-html-meta-tags-default~ as an example of the latter).
+
** New features
*** =ob-python= improvements to =:return= header argument
--
2.30.0
Oh, by the way --- regarding your commits on commit/code conventions.
With (what seem like to me) quite a few "best practices" to keep in
mind, has anyone created a patch lint tool to make sure they're being
adhered to? I imagine it wouldn't be hard to check for blank lines in
functions or commits without a sentence case commit message.
For someone who isn't aware of all the nits that may be picked :P this
would be rather useful, and far better than a list of guidelines (I'm
not actually any such list though).
Oh dear, I sense myself diverging but I'm now considering the
possibility of setting up CI for the org-mode repo to check for as many
such concerns as we can to try to make the code base more consistent
(from my experience, every time I'm told to check for a specific issue
in a patch I wrote, I find many other matches in the file).
Perhaps it could be possible to hook up the ML to a process that runs
the CI script on a copy of Org with the patch(es) applied and replies
with any errors that may come up?
I should really stop here, before I really get going and start
explaining why I think it could be good to migrate to Gitea and other
ideas :P
Feel free to disregard my ramble, I've just been accumulating thoughts
on the state of Org development, and a few are liable to spill out.
All the best,
Timothy
