Re: when does :cache not cache?
Eric S Fraga writes: > in the paper I am writing, I have a number of gnuplot src blocks, some > of which process a significant amount of data so take some time to > generate the actual plots. The data are static so caching the results > make sense. However, even though I have ":cache yes" on each of these > named src blocks, and I have (for good measure), the property > "header-args:gnuplot" set to ":cache yes" as well, the plots are being > regenerated each time I export to PDF via LaTeX. I was able to reproduce. The reason why caching does not work is related to the way :var assignments work in ob-gnuplot. We dump the table data into temporary files and refer to those files in generated gnuplot script body. The temporary files names change on every execution and the gnuplot script hash is never going to be the same. I am attaching tentative patch to fix the issue. The patch introduces a new functionality to ob-core.el allowing more stable temporary file names. I am not sure if my implementation is the best way to solve the problem, so comments are welcome. Best, Ihor >From ac11b4d08edd577b29a398296364b4340096a6ae Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Sun, 12 Dec 2021 15:31:35 +0800 Subject: [PATCH] ob-gnuplot.el: Make :cache argument work with :var assignments * lisp/ob-core.el (org-babel-temporary-stable-directory): New variable holding a temporary directory name that does not change between Emacs sessions. (org-babel-remove-temporary-stable-directory): New function removing `org-babel-temporary-stable-directory' on Emacs shutdown. (org-babel-temp-stable-file): Generate stable temporary file name for object storage. The file name is constant with for equal objects. (org-babel-execute-src-block): Explicitly identify that if the result is cached. * lisp/ob-gnuplot.el (org-babel-gnuplot-process-vars): Make use of `org-babel-stable-file' to make expanded body stable with respect to :var assignments. Fixes https://orgmode.org/list/87mtn1o5mn@ucl.ac.uk --- lisp/ob-core.el| 52 +- lisp/ob-gnuplot.el | 5 - 2 files changed, 55 insertions(+), 2 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 7a9467b0e..d572423b7 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -735,7 +735,8 @@ (defun org-babel-execute-src-block ( arg info params) (forward-line) (skip-chars-forward " \t") (let ((result (org-babel-read-result))) - (message (replace-regexp-in-string "%" "%%" (format "%S" result))) + (message (format "Cached: %s" + (replace-regexp-in-string "%" "%%" (format "%S" result result))) ((org-babel-confirm-evaluate info) (let* ((lang (nth 0 info)) @@ -3112,6 +3113,22 @@ (defvar org-babel-temporary-directory Used by `org-babel-temp-file'. This directory will be removed on Emacs shutdown.")) +(defvar org-babel-temporary-stable-directory) +(unless (or noninteractive (boundp 'org-babel-temporary-stable-directory)) + (defvar org-babel-temporary-stable-directory +(or (and (boundp 'org-babel-temporary-stable-directory) + (file-exists-p org-babel-temporary-stable-directory) + org-babel-temporary-stable-directory) +(condition-case nil +(make-directory + (expand-file-name + "babel-stable" + (temporary-file-directory))) + (t nil))) +"Directory to hold temporary files created to execute code blocks. +Used by `org-babel-temp-file'. This directory will be removed on +Emacs shutdown.")) + (defcustom org-babel-remote-temporary-directory "/tmp/" "Directory to hold temporary files on remote hosts." :group 'org-babel @@ -3155,6 +3172,30 @@ (defun org-babel-temp-file (prefix suffix) temporary-file-directory))) (make-temp-file prefix nil suffix +(defun org-babel-temp-stable-file (data prefix suffix) + "Create a temporary file in the `org-babel-remove-temporary-stable-directory'. +The file name is stable with respect to DATA. The file name is +constructed like the following: PREFIXDATAhashSUFFIX." + (if (file-remote-p default-directory) + (let* ((prefix + (concat (file-remote-p default-directory) + (expand-file-name + prefix org-babel-temporary-stable-directory))) + (path (concat prefix (format "%s" (sxhash data)) (or suffix "" +(with-temp-file path) +path) +(let* ((temporary-file-directory + (or (and (boundp 'org-babel-temporary-stable-directory) + (file-exists-p org-babel-temporary-stable-directory) + org-babel-temporary-stable-directory) + temporary-file-directory)) + (path (concat + (expand-file-name + prefix org-babel-temporary-stable-directory) + (format "%s" (sxhash data)) (or suffix "" + (with-temp-file path) + path))) + (defun
Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
Ihor Radchenko writes: > Tim Cross writes: > >> ... while I totally agree we should work >> very hard not to break compatibility or adversely affect other projects >> which are built on top of org mode, like org-roam, we also don't want to >> find ourselves in a position where we cannot improve/enhance org mode >> because of the impact it has on other projects. > > Well. We have no direct control on the other projects. However, not > doing anything about the fact that other project keep appearing is > nothing but a call for more compatibility issues. If we do not clearly > specify relatively stable syntax or API, the other projects will > inevitably use internal implementation details and could be broken more > easily. For example, my recent patch to org-element broke org-roam > because org-roam relied on some undocumented behaviour of > org-element-at-point. > >> Having thought about this whole thread and other recent posts, I still >> feel any concern or reference to third party libraries etc is misguided >> or at the least, irrelevant. Most of the suggestions are fine and would >> be beneficial to org mode (such as clearly defined, consistent and >> documented syntax). The fact 3rd party libraries would also benefit from >> this is a bonus, but largely irrelevant. > > You read "Org mode third-party integration" as benefit for third-party > libraries. I read it as benefit for Org from third-party libraries (as > opposed to no benefit and potential complains from third-party library > users). > I think 3rd party libraries are a benefit to org users. On the whole, they are of no direct benefit to org-mode (if they are, then they are a good candidate for inclusion into org mode). The relationship is very similar to what Emacs has with all the external packages which are not part of Emacs. There is no direct benefit to Emacs from all these packages, but there is huge benefit for the Emacs community. Emacs changes and evolves as necessary to keep it relevant, maintainable and up-to-date with user expectations. At times, it will make changes that are breaking on 3rd party libraries or require 3rd party libraries to update/modify how they interact with Emacs. These changes are not done lightly and are done so as to minimise impact to these 3rd parties. However, Emacs does not concern itself with 3rd party libraries - it focuses on making Emacs better and leaves 3rd party libraries to themselves. Placing too much focus on 3rd party libraries runs the risk of the tail wagging the dog. Org mode should focus on what org-mode needs to do to be performant, maintainable and minimise bugs. Having clear syntax specifications, good unit tests, a clear and consistent API and documentation all contribute to org-mode stability and maintainability. Coincidentally, these are also the things which will most benefit 3rd party libraries. However, should there be some justified reason to change the syntax or the API in order to improve performance, or maintainability, we should not feel constrained from doing so because it will impact on 3rd party libraries. Instead, we should make such changes in a staged manner and provide a reasonable time for 3rd parties to be updated to work with the changes and only introduce breaking change in new major versions.
Re: Question About Nuking The Priority Of A Task After Its Been Marked As 'DONE'
Hey Konibunix!
Thanks a ton for this, this looks fun as heck to implement :)
I'll have to try this on my config sometime next week. Thanks a ton for this,
bookmarking this post for now.
Love it :)
On Sat, Dec 11, 2021, at 7:49 AM, Samuel Loury wrote:
> "Samuel Banya" writes:
>
> > I often change states of my todo list items to 'DONE', 'CANCELLED', etc.
> >
> > However, one thing I would want to know is this:
> > - Is it possible to automatically delete the '#' priority value of a task
> > after a task has been marked as 'DONE', 'CANCELLED', etc?
> >
> > Is this done via a hook function?
>
> To do it globally:
>
> --8<---cut here---start->8---
> (defun my/org-trigger-hook (change-plist)
> (let* ((type (plist-get change-plist :type))
> (pos (plist-get change-plist :position))
> (from (substring-no-properties (or (plist-get change-plist :from)
> "")))
> (to (substring-no-properties (or (plist-get change-plist :to) "")))
> )
> (when (and
>(eq type 'todo-state-change)
>(member to org-done-keywords)
>(member from org-not-done-keywords)
>)
> (org-priority (string-to-char " "))
> )
> )
> )
>
> (add-hook #'org-trigger-hook
> #'my/org-trigger-hook)
> --8<---cut here---end--->8---
>
>
> But if, like me, you want to define this behavior per task, this is one
> of the purposes of org-edna. I suggest you try it.
>
> I your particular example, you would simply set the TRIGGER property of
> the task for which you want to delete the priority to this content
>
> --8<---cut here---start->8---
> * NEXT [#B] some task
> :PROPERTIES:
> :TRIGGER: self() set-priority!(" ")
> :END:
> --8<---cut here---end--->8---
>
> Closing it would result in
>
> --8<---cut here---start->8---
> * DONE some task
> CLOSED: [2021-12-11 Sat 13:38]
> :PROPERTIES:
> :TRIGGER: self() set-priority!(" ")
> :END:
> --8<---cut here---end--->8---
>
> Of course, it also work for repeated task or any complicated scenario
> I have tried so far.
>
> I hope that helps,
> --
> Konubinix
> GPG Key: 7439106A
> Fingerprint: 5993 BE7A DA65 E2D9 06CE 5C36 75D2 3CED 7439 106A
>
>
> *Attachments:*
> * signature.asc
bug#51365: 29.0.50; org-mode: modification-time error with git controled file
close 51365 28.1
quit
TAKAHASHI Yoshio writes:
> Hi,
>
> With git controled file,
> {{{modification-time(%Y-%02m-%02dT%02H:%02M:%02S+09:00, 1)}}}
> causes "Wrong type argument: stringp, " error.
>
> `org-macro--vc-modified-time' in org-macro.el should pass list of FILE
> to `vc-call', because `vc-git-print-log' expects list of file as its 1st
> argument.
Thanks for the report and fix. This failure is new with Emacs 28,
specifically 3572613550f (Fix vc-git-state for filenames with wildcards,
2021-08-15). Before that, passing a string instead of a list worked
okay because vc-git-print-log just passed its FILES argument untouched
to vc-git-command's FILE-OR-LIST.
> diff --git a/lisp/org/org-macro.el b/lisp/org/org-macro.el
> index b8d3373418..9e70844963 100644
> --- a/lisp/org/org-macro.el
> +++ b/lisp/org/org-macro.el
> @@ -368,7 +368,7 @@ org-macro--vc-modified-time
> date)
> (unwind-protect
> (progn
> - (vc-call print-log file buf nil nil 1)
> + (vc-call print-log (list file) buf nil nil 1)
> (with-current-buffer buf
> (vc-exec-after
>(lambda ()
Looks good to me. I confirmed the bug and fix only with vc-git,
although the change looks appropriate for the other backends too:
$ git grep -E '\(defun vc-.+-print-log'
lisp/vc/vc-bzr.el:(defun vc-bzr-print-log (files buffer shortlog
start-revision limit)
lisp/vc/vc-cvs.el:(defun vc-cvs-print-log (files buffer _shortlog
_start-revision limit)
lisp/vc/vc-dav.el:(defun vc-dav-print-log (_url)
lisp/vc/vc-git.el:(defun vc-git-print-log (files buffer shortlog
start-revision limit)
lisp/vc/vc-hg.el:(defun vc-hg-print-log (files buffer shortlog
start-revision limit)
lisp/vc/vc-mtn.el:(defun vc-mtn-print-log (files buffer _shortlog
start-revision limit)
lisp/vc/vc-rcs.el:(defun vc-rcs-print-log-cleanup ()
lisp/vc/vc-rcs.el:(defun vc-rcs-print-log (files buffer _shortlog
lisp/vc/vc-sccs.el:(defun vc-sccs-print-log (files buffer _shortlog
_start-revision-ignored limit)
lisp/vc/vc-src.el:(defun vc-src-print-log (files buffer shortlog
_start-revision limit)
lisp/vc/vc-svn.el:(defun vc-svn-print-log (files buffer _shortlog
start-revision limit)
So, I've added a commit message to above patch and applied it in your
name on Org's bugfix branch (888689f2b).
Re: [PATCH] Fix org-comment-line-break-function
Hello, Kaushal Modi writes: > I have added few tests in the updated patch pasted in this email. > I have made the tests for (call-interactive #'default-indent-new-line) > because that the interactive function M-j is bound to by default. > > Can you please review and commit it? The machine I am on right now does not > allow external ssh access. Unfortunately, this seems to break "test-org/auto-fill-function" test. Could you have a look at it? Regards, -- Nicolas Goaziou
font lock (locally, per file) ignore subscripts
Hi I'd like that, in certain files, subscripts are ignored. I know I could use ~ ~ as in ~dl_emacs_support.m~ Or =dl_emacs_support.m= But could I deactivate font locking for these constructions locally? regards Uwe Brauer
[PATCH] org-test: Create a collaborative test set for Org buffer parser
Dear all,
The attached patch is an attempt to create something like shared repo
for Org element parser tests.
The idea is moving the tests out from Elisp into a set of text files.
That way, anyone interested in developing Org syntax support can use our
tests and potentially contribute more test files to the benefit of Org
mode for Emacs.
The test set is essentially a series of .org files alongside .el files
containing normalised output of `org-element-parse-buffer'. (see the
patch)
Anyone can contribute to the test set by adding new .org files and
generating the canonical parser output with new
M-x test-org-element-parser-save-expected-result function.
README.org in the repo also serves as a test file .
Any comments or suggestions?
I am particularly looking for thoughts about licensing and possible
distribution of the test set in separate repository.
Best,
Ihor
>From f7bb947517e8793a45864b614f06460d1132539d Mon Sep 17 00:00:00 2001
Message-Id:
From: Ihor Radchenko
Date: Sat, 11 Dec 2021 22:24:39 +0800
Subject: [PATCH] org-test: Create a separate testset for Org element parser
* testing/lisp/test-org-element-parser-sources/README.org: Add readme
file describing the test file format and organisation.
* testing/lisp/test-org-element-parser-sources/simple-heading.org: Add
an example test file.
* testing/lisp/test-org-element-parser-sources/README.el:
* testing/lisp/test-org-element-parser-sources/simple-heading.el: Add
normalised expected parser output files.
* testing/lisp/test-org-element-parser.el: New testset integration to
main Org test suite. The file defines ERT tests for files inside
test-org-element-parser-sources and an interactive function
`test-org-element-parser-save-expected-result' to generate parser
output files.
---
.../test-org-element-parser-sources/README.el | 42 ++
.../README.org| 64 +
.../simple-heading.el | 11 ++
.../simple-heading.org| 5 +
testing/lisp/test-org-element-parser.el | 129 ++
5 files changed, 251 insertions(+)
create mode 100644 testing/lisp/test-org-element-parser-sources/README.el
create mode 100644 testing/lisp/test-org-element-parser-sources/README.org
create mode 100644 testing/lisp/test-org-element-parser-sources/simple-heading.el
create mode 100644 testing/lisp/test-org-element-parser-sources/simple-heading.org
create mode 100644 testing/lisp/test-org-element-parser.el
diff --git a/testing/lisp/test-org-element-parser-sources/README.el b/testing/lisp/test-org-element-parser-sources/README.el
new file mode 100644
index 0..852df032f
--- /dev/null
+++ b/testing/lisp/test-org-element-parser-sources/README.el
@@ -0,0 +1,42 @@
+(org-data
+ (:begin 1 :contents-begin 2 :contents-end 1306 :end 1306 :post-affiliated 1 :post-blank 0)
+ (section
+ (:begin 2 :contents-begin 2 :contents-end 837 :end 838 :post-affiliated 2 :post-blank 1)
+ (paragraph
+ (:begin 2 :contents-begin 2 :contents-end 51 :end 52 :post-affiliated 2 :post-blank 1)
+ "This is a shared test suite for Org mode syntax.\n")
+ (paragraph
+ (:begin 52 :contents-begin 52 :contents-end 247 :end 248 :post-affiliated 52 :post-blank 1)
+ "The test suite consists of a number of .org example files alongside\nwith the expected parser output. Each .org file can be parsed as is\nand the result should match the corresponding .el file. \n")
+ (paragraph
+ (:begin 248 :contents-begin 248 :contents-end 424 :end 425 :post-affiliated 248 :post-blank 1)
+ "The parser results in .el files are Emacs sexps. Each sexp is an\noutput of "
+ (verbatim
+(:begin 324 :end 351 :post-blank 1))
+ "stripped from unessential\nproperties. Each sexp has the following form:\n")
+ (src-block
+ (:begin 425 :end 773 :post-affiliated 425 :post-blank 1))
+ (paragraph
+ (:begin 773 :contents-begin 773 :contents-end 837 :end 837 :post-affiliated 773 :post-blank 0)
+ "The properties of elements can be specified in arbitrary order.\n"))
+ (headline
+ (:archivedp nil :begin 838 :commentedp nil :contents-begin 854 :contents-end 1306 :end 1306 :footnote-section-p nil :level 1 :post-affiliated 838 :post-blank 0 :pre-blank 1 :priority nil :raw-value "Contributing" :tags nil :title
+ ("Contributing")
+ :todo-keyword nil :todo-type nil)
+ (section
+ (:begin 854 :contents-begin 854 :contents-end 1306 :end 1306 :post-affiliated 854 :post-blank 0)
+ (paragraph
+(:begin 854 :contents-begin 854 :contents-end 983 :end 984 :post-affiliated 854 :post-blank 1)
+"To add new test files to this suite, send a patch to Org mode mailing\nlist, as described in "
+(link
+ (:begin 946 :contents-begin nil :contents-end nil :end 981 :post-blank 0))
+".\n")
+ (paragraph
+(:begin 984 :contents-begin 984 :contents-end 1306 :end 1306 :post-affiliated 984 :post-blank 0)
+"The expected parser output can be generated using Emacs and latest\nversion of Org
Re: Question About Nuking The Priority Of A Task After Its Been Marked As 'DONE'
"Samuel Banya" writes:
> I often change states of my todo list items to 'DONE', 'CANCELLED', etc.
>
> However, one thing I would want to know is this:
> - Is it possible to automatically delete the '#' priority value of a task
> after a task has been marked as 'DONE', 'CANCELLED', etc?
>
> Is this done via a hook function?
To do it globally:
--8<---cut here---start->8---
(defun my/org-trigger-hook (change-plist)
(let* ((type (plist-get change-plist :type))
(pos (plist-get change-plist :position))
(from (substring-no-properties (or (plist-get change-plist :from) "")))
(to (substring-no-properties (or (plist-get change-plist :to) "")))
)
(when (and
(eq type 'todo-state-change)
(member to org-done-keywords)
(member from org-not-done-keywords)
)
(org-priority (string-to-char " "))
)
)
)
(add-hook #'org-trigger-hook
#'my/org-trigger-hook)
--8<---cut here---end--->8---
But if, like me, you want to define this behavior per task, this is one
of the purposes of org-edna. I suggest you try it.
I your particular example, you would simply set the TRIGGER property of
the task for which you want to delete the priority to this content
--8<---cut here---start->8---
* NEXT [#B] some task
:PROPERTIES:
:TRIGGER: self() set-priority!(" ")
:END:
--8<---cut here---end--->8---
Closing it would result in
--8<---cut here---start->8---
* DONE some task
CLOSED: [2021-12-11 Sat 13:38]
:PROPERTIES:
:TRIGGER: self() set-priority!(" ")
:END:
--8<---cut here---end--->8---
Of course, it also work for repeated task or any complicated scenario
I have tried so far.
I hope that helps,
--
Konubinix
GPG Key: 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE 5C36 75D2 3CED 7439 106A
signature.asc
Description: PGP signature
How to add font-lock keywords
Hi, I want to add custom keywords to be highlighted. I used
(font-lock-add-keywords nil '(("books" . org-level-4)) t)
but nothing happens after I restart orgmode or call 'font-lock-update'.
--
Daniel Fleischer
Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
Tim Cross writes: > ... while I totally agree we should work > very hard not to break compatibility or adversely affect other projects > which are built on top of org mode, like org-roam, we also don't want to > find ourselves in a position where we cannot improve/enhance org mode > because of the impact it has on other projects. Well. We have no direct control on the other projects. However, not doing anything about the fact that other project keep appearing is nothing but a call for more compatibility issues. If we do not clearly specify relatively stable syntax or API, the other projects will inevitably use internal implementation details and could be broken more easily. For example, my recent patch to org-element broke org-roam because org-roam relied on some undocumented behaviour of org-element-at-point. > Having thought about this whole thread and other recent posts, I still > feel any concern or reference to third party libraries etc is misguided > or at the least, irrelevant. Most of the suggestions are fine and would > be beneficial to org mode (such as clearly defined, consistent and > documented syntax). The fact 3rd party libraries would also benefit from > this is a bonus, but largely irrelevant. You read "Org mode third-party integration" as benefit for third-party libraries. I read it as benefit for Org from third-party libraries (as opposed to no benefit and potential complains from third-party library users). > I think a far more likely scenario is that we will see some/many of the > ideas found in org-mode adapted and implemented in other editors, but > without concern for compatibility. This has little to do with Emacs > org-mode's documentation or org-modes specification, but rather is about > how the ideas which are encapsulated in org-mode can be implemented in > other systems and within the limitations of those systems. I'm actually > surprised there hasn't been more org-mode clones already, but that could > be a reflection of the amount of work it would take to create something > which wasn't just another markdown module that renders a reasonable > HTML/PDF version of it's contents. . There are some "clones" like smos. However, org-mode is nothing but a compilation of existing ideas. There are many other (mostly proprietary) tools implementing parts of org's functionality: roam research, notion, evernote, wunderlist, zettelkasten (app), hypothes.is, ipython, Mathematica, taskwarrior, remember the milk, Doug Engelbart’s ideas, etc. Even the damned Microsoft Word has built-in outliner (don't ask how I know). Best, Ihor
Re: [BUG] "args out of range" on link heading completion [9.5 (9.5-gd361c7 @ /Users/carlos/.emacs.d/straight/build/org/)]
Carlos Pita writes: > Hi Igor, > > I believe the problem is in: > > (defun pcomplete/org-mode/searchhead () >... > ;; When completing a bracketed link, i.e., "[[*", argument > ;; starts at the star, so remove this character. > (substring pcomplete-stub 1 <-- trailing ]] not removed! > > Changing the last line to (substring pcomplete-stub 1 -2) fixes it in my > example. I don't know if one is supposed to do [[*prefix]] or > [[*prefix as is implied by the code, but better to support both, > specially considering electric pairs, don't you think? I agree that the error is thrown there. However, there is nothing wrong in the pcomplete/org-mode/searchhead. It is pcomplete that is passing something strange to our completion backend. Maybe you can try to send it as Emacs bug? Best, Ihor
