Re: [BUG] org-store-link on document title
On 6/29/23 11:54, Ihor Radchenko wrote: You can set :store property for "file" links in `org-link-parameters' to adjust for your personal use case. That is good advice. -- Anthony Carrico
Re: [BUG] org-store-link on document title
On 6/29/23 09:20, Ihor Radchenko wrote: Sure. And if it were a plain file link, there would be no reason to assign TITLE as description. Because the link would be to a generic line in file. What? The title is the perfect description for the file! I would say that 90% of the links in my org notes are file links with the title as the description. I tend to use *deft* to search a lot of small pages without deep outlines. -- Anthony Carrico
Re: [BUG] org-store-link on document title
On 6/28/23 16:16, Ihor Radchenko wrote:> It has been added back in Org 9.5. Thanks, I'm on 9.5.5, so I can test it... You can set `org-id-link-to-org-use-id' to non-nil (4.5 Handling Links). Then, Org will store link to current file/heading instead of more generic link. Latest version of Org will also auto-assign TITLE as the link description. #+begin_example :PROPERTIES: :ID: 5f4cdb46-d18d-41bb-914e-da7faa12 :END: #+TITLE: test org title link #+end_example #+begin_example [[id:5f4cdb46-d18d-41bb-914e-da7faa12][test org title link]] #+end_example ...hmm, you are correct that this option does add the proper default description, but this is not a just plain file link anymore. -- Anthony Carrico
Re: what is the purpose of "This link has already been stored"?
On 6/29/23 06:28, Ihor Radchenko wrote: Samuel Wales writes: if you move the recent one to top of list, that would work for my mindless store/insert, but it might not work for a user who has carefully cultivated a set of links that are all to be inserted, or such. although idk if the mechanism supports. Makes sense. It is a +1 for a defcustom. Although I still believe that we should change the current default, even if leaving an option to fall back to previous behaviour. I don't think there is much reason to complicate the interface with a defcustom. The current default is an error, so changing the default doesn't break the workflow of anyone using it the way Samuel describes (unless I'm missing something). -- Anthony Carrico
Re: [BUG] org-store-link on document title
On 6/28/23 15:56, Ihor Radchenko wrote: Latest version of Org will also auto-assign TITLE as the link description. Nice, sound like this issue is already fixed. Looking forward to the upgrade. -- Anthony Carrico
[BUG] org-store-link on document title
On 6/28/23 12:48, Ihor Radchenko wrote: > I cannot reproduce. > Please provide more details and report this under a different email > subject, so that we can easily distinguish the two bugs. > See https://orgmode.org/manual/Feedback.html#Feedback Ah, very sorry for the distraction on the "This link has already been stored" issue. I'll describe the behavior I observe, and a more useful behavior. I'm not sure this constitutes an actual bug, since org-store-link isn't documented to work on the title line of a document. Org mode version 9.5.5 (release_9.5.5 @ /usr/share/emacs/28.2/lisp/org/) GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, cairo version 1.17.6) of 2023-01-02 To duplicate: Create file test.org as in this example: #+begin_example #+TITLE: test org title link #+end_example 1. go to title line of test.org, and do org-store link: 'C-c l' 2. go to new file test2.org, and do org-insert-link: 'C-c C-l M-p ' Here is the actual file test2.org produced by this method: #+begin_example [[file:test.org::+TITLE: test org title link]] #+end_example This isn't great because there is no description. 1. Expected file test2.org: #+begin_example [[file:test.org::+TITLE: test org title link][test org title link]] #+end_example Or even better: 2. Desired file test2.org: #+begin_example [[file:test.org][test org title link]] #+end_example Here the title is used as the description, and the file itself is linked, rather than the title line. The second option makes more sense to me. Why? Because at the title line I intend to store a link to the document labeled with the title, and at a headline I intend to store a link to a section of the document labeled with the headline. This option also produces cleaner html output (at least a few years ago--see org mailing list around 2020-08-06 with subject "ISSUE: Unable to resolve link (html export)"). -- Anthony Carrico
Re: what is the purpose of "This link has already been stored"?
I agree that the current behavior is useless, and I agree that a good default would be to bring the link to the front of the list. Storing the link is also currently somewhat buggy. I almost always link to the top of the page (the title), and org creates a table entry which looks like this: Abstract Syntax Graphs for Domain Specific Languages> Creating a link like this: [[file:2023-06-24T161646.org::+TITLE: Ref: Functional Programming with Structured Graphs]] Unfortunately the link doesn't automatically get a sensible default description. This would be a better table entry: Ref: Abstract Syntax Graphs for Domain Specific Languages Creating a link like this: [[file:2023-06-24T161646.org][Ref: Functional Programming with Structured Graphs]] I always do this transformation manually when creating links to my pages. I'm in the habit of stripping the title from the link, because such links didn't used to work, maybe due to the pound sign, but apparently they are currently working, as I just discovered. -- Anthony Carrico
Re: org-insert-structure-template
On 12/12/22 09:20, alain.coch...@unistra.fr wrote: Perhaps you have in min > '<', followed by a template selector and ' Yes! I didn't realize that could be enabled. I trained myself not to rely on this when the new keybinding came. Only recently did I realize the reason the new keybinding is sometimes unreliable is the limited ASCII control keys on the TTY. Thanks! Was this deprecated because it isn't a regular emacs keybinding? -- Anthony Carrico
Re: org-insert-structure-template
On 12/12/22 09:04, Ihor Radchenko wrote: Note that we have alternative key bindings for TTY. See `org-use-extra-keys'. The general pattern is C-c C-x . Maybe we can add "C-c C-x ,"? Thanks, that is probably a good pattern to use. I'll look into org-use-extra-keys. This is the only keybinding that regularly bites me on the TTY. -- Anthony Carrico
Re: org-insert-structure-template
I'm trying to remember what the old keybinding was before it got switched to 'C-c C-,'... -- Anthony Carrico
org-insert-structure-template
I use this command all the time because the literal syntax is so heavy. The problem is that the current keybinding is not available on the TTY, and every time I use it there I get org-priority which is bound to 'C-c ,'. Does anyone else find this frustrating? Which keybinding do you use for org-insert-structure-template? I don't think I've ever used org-priority, so I'll probably just rebind 'C-c ,' to fix the problem. ‘C-c C-,’ (‘org-insert-structure-template’) Prompt for a type of block structure, and insert the block at point. If the region is active, it is wrapped in the block. First prompts the user for keys, which are used to look up a structure type from the variable below. If the key is ‘’, ‘’, or ‘’, the user is prompted to enter a block type. -- Anthony Carrico
Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
I've trimmed the CC's, and condensed my answers to the various threads below: To Bastien: You are doing a good job respecting the code. Thank you. The original implementation flip-flops between cached and normal classes (six statements removed in the original patch), whereas my clone adds and removes a class name from the classList (three statements inserted in the original patch). I did intend to make a material change which would create a new public domain implementation of the original API. I did not intended to disrespect Carsten's work or to detract from it, and I apologize to anyone who did not consider it to be a good-faith gesture. I did honestly believe that the org-mode code base would welcome a public domain clone of the script functionality to resolve the issue at hand. To the other participants in the thread: To answer your questions, I have been around for the evolution of the FSF, the Open Source movement, and the Creative Commons. I did follow Lawrence Lessig's creation of CC0. I do understand its role. I have Richard Stallman's book on my shelf signed "Happy Hacking, Richard Stallman", and I understand that emacs is his baby. Next are Jessica Litman's and Clay Shirky's, and I also own Lawrence Lessig's and Siva Vaidhyanathan's (missing, somewhere...). I did attend Richard Stallman's lecture at Saint Michael's College, as well as Siva V.'s lecture at Middlebury College. I value the contributions of all these philosophers. I have attempted to look for solutions that would solve both bug reports (license insertion + LibreJS incompatibility) without advocating or offering opinions on the broader philosophical issues. I hope my technical contributions are valued, even if they are not accepted. I did offer an opinion on license insertion: My opinion is that org-export is a means to save an org-mode file in html format, and that org-mode authors don't view their documents as derivative works of the org-export markup. I still believe inserting a license into exported documents is a mistake. The FSF encourages authors to choose an approved license for their work, but my impression is that the FSF is also anxious to avoid the notion that their products will do so unintentionally. There is a danger that such an impression would erode their market share, and therefore their ability to advocate for their mission. This stance is apparent in the FSF signalling around project pairs like GCC/LLVM, etc., and I imagine it would apply to equally to emacs, so I think it would be wise to fix both issues if possible. Bastien: You certainly have my permission to use my CodeHighlightOn/CodeHighlightOff implementation as you see fit, including licensing it under the GPLv3+, and that is a reasonable choice for you to make. If you happen to agree with the notion that the org-export output should be license-free, and you want to avoid using a clone of these functions, a third option would be to remove the script in question: The functionality is pretty unusual for a document to trigger, and might not be missed in exchange for a javascript-free export, but I yield to your ultimate decision. Thank you -- Anthony Carrico
Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
On 4/22/21 4:29 PM, Anthony Carrico wrote: Practically speaking, the script included by org-mode is in the public domain, so it could never conflict with whatever license the author chooses. Therefore, we should remove the LibreJS tag from the
[PATCH] Org-mode publish avoids inserting script license tag into target documents
>From 8f86d82b6784d26d8af86de01adcf333ee81148b Mon Sep 17 00:00:00 2001
From: Anthony Carrico
Date: Thu, 22 Apr 2021 17:32:59 -0400
Subject: [PATCH] Org-mode publish avoids inserting script license tag into
target documents
* ox-html.el: In previous versions, org-export included a script
license tag which created a conflict for authors exporting documents
for use with the LibreJS web filter. The script is in the public
domain, and does not conflict with any LibreJS license notice that
authors may include at the top of their page, so a separate license
in the is unnecessary and was removed.
This entire patch is released to the public domain by its author, Anthony
Carrico. TINYCHANGE
---
lisp/ox-html.el | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index d2f24f5c6..15ab15c34 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -233,7 +233,6 @@ property on the headline itself.")
(defconst org-html-scripts
"<script type=\"text/javascript\">
-// @license
magnet:?xt=urn:btih:e95b018ef3580986a04669f1b5879592219e2a7a&dn=public-domain.txt
Public Domain
<!--/*--><![CDATA[/*><!--*/
function CodeHighlightOn(elem, id)
{
@@ -252,9 +251,8 @@ property on the headline itself.")
}
}
/*]]>*///-->
-// @license-end
"
- "Basic JavaScript that is needed by HTML files produced by Org mode.")
+ "Basic public domain JavaScript that is needed by HTML files produced by Org
mode.")
(defconst org-html-style-default
"
Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
On 4/22/21 5:20 PM, Tim Cross wrote: Appreciate the intention. Perhaps we need to clarify what exactly we are licensing here I'm sorry, I didn't realize that you were missing the context; it is a tiny
Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
On 4/20/21 12:55 AM, Tim Cross wrote: The error from libreJS is correct - public domain is not a valid license. Everyone is licensed to use public domain works (except to obtain a copyright on them). I think you mean that libreJS is working by design when it blocks them, which is apparently the case. As this is a GNU project and correct licensing is important... Emacs is a GNU project, but org-mode export is a document processor, and the goal here was to avoid including licensed content in an Author's exported documents. -- Anthony Carrico
Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
Hi all. Thanks for the note. I took a look at the LibreJS docs to try to understand the problem. My analysis: LibreJS is a web filtering plugin. Users are making a decision to block content which is not explicitly licensed in the LibreJS syntax, including public domain works marked in that syntax. Apparently LibreJS is working as designed. I don't think we should attempt to work around a user's web filtering software. My understanding is that authors who want to get through the web filter should include an approved LibreJS license notice at the top of their page, and a separate license in a
Re: Reply-All noise
On 10/9/20 3:24 PM, c.bu...@posteo.jp wrote: Do you receive double mails? Doesn't it bother you? Normally I would agree with you, but there is a very simple explanation for this particular list: This mailing list is very high traffic and people can't pay attention all the time. I automatically filter it out of my email and look at it occasionally, so I miss most of the discussion, which is fine, except if I submit a patch or an issue, etc., and weeks or months later activity moves toward my patch/issue/etc. Basically, you need to reply-all to wake people up when a topic that interests them comes around. -- Anthony Carrico
Re: [PATCH] Include missing files when sitemap style is tree
On 10/24/20 8:21 AM, Bastien wrote:
Anthony Carrico writes:
* ox-publish.el (org-publish-sitemap): Include files that have an
ancestor below base-directory with no published files and sitemap style
is tree.
thanks for the patch and sorry for the delay in replying. I'm not
sure I understand the bug it fixes: can you briefly describe it or
provide a reproducible recipe?
#!/run/current-system/sw/bin/emacs --script
(require 'org)
(require 'ox-publish)
;;; create a source directory tree:
(make-directory "test-export/src/level1/level2/level3" t)
;;; create two source files, with an empty directory between:
(with-temp-file "test-export/src/level1/one.org"
(insert "#+TITLE one"))
(with-temp-file "test-export/src/level1/level2/level3/three.org"
(insert "#+TITLE three"))
;;; create a destination directory trees:
(make-directory "test-export/dest" t)
;;; publish the test-export:
(setq org-publish-project-alist
`(("test-export"
:base-directory "test-export/src"
:publishing-directory "test-export/dest"
:publishing-function org-html-publish-to-html
:sitemap-filename "index.org"
:sitemap-title "test-export"
:sitemap-style tree
:auto-sitemap t
:recursive t)))
;; ISSUE: Even with the force argument, org-publish still seems to
generate a cache in ~/.org-timestamps which creates a sitemap with old
titles and breaks reproducible builds. To avoid this problem delete the
cache when publishing:
(defun org-publish-delete-cache-file (project-name)
(let* ((cache-file
(concat
(expand-file-name org-publish-timestamp-directory)
project-name ".cache"))
(cexists (file-exists-p cache-file)))
(when (file-exists-p cache-file)
(delete-file cache-file
(org-publish-delete-cache-file "test-export")
(org-publish "test-export" t)
(org-publish-delete-cache-file "test-export")
;; Now run:
;;
;; $ firefox test-export/dest/index.html
;;
;; You should see something like this:
;;
;;
;; test-export
;;
;; level1
;; one
;;
;; Now run again with my patch, and you will see something like this:
;;
;; test-export
;;
;; level1
;; one
;; level2
;; level3
;; three
;;
;; As you can see, without the patch, "three" is missing from the index.
+(defun org-publish-dir-name-parent (dir-name)
+ (file-name-as-directory (expand-file-name (concat dir-name ".."
+
+(defun org-publish-dir-name-and-parents (dir-name root-dir-name)
+ (pcase dir-name
+ ("" nil)
+ ((or "./" "/" (pred (string= root-dir-name))) (list dir-name))
+ (_ (cons dir-name (org-publish-dir-name-and-parents
+ (org-publish-dir-name-parent dir-name)
root-dir-name)
+
+(defun org-publish-file-name-parents (file root)
+ (org-publish-dir-name-and-parents (file-name-directory file)
+ (file-name-as-directory root)))
+
You would need to add docstrings for each of the new functions.
I've run out of time today. These /seem/ like they should be standard
procedures in elisp, not something in org-publish, but I couldn't find
them in the manual. I'm not very experienced with elisp though.
I've run out of time today. Tell me if you have trouble with the test
case. Thank you Bastien.
--
Anthony Carrico
[PATCH] Include missing files when sitemap style is tree
* ox-publish.el (org-publish-sitemap): Include files that have an
ancestor below base-directory with no published files and sitemap style
is tree.
This entire patch is released to the public domain by its author,
Anthony Carrico. TINYCHANGE
---
lisp/ox-publish.el | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/lisp/ox-publish.el b/lisp/ox-publish.el
index 7bb2fed6e..314b48ffc 100644
--- a/lisp/ox-publish.el
+++ b/lisp/ox-publish.el
@@ -747,6 +747,20 @@ return a string. Return value is a list as returned by
(funcall subtree-to-list root)))
(_ (user-error "Unknown site-map style: `%s'" style)
+(defun org-publish-dir-name-parent (dir-name)
+ (file-name-as-directory (expand-file-name (concat dir-name ".."
+
+(defun org-publish-dir-name-and-parents (dir-name root-dir-name)
+ (pcase dir-name
+ ("" nil)
+ ((or "./" "/" (pred (string= root-dir-name))) (list dir-name))
+ (_ (cons dir-name (org-publish-dir-name-and-parents
+ (org-publish-dir-name-parent dir-name)
root-dir-name)
+
+(defun org-publish-file-name-parents (file root)
+ (org-publish-dir-name-and-parents (file-name-directory file)
+ (file-name-as-directory root)))
+
(defun org-publish-sitemap (project sitemap-filename)
"Create a sitemap of pages in set defined by PROJECT.
Optionally set the filename of the sitemap with SITEMAP-FILENAME.
@@ -819,8 +833,11 @@ Default for SITEMAP-FILENAME is `sitemap.org'."
;; Add directories, if applicable.
(unless (and (eq style 'list) (eq sort-folders 'ignore))
(setq files
-(nconc (remove root (org-uniquify
- (mapcar #'file-name-directory files)))
+(nconc (remove
+root
+(org-uniquify
+ (mapcan (lambda (f) (org-publish-file-name-parents f
root))
+ files)))
files)))
;; Eventually sort all entries.
(when (or sort-files (not (memq sort-folders 'ignore)))
--
2.25.4
Re: [PATCH] Org-mode publish avoids inserting licensed content into target documents.
On 9/5/20 4:03 AM, Bastien wrote: ... I applied your change on the master branch as 471054136, thanks for this. And thank you Bastien! -- Anthony Carrico
ISSUE: Unable to resolve link (html export)
* Steps to reproduce: 1. Create a file called test.org: #+TITLE: test.org 2. Create a file called test2.org: #+TITLE: test2.org [[file:test.org::+TITLE: test][test]] 3. Export C-c C-e h H * Expected result: An html buffer * Actual result: Unable to resolve link: "No match for fuzzy expression: +TITLE: test" * Additional data The link was created by going to the first line of test.org and hitting C-c l, then the second line of test2.org and hitting C-c C-l. * Work around It seems like changing the link to: [[file:test.org::#+TITLE: test][test]] allows the export to succeed. On the other hand, the original link works fine internally. This leads me to suspect that export is using different code to follow links, but also that the insert link code is buggy, skipping the pound symbol. -- Anthony Carrico
[PATCH] Org-mode publish avoids inserting licensed content into target documents.
* It is customary for compilers to avoid claiming authorship over target code. However, the org-mode publish document publisher silently inserted licensed content into target documents. This patch replaces the GPL-V3 licensed highlighter script with a public domain version to resolve this issue. The public domain version works in a different way than the original. It adds(removes) highlighting rather than replacing the original format. In contrast, the old version caches(restores). Because the new add(remove) method is idempotent, the public domain version avoids a potential bug in the original: the cached value would be lost if it was called twice in succession. This entire patch is released to the public domain by its author, Anthony Carrico. TINYCHANGE --- lisp/ox-html.el | 16 +++- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 32996c2c2..6a4555bc7 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -233,25 +233,23 @@ property on the headline itself.") (defconst org-html-scripts "
ISSUE: dev documentation loading org, built from git
Recently, Bastien pointed me to org contribute documentation: On 5/22/20 11:10 AM, Bastien wrote > See https://orgmode.org/worg/org-contribute.html on how to contribute. And I found my way to: https://orgmode.org/worg/dev/org-build-system.html This document doesn't have a simple 5 step process at the top, but if I recall correctly I did something like this: $ make $ emacs local.mk # edit this to set prefix $ make $ make install And so I've built Version 9.4-dev locally, and now ~/share/emacs/site-lisp/org has the .el and .elc files. I've added (push "/home/acarrico/share/site-lisp" load-path) as the first thing in my init.el, but I'm unsure how to get this to load. Currently an older version is running. I'm not even sure what kind of artifact I'm looking for--an emacs package? list-packages shows: org 9.3.6 org 9.1.9 -- Anthony Carrico
Re: ISSUE: org publish document processor silently inserts licensed content into targets by default
On 5/22/20 11:10 AM, Bastien wrote: > If you think it is useful as a patch against Org, not just as a way to > customize a setup, can you send a patch? > > See https://orgmode.org/worg/org-contribute.html on how to contribute. Ok, it is on my list, thanks. -- Anthony Carrico
Re: issue tracker?
On 5/22/20 4:17 AM, Roland Everaert wrote: Example of message states: [QUESTION] -> [ANSWER] [BUG] -> ( [CONFIRMED] | [WONTFIX] | [SOLVED] ) [CONFIRMED] -> ( [SOLVED] | [PLANNED] ) [FEATURE] -> ( [WONTDO] | [PLANNED] | [IMPLEMENTED] ) [PLANNED] -> ( [IMPLEMENTED] | [SOLVED] ) I love your enthusiasm. A mailing list has no means to type check messages, so I think it does call for a more simplified mechanism, especially as a first pass (note that the machine is necessarily nondeterministic, since different people can cause it to transition at the same time by sending a message). I'd argue that questions and answers are just normal threads, that don't need a state, and issues just need an open state, and a closed state. /The details of the of those states are in the threads for anyone who cares to look/. So, OPEN/CLOSED and let the threads speak for themselves. In this way, there are just two kinds of discussions: tracked, and untracked. Newbies can quickly pick up the OPEN/CLOSED grammar. People can meander threads between the richer states in their discussion, hopefully with good subject lines, and 'bots just need to look for one pair of keywords, ignoring threads without those keywords. I don't actually use emacs for email, but I'm guessing it wouldn't be too hard for someone to write an elisp script to scan a mailbox/maildir to gather a list of subject lines--is this true? -- Anthony Carrico
Re: issue tracker?
On 5/21/20 10:18 AM, Anthony Carrico wrote: > which is a big ask for users. ... given that the community expressed that it would like to interact on a mailing list without other user facing tooling. -- Anthony Carrico
Re: issue tracker?
On 5/21/20 3:31 AM, Kévin Le Gouguec wrote: > I think you've just described, in order: > > - Debbugs (the issue tracking software), Yes, I almost mentioned that Debian uses an email based bug tracker, as a point of reference. I'm not familiar with the details, but I think it is header based, which is a big ask for users. -- Anthony Carrico
Re: issue tracker?
On 5/18/20 5:24 PM, Anthony Carrico wrote: Does org-mode have an issue tracker, to keep track of which issues are active, or is it just this mailing list? I'm the OP here. My first post to this list generated a lot of feedback. I'm not sure I have an opinion, it was an honest question, but I'd like to summarize the replies: 1. The mailing list is a good way, perhaps the best way to manage discussion threads, including threads about issues (bugs). 2. There isn't an issue tracker. I think issue tracking could happen on a mailing list. If you tag an issue's subject line with OPEN: or CLOSE:, a bot could mail a summary of the OPEN: issues to the list periodically (in theory). Given that the mailing list holds the issues, it would be nice if you could import the mailing list into your client as a lump (maildir/mbox). Currently you can only download it chunk by chunk, so it isn't really practical for a newcomer to import the whole list to do research a new issue before reporting it. -- Anthony Carrico
ISSUE: org publish document processor silently inserts licensed content into targets by default
ISSUE: An author should expect a compiler to avoid claiming authorship
over target code, however, currently the org-mode publish document
processor silently inserts licensed content into target documents by
default.
SOLUTION: The following script is a drop-in-replacement which provides
the same API as the original, without a license. It also opts not to
highlight code links, but only their targets, which seems less
distracting (it is a simple change to keep the original behavior if
preferred).
The public domain version works in a different way than the original,
fixing a potential bug. It adds(removes) highlighting rather than
replacing the original format. Ignoring the boilerplate, the new script is:
target.classList.add("code-highlighted")
The add method is idempotent. In contrast, the old version caches(restores):
elem.cacheClassTarget = target.className;
target.className = "code-highlighted";
Note that the cached value would be lost if this was called twice in
succession.
I've added the comment, "any content added to the source document by the
document processor, including this script, is in the public domain".
This statement may seem superfluous, since an author should expect the
compiler to avoid claiming authorship over target code anyway. I've only
added it in contrast with the original claim.
Assuming the org-mode authors agree with the goal of publish acting as
pure compiler, and if it seems more appropriate not to pass the notice
through to the target html, then feel free to remove this notice from
the org-html-scripts definition, perhaps retaining it above the
definition as an as an elisp comment and/or as a note in the documentation.
One last note: users can attempt to fix this issue by disabling
:html-head-include-scripts, but doing so will provoke an error when a
reader's browser attempts to highlight links to source code literal
lines, so it is probably better to patch the script.
Anyway here is my patch, you can adapt it to your emacs init, or call it
from the command line as "emacs --batch -l publish".
I declare that this patch is in the public domain.
Enjoy.
;;; publish.el --- publish project with org publish -*- lexical-binding:
t; -*-
;; To use this from the shell:
;;
;; emacs --batch -l publish
(require 'org)
(require 'ox-publish)
(defconst public-domain-scripts
"
/* Any content added to the source document by the document
processor, including this script, are in the public domain */
function CodeHighlightOn(elem, id)
{
const target = document.getElementById(id);
if(null != target) {
target.classList.add(\"code-highlighted\");
}
}
function CodeHighlightOff(elem, id)
{
const target = document.getElementById(id);
if(null != target) {
target.classList.remove(\"code-highlighted\");
}
}
")
;; patch globally:
(setq org-html-scripts public-domain-scripts)
(org-publish-all)
;; or patch locally:
;;
;; (let ((org-html-scripts public-domain-scripts)) (org-publish-all))
--
Anthony Carrico
issue tracker?
Does org-mode have an issue tracker, to keep track of which issues are active, or is it just this mailing list? -- Anthony Carrico
