[feature request] The :pre header argument
This message contains my thoughts on a feature request which I think
would be useful: The =:pre= header argument, it would be used to
execute a code block before the code block at point is executed. It
would be similar to the behavior of the =:post= header argument.
Here's a simple example that shows how =:pre= could be used
#+NAME: clean-path-experiments
#+begin_src dash
if [ ! -z "$my__experiments" ] && [ -d "$my__experiments" ]; then
find ~/e -mindepth 1 -maxdepth 1 -exec rm -rf {} +
fi
#+end_src
#+NAME: tree-command
#+begin_src dash
tree -a --noreport
#+end_src
#+NAME: create-dir-for-minimal-reproducible-example
#+HEADER: :pre clean-path-experiments()
#+HEADER: :post tree-command()
#+begin_src python
import os
[os.makedirs(_) for _ in ["a/foo", "a/bar", "b"]]
[os.mknod(_) for _ in ["a/1.txt", "a/2.txt", "a/foo/b.txt", "a/bar/b.txt",
"b/b.txt"]]
#+end_src
#+RESULTS: create-dir-for-minimal-reproducible-example
#+begin_example
.
├── a
│ ├── 1.txt
│ ├── 2.txt
│ ├── bar
│ │ └── b.txt
│ └── foo
│ └── b.txt
└── b
└── b.txt
#+end_example
I think that such header argument would be useful because of two
main reasons:
* It would improve readability of code blocks by explicitly expressing
dependency
By having a header argument for the sole purpose of expressing
dependencies between code blocks, the readability of header arguments
would be improved. Recall that it is currently possible to express
such dependency by calling a code block through a =:var <>=
header argument but I think that =:var= header argument must only be
used for defining variables (be it from results obtained from
different code blocks or literals).
The first code block shown below show the differences between using
=:var= and =:pre= for the same scenario. =first-code-block= uses the
=:var= header argument while the =second-code-block= uses the =:pre=
header argument.
#+NAME: first-code-block
#+begin_src org
For our experimentation, let's start with an empty directory and let's
execute the first step.
,#+NAME: first-step
,#+HEADER: :results silent
,#+HEADER: :var e=clean-path-experiments
,#+begin_src dash
touch first-step.txt
,#+end_src
We know execute the second step.
,#+NAME: second-step
,#+HEADER: :results silent
,#+HEADER: :var e=first-step
,#+begin_src dash
touch second-step.txt
,#+end_src
Finally, we execute the third step.
,#+NAME: third-step
,#+HEADER: :results silent
,#+HEADER: :var e=second-step
,#+begin_src dash
touch third-step.txt
,#+end_src
#+end_src
#+NAME: second-code-block
#+begin_src org
For our experimentation, let's start with an empty directory and let's
execute the first step.
,#+NAME: first-step
,#+HEADER: :results silent
,#+HEADER: :pre clean-path-experiments()
,#+begin_src dash
touch first-step.txt
,#+end_src
We know execute the second step.
,#+NAME: second-step
,#+HEADER: :results silent
,#+HEADER: :pre first-step()
,#+begin_src dash
touch second-step.txt
,#+end_src
Finally, we execute the third step.
,#+NAME: third-step
,#+HEADER: :results silent
,#+HEADER: :pre second-step()
,#+begin_src dash
touch third-step.txt
,#+end_src
#+end_src
In my opinion, the second code block looks more readable than the
first one.
* it would add importance to the =:post= header argument
The =:post= header argument can be used in Org Mode 9.3 to execute a
given code block after the code block at point is executed; having a
header argument that does the opposite of the =:post= header argument
would give relevance to the =:post= header argument.
--
Greetings,
Rodrigo Morales.
IRC: rdrg109 (freenode)
Improve formatting and documentation inline source block [9.3 (release_9.3 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Sorry, sending this from the browser because none of Emacs sending options
currently work
From: dalanicolai
To: emacs-orgmode@gnu.org
Subject: Bug: Improve formatting and documentation inline source block [9.3
(release_9.3 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Date: Thu, 18 Feb 2021 18:13:07 +0100
Message-ID:
<87o8ghwb8c.fsf@daniel-fedora.i-did-not-set--mail-host-address--so-tickle-me
>
--text follows this line--
This bug report contains two requests/bugs about inline source blocks
namely:
1. Inline source blocks don't get formatted/propertized within
org buffers.
2. Different from ordinary source blocks, the inline source blocks
require the [:exports code] argument to get exported. I think it would
be useful to mention it explicitly in [section 15.2 of the
documentation](https://orgmode.org/manual/Structure-of-Code-Blocks.html),
because it is somewhat unexpected behavior (compared to ordinary source
blocks).
To test it just open an org buffer and enter e.g. the following line
`test src_emacs-lisp{(server-start)} test`
then run `M-x org-html-export-as-html`. Compare output to that of
`test src_emacs-lisp[:exports code]{(server-start)} test`
Emacs : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.25, cairo version 1.16.0)
of 2021-02-18
Package: Org mode version 9.3 (release_9.3 @
/usr/local/share/emacs/28.0.50/lisp/org/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
outline-isearch-open-invisible-function #[128 "\300\301!\207"
[org-show-context isearch] 3 "\n\n(fn _)"]
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-open-link :export
org-attach-export-link :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow eww :store
org-eww-store-link)
("rmail" :follow org-rmail-open :store org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link :export
org-irc-export)
("info" :follow org-info-open :export org-info-export :store
org-info-store-link)
("gnus" :follow org-gnus-open :store org-gnus-store-link)
("docview" :follow org-docview-open :export org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export org-bbdb-export :complete
org-bbdb-complete-link
:store org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("file+sys") ("file+emacs")
("shell" :follow org-link--open-shell)
("news" :follow #[257 "\301\300\302Q!\207" ["news" browse-url ":"] 5
"\n\n(fn URL)"])
("mailto" :follow #[257 "\301\300\302Q!\207" ["mailto" browse-url
":"] 5 "\n\n(fn URL)"])
("https" :follow #[257 "\301\300\302Q!\207" ["https" browse-url ":"]
5 "\n\n(fn URL)"])
("http" :follow #[257 "\301\300\302Q!\207" ["http" browse-url ":"] 5
"\n\n(fn URL)"])
("ftp" :follow #[257 "\301\300\302Q!\207" ["ftp" browse-url ":"] 5
"\n\n(fn URL)"])
("help" :follow org-link--open-help) ("file" :complete
org-link-complete-file)
("elisp" :follow org-link--open-elisp) ("doi" :follow
org-link--open-doi))
org-link-elisp-confirm-function 'yes-or-no-p
)
Re: org-agenda for a day different than today
Hello, On 2021-02-18 00:32, Kyle Meyer writes: >> Looking at the code, I don’t see how it could cause trouble elsewhere >> (but understanding agenda code is always tricky…) > > Yeah, I too think it's safe. If you have the time, I'd appreciate if > you could skim through the above threads and see if there are any > minimal examples or test cases. If so, it be good to verify that they > still work with the patch. I tested the first thread (where two agendas are displayed) and it still works. The second thread was about the beginning of the week wrongly set in a custom file. Best, Alan signature.asc Description: PGP signature
[PATCH] Startup option to separate macros arguments with an alternative string
Hi,
I would like to propose this (possible) patch.
With `#+STARTUP: macro-arg-sep-other' the macros arguments can be
separated by a string other than comma, whose value is defined in
`org-macro-arg-sep-other' (by default it is "'@").
Rationale for this patch: There are many contexts where the comma character can
be
inappropriate as an argument separator, since it has to be escaped many times.
If the patch is relevant, I can take care of writing the documentation and
docstrings.
Example:
#+begin_src org
,#+STARTUP: macro-arg-sep-other
,#+MACRO: lg (eval (if (org-export-derived-backend-p
org-export-current-backend 'latex) (concat "@@latex:\\foreignlanguage{@@" $1
"@@latex:}{@@" "\u200B" $2 "\u200B" "@@latex:}@@") $2))
{{{lg(latin'@Lorem ipsum dolor sit amet, consectetuer adipiscing elit, donec
hendrerit
tempor tellus, donec pretium posuere tellus, proin quam nisl, tincidunt et,
mattis eget,
convallis nec, purus.)}}}
With the escaped character:
{{{lg(latin'@Lorem ipsum dolor sit amet \'@)}}}
#+end_src
Best regards,
Juan Manuel
diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index f914a33d6..311eaf9a5 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -82,6 +82,8 @@ directly, use instead:
#+MACRO: name template")
+(defvar org-macro-arg-sep-other "'@")
+
;;; Functions
(defun org-macro--set-template (name value templates)
@@ -277,15 +279,19 @@ Return a list of arguments, as strings. This is the opposite of
`org-macro-escape-arguments'."
;; Do not use `org-split-string' since empty strings are
;; meaningful here.
+ (let ((sep (cond ((eq org-startup-macro-arg-sep 'comma)
+ ",")
+ ((eq org-startup-macro-arg-sep 'other)
+ org-macro-arg-sep-other
(split-string
(replace-regexp-in-string
-"\\(*\\),"
+ (format "\\(*\\)%s" sep)
(lambda (str)
(let ((len (length (match-string 1 str
(concat (make-string (/ len 2) ?\\)
- (if (zerop (mod len 2)) "\000" ","
+ (if (zerop (mod len 2)) "\000" (format "%s" sep)
s nil t)
- "\000"))
+ "\000")))
;;; Helper functions and variables for internal macros
diff --git a/lisp/org.el b/lisp/org.el
index 7d8733448..a51893ed3 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -974,6 +974,15 @@ case it is too late to set the variable `org-startup-truncated'."
:group 'org-startup
:type 'boolean)
+(defcustom org-startup-macro-arg-sep 'comma
+"TODO"
+:group 'org-startup
+:package-version '(Org . "9.0")
+:version "26.1"
+:type '(choice
+ (const :tag "comma" comma)
+ (const :tag "other" other)))
+
(defcustom org-startup-indented nil
"Non-nil means turn on `org-indent-mode' on startup.
This can also be configured on a per-file basis by adding one of
@@ -4187,7 +4196,8 @@ After a match, the following groups carry important information:
("nohideblocks" org-hide-block-startup nil)
("beamer" org-startup-with-beamer-mode t)
("entitiespretty" org-pretty-entities t)
-("entitiesplain" org-pretty-entities nil))
+("entitiesplain" org-pretty-entities nil)
+("macro-arg-sep-other" org-startup-macro-arg-sep other))
"Variable associated with STARTUP options for Org.
Each element is a list of three items: the startup options (as written
in the #+STARTUP line), the corresponding variable, and the value to set
bug#44824: [PATCH] org.el: Avoid xdg-open silent failure
> From: Maxim Nikulin > Date: Thu, 18 Feb 2021 19:56:03 +0700 > Cc: 44...@debbugs.gnu.org > > I could not estimate effect of such change on windows, so pipe process > is used only on linux. I am unsure concerning mac however. On Windows Emacs always uses pipes, because we don't have PTYs there. And there's no xdg-open on MS-Windows anyway, so it's a moot point.
Re: Assistance Writing Test for Org Agenda Custom Bulk Function
Kyle Meyer writes: > Unrelated note: there's a missing a space between the second "*" and > "TODO". Good catch, thank you. > Perhaps you're not capturing the environment due to your quoting: > > ;; -*- lexical-binding: t; -*- > > (let ((x 0)) > '(t (lambda () x))) ;; => (y (lambda nil x)) > > (let ((x 0)) > (list t (lambda () x))) ;; => (t (closure ((x . 0) t) nil x)) > > So try something like > > (org-agenda-bulk-custom-functions >`((?P ,(lambda ( args) > (message "test" args) > (setq f-called-cnt (1+ f-called-cnt) > f-called-args args)) > ,(lambda () > (setq arg-f-call-cnt (1+ arg-f-call-cnt)) > '(1 2 3) This was exactly it, thank you. I'll hopefully have this in a patch shortly. Kevin
Re: Source Block header arguments
On Thu, Feb 18, 2021 at 07:10:52PM +0800, Timothy wrote: > > Hi Russel, > > Russell Adams writes: > > > I know I can easily create templates for frequently used code blocks. > > > > My question is, is there a completion or in-place documentation for > > valid header arguments to code blocks? The options are rather buried > > in the manual. > > As it so happens, I have had the exact same annoyance. > > My solution was using snippets, you can see the details by looking at: > + https://tecosaur.github.io/emacs-config/config.html#snippet-helpers > + https://tecosaur.github.io/emacs-config/config.html#snippets-org-mode That is interesting. That's kind of what I was thinking could already be implemented without my knowing. ;] Maybe we need to buff the block insertion code? -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Source Block header arguments
On Thu, Feb 18, 2021 at 11:08:32AM +0800, Ihor Radchenko wrote: > Russell Adams writes: > > > I know I can easily create templates for frequently used code blocks. > > > > My question is, is there a completion or in-place documentation for > > valid header arguments to code blocks? The options are rather buried > > in the manual. > > I use helm-info-org for this. I have helm, and never saw this. Good tip! -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
[PATCH] org.el: Avoid xdg-open silent failure
On 31/01/2021 23:33, Eli Zaretskii wrote: From: Maxim Nikulin Date: Sun, 31 Jan 2021 22:57:57 +0700 Cc: 44...@debbugs.gnu.org To fix the problem it is better to use (make-process :connection-type 'pipe ...) that unfortunately has no higher level wrappers. Wouldn't it work to let-bind process-connection-type to nil around the function that starts the async subprocess? Sorry, for me it easier to reason how to express it in terms of system calls and terminal process groups than if let-bind could override a variable when lexical-bind is set to true. Well, I think we should try this, because if it works, it will show us a way to fix the problem. (I don't see how lexical-binding could interfere with let-binding.) I have prepared a patch that uses `make-process'. I hope, error reporting is improved a bit, but in the case of this particular problem failure is still quiet since xdg-open exits successfully. I could not estimate effect of such change on windows, so pipe process is used only on linux. I am unsure concerning mac however. Another question is if failure message should be suppressed when `waiting-for-user-input-p' returns truth to keep user prompt and input unaffected. commit 0001bff24864ee16598b4701a05cf40e9abc83af Author: Max Nikulin Date: Wed Feb 17 16:35:58 2021 + org.el: Avoid xdg-open silent failure * lisp/org.el (org-open-file): Use 'pipe :connection-type instead of 'pty to prevent killing of background process on handler exit. Problem happens only in some desktop environments where configured through `org-file-apps' or mailcap handlers launches actual viewer (as defined in .desktop files and obtained from mimeapps.list) in background. E.g. xdg-open invokes "gio open" or kde-open5 for Gnome or KDE accordingly and these handlers launches e.g. eog or okular in background. As soon as main process exits, temporary terminal session created by `start-process-shell-command' is terminated. As a result background processes receive SIGHUP. Previously command were executed with no buffer, so the change does not affect "needsterminal" and "copiousoutput" mailcap features, they are not supported as earlier. If handler main process fails then show a message with exit reason. Output (including error messages) is ignored as before. Gtk application tends to report significant amount of failed asserts hardly informative for majority of users. diff --git a/lisp/org.el b/lisp/org.el index 7d8733448..a199a65c9 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -8645,6 +8645,15 @@ opened in Emacs." (when add-auto-mode (mapcar (lambda (x) (cons (car x) 'emacs)) auto-mode-alist +(defun org--error-process-sentinel (proc event) + "Show a message if process failed (exited with non-zero code +or killed by a signal. Pass the function as :SENTINEL argument +of `make-process'." + (unless (string-match "finished" event) +(message "Command %s: %s." + (mapconcat 'identity (process-command proc) " ") + (substring event 0 -1 + ;;;###autoload (defun org-open-file (path in-emacs line search) "Open the file at PATH. @@ -8766,7 +8775,17 @@ If the file does not exist, throw an error." (save-window-excursion (message "Running %s...done" cmd) - (start-process-shell-command cmd nil cmd) + (if (eq system-type 'gnu/linux) + ;; Handlers as "gio open" and kde-open5 start viewer in background + ;; and exit immediately. Avoid start-process since it assumes + ;; :connection-type 'pty and kills children processes with SIGHUP + ;; when temporary terminal session is finished. + (make-process + :name "org-open-file" :connection-type 'pipe :noquery 't + :buffer nil ; use "*Messages*" for debugging + :sentinel 'org--error-process-sentinel + :command (list shell-file-name shell-command-switch cmd)) + (start-process-shell-command cmd nil cmd)) (and (boundp 'org-wait) (numberp org-wait) (sit-for org-wait ((or (stringp cmd) (eq cmd 'emacs))
passing variables to lilypond code blocks
Hi,
I’m trying to understand how ob-lilypond handles variables.
I have the following minimal example which compiles correctly:
#+begin_src lilypond :file test.png :cache no
myVar = { e f g}
\relative c' { a b c d \myVar }
#+end_src
Can I move the definition of myVar to a header argument of the
source block?
When I write this:
#+begin_src lilypond :file test.png :cache no :var
myVar="{ e f g }"
\relative c' { a b c d \myVar }
#+end_src
The compiler complains: "unknown escaped string: `\myVar'".
This makes me think that myVar is not passed at all to the code
block. What is the correct way to do this?
I know that I can do it with noweb syntax. However, I would prefer
to use header args because I need those variables in all lilypond
code blocks. Ultimately, I plan to pass them from
org-babel-default-header-args:lilypond.
Victor
Re: Source Block header arguments
Hi Russel, Russell Adams writes: > I know I can easily create templates for frequently used code blocks. > > My question is, is there a completion or in-place documentation for > valid header arguments to code blocks? The options are rather buried > in the manual. As it so happens, I have had the exact same annoyance. My solution was using snippets, you can see the details by looking at: + https://tecosaur.github.io/emacs-config/config.html#snippet-helpers + https://tecosaur.github.io/emacs-config/config.html#snippets-org-mode I hope that might be of some help/interest :) -- Timothy
