Re: [BUG] inline src blocks in caption of not-inline src blocks do not execute

[Tom Gillespie]

I have tested this again against bugfix, the issue is still present
when the cursor is on the s in #+caption: src_. Best,
Tom

Re: [PATCH] ob-tangle.el: restore :tangle closure nil behavior

[Tom Gillespie]

Here is a corrected patch that fixes the fact that closures passed to the
:tangle header were not being evaluated. Details in the commit message.
Best,
Tom

On Tue, Aug 15, 2023 at 6:41 PM Tom Gillespie  wrote:
>
> After a bit more investigation don't apply this patch because the change
> is insufficient to correct another issue.
>
> Specifically org-babel-tangle-collect-blocks must check for and resolve
> any closures that are passed to :tangle _before_ testing (string=
> src-tfile "no").
> As it stands blocks that are marked :tangle (and "no") with a closure
> incorrectly make it to a call to (org-babel-get-src-block-info) which causes
> a call to org-babel-process-params when :tangle would be "no".
>
> Working on a proper fix now.
From ce56fe5c1a24ba37c5c7c2f541c48684b0cb1e0b Mon Sep 17 00:00:00 2001
From: Tom Gillespie 
Date: Tue, 15 Aug 2023 13:46:08 -0700
Subject: [PATCH] ob-tangle.el: restore :tangle closure evaluation before eval
 info

* lisp/ob-tangle.el (org-babel-tangle): check that :tangle is not no
before attempting to tangle a single block
(org-babel-tangle--unbracketed-link): new optional argument
info-was-evaled to control whether (cdr (assq :tangle params)) is
expanded via `org-babel-read'
(org-babel-tangle-collect-blocks): expand closures passed to :tangle
with `org-babel-read' so that blocks with :tangle closure that eval to
"no" will not incorrectly eval other parameters
(org-babel-tangle-single-block): src-tfile handle cases where output
of :tangle closure could be nil and conver to "no"

This patch fixes a bug where header arguments like :tangle (or "no")
were treated as if they were tangling to a file named "(or \"no\")".
As a result, org-bable would call org-babel-get-src-block-info with
'no-eval set to nil, causing parameters to be evaluated despite the
fact that when :tangle no or equivalent is set, the other parameters
should never be evaluated.

This patch also restores the original behavior of the :tangle header
argument when a closure returned nil, e.g. #+header: :tangle (or), by
using (or (cdr (assq :tangle params)) "no"). Without this the call to
`file-name-directory' in `org-babel-tangle--unbracketed-link' can fail
with a wrong-type-argument stringp nil error.
---
 lisp/ob-tangle.el | 32 +++-
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 4566e03ad..a9fb0e286 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -316,9 +316,13 @@ matching a regular expression."
 		 (write-region nil nil file-name)
 		 (mapc (lambda (mode) (set-file-modes file-name mode)) modes))
(push file-name path-collector))
-	 (if (equal arg '(4))
-	 (org-babel-tangle-single-block 1 t)
-	   (org-babel-tangle-collect-blocks lang-re tangle-file)))
+ (if (equal arg '(4))
+ (let* ((info (org-babel-get-src-block-info 'no-eval))
+(params (nth 2 info))
+(src-tfile (or (org-babel-read (cdr (assq :tangle params))) "no")))
+   (unless (string= src-tfile "no")
+ (org-babel-tangle-single-block 1 t)))
+   (org-babel-tangle-collect-blocks lang-re tangle-file)))
 	(message "Tangled %d code block%s from %s" block-counter
 		 (if (= block-counter 1) "" "s")
 		 (file-name-nondirectory
@@ -473,14 +477,14 @@ code blocks by target file."
 		  (org-in-archived-heading-p))
 	(let* ((info (org-babel-get-src-block-info 'no-eval))
 	   (src-lang (nth 0 info))
-	   (src-tfile (cdr (assq :tangle (nth 2 info)
+	   (src-tfile (or (org-babel-read (cdr (assq :tangle (nth 2 info "no")))
 	  (unless (or (string= src-tfile "no")
 		  (and tangle-file (not (equal tangle-file src-tfile)))
 		  (and lang-re (not (string-match-p lang-re src-lang
 	;; Add the spec for this block to blocks under its tangled
 	;; file name.
 	(let* ((block (org-babel-tangle-single-block counter))
-   (src-tfile (cdr (assq :tangle (nth 4 block
+   (src-tfile (or (cdr (assq :tangle (nth 4 block))) "no"))
 		   (file-name (org-babel-effective-tangled-filename
buffer-fn src-lang src-tfile))
 		   (by-fn (assoc file-name blocks)))
@@ -490,7 +494,7 @@ code blocks by target file."
 (mapcar (lambda (b) (cons (car b) (nreverse (cdr b
 	(nreverse blocks
 
-(defun org-babel-tangle--unbracketed-link (params)
+(defun org-babel-tangle--unbracketed-link (params  info-was-evaled)
   "Get a raw link to the src block at point, without brackets.
 
 The PARAMS are the 3rd element of the info for the same src block."
@@ -510,7 +514,10 @@ The PARAMS are the 3rd element of the info for the same src block."
   (concat "file:"
   (file-relative-name (substring bare (match-end 0))
   (file-name-directory
-   (cdr (assq :tangle 

Re: Export snippet matching without closing "@@"

[Tom Alexander]

> Thanks for reporting!
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e340dde63

Thanks for fixing!

-- 
Tom Alexander

Re: [PATCH] ob-tangle.el: restore :tangle closure nil behavior

[Tom Gillespie]

After a bit more investigation don't apply this patch because the change
is insufficient to correct another issue.

Specifically org-babel-tangle-collect-blocks must check for and resolve
any closures that are passed to :tangle _before_ testing (string=
src-tfile "no").
As it stands blocks that are marked :tangle (and "no") with a closure
incorrectly make it to a call to (org-babel-get-src-block-info) which causes
a call to org-babel-process-params when :tangle would be "no".

Working on a proper fix now.

[PATCH] ob-python results handling for dicts, dataframes, arrays, and plots

[Jack Kamm]

Following up on a discussion from last month [1], I am reviving my
proposal from a couple years ago [2] to improve ob-python results
handling. Since it's a relatively large change, I am sending it to the
list for review before applying the patch.

The patch changes how ob-python handles the following types of
results:

- Dictionaries
- Numpy arrays
- Pandas dataframes and series
- Matplotlib figures

Starting with dicts: these are no longer mangled. The current behavior
(before patch) is like so:

#+begin_src python
  return {"a": 1, "b": 2}
#+end_src

#+RESULTS:
| a | : | 1 | b | : | 2 |

But after the patch they appear like so:

#+begin_src python
  return {"a": 1, "b": 2}
#+end_src

#+RESULTS:
: {'a': 1, 'b': 2}

Next, for numpy arrays and pandas dataframes/series: these are
converted to tables, for example:

#+begin_src python
  import pandas as pd
  import numpy as np

  return pd.DataFrame(np.array([[1,2,3],[4,5,6]]),
  columns=['a','b','c'])
#+end_src

#+RESULTS:
|   | a | b | c |
|---+---+---+---|
| 0 | 1 | 2 | 3 |
| 1 | 4 | 5 | 6 |

To avoid conversion, you can specify "raw", "verbatim", "scalar", or
"output" in the ":results" header argument.

Finally, for plots: ob-python now supports ":results graphics" header
arg. The behavior depends on whether using output or value
results. For output results, the current figure (pyplot.gcf) is
cleared before evaluating, then the result saved. For value results,
the block is expected to return a matplotlib Figure, which is
saved. To set the figure size, do it from within Python.

Here is an example of how to plot:

#+begin_src python :results output graphics file :file boxplot.svg
  import matplotlib.pyplot as plt
  import seaborn as sns
  plt.figure(figsize=(5, 5))
  tips = sns.load_dataset("tips")
  sns.boxplot(x="day", y="tip", data=tips)
#+end_src

Compared to the original version of this patch [2], I tried to
simplify and streamline things as much as possible, since this is a
relatively large and complex change. For example, the handling for
dict objects is much more simplistic now. And there are other
miscellaneous changes to the code structure which I hope improve the
clarity a bit.

[1] 
https://list.orgmode.org/caoqtw-n9re7fdrm1apmo8x5lrzmjfn_zjht3rvaf4x+s5m_...@mail.gmail.com/
[2] https://list.orgmode.org/87eenpfe77@gmail.com/

>From 468eeaa69660a18d8b0503e5a68c275301d6e6ae Mon Sep 17 00:00:00 2001
From: Jack Kamm 
Date: Mon, 7 Sep 2020 09:58:30 -0700
Subject: [PATCH] ob-python: Results handling for dicts, dataframes, arrays,
 plots

* lisp/ob-python.el (org-babel-execute:python): Parse graphics-file
from params, and pass it to `org-babel-python-evaluate'.
(org-babel-python-table-or-string): Prevent `org-babel-script-escape'
from mangling dict results.
(org-babel-python--def-format-value): Python code for formatting
value results before returning.
(org-babel-python-wrapper-method): Removed.  Instead use part of the
string directly in `org-babel-python-evaluate-external-process'.
(org-babel-python-pp-wrapper-method): Removed.  Pretty printing is now
handled by `org-babel-python--def-format-value'.
(org-babel-python--output-graphics-wrapper): New constant.  Python
code to save graphical output.
(org-babel-python--exec-tmpfile): Removed.  Instead use the raw string
directly in `org-babel-python-evaluate-session'.
(org-babel-python--def-format-value): New constant.  Python function
to format and save value results to file.  Includes handling for
graphics, dataframes, and arrays.
(org-babel-python-format-session-value): Updated to use
`org-babel-python--def-format-value' for formatting value result.
(org-babel-python-evaluate): New parameter graphics-file.  Pass
graphics-file onto downstream helper functions.
(org-babel-python-evaluate-external-process): New parameter
graphics-file.  Use `org-babel-python--output-graphics-wrapper' for
graphical output.  For value result, use
`org-babel-python--def-format-value'.
(org-babel-python-evaluate-session): New parameter graphics-file.  Use
`org-babel-python--output-graphics-wrapper' for graphical output.
Replace the removed constant `org-babel-python--exec-tmpfile' with the
string directly.  Rename local variable tmp-results-file to
results-file, which may take the value of graphics-file when provided.
(org-babel-python-async-evaluate-session): New parameter
graphics-file.  Use `org-babel-python--output-graphics-wrapper' for
graphical output.  Rename local variable tmp-results-file to
results-file, which may take the value of graphics-file when provided.
---
 etc/ORG-NEWS  |  19 +-
 lisp/ob-python.el | 164 --
 2 files changed, 119 insertions(+), 64 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 11fdf2825..2630554ae 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -576,6 +576,21 @@ of all relational operators (~<*~, ~=*~, ~!=*~, etc.) that work like
 the regular, unstarred operators but match a headline only if the
 tested 

[PATCH] ob-tangle.el: restore :tangle closure nil behavior

[Tom Gillespie]

Hi,
   Here's a patch to fix the :tangle header behavior when it is
passed a closure that returns nil. Best,
Tom
From f1e15e0634fffed4648aa11628a14e0a68c3b18d Mon Sep 17 00:00:00 2001
From: Tom Gillespie 
Date: Tue, 15 Aug 2023 13:46:08 -0700
Subject: [PATCH] ob-tangle.el: restore :tangle closure nil behavior

* lisp/ob-tangle.el (org-babel-tangle-collect-blocks):
* lisp/ob-tangle.el (org-babel-tangle--unbracketed-link):
* lisp/ob-tangle.el (org-babel-tangle-single-block): src-tfile fix
case where (cdr (assq :tangle params)) could be nil

This patch restores the original behavior of the :tangle header
argument when a closure returned nil, e.g. #+header: :tangle (or),
by using (or (cdr (assq :tangle params)) "no"). Without this the
call to `file-name-directory' in `org-babel-tangle--unbracketed-link'
can fail with a wrong-type-argument stringp nil error.
---
 lisp/ob-tangle.el | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 4566e03ad..0df649d7e 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -473,14 +473,14 @@ code blocks by target file."
 		  (org-in-archived-heading-p))
 	(let* ((info (org-babel-get-src-block-info 'no-eval))
 	   (src-lang (nth 0 info))
-	   (src-tfile (cdr (assq :tangle (nth 2 info)
+	   (src-tfile (or (cdr (assq :tangle (nth 2 info))) "no")))
 	  (unless (or (string= src-tfile "no")
 		  (and tangle-file (not (equal tangle-file src-tfile)))
 		  (and lang-re (not (string-match-p lang-re src-lang
 	;; Add the spec for this block to blocks under its tangled
 	;; file name.
 	(let* ((block (org-babel-tangle-single-block counter))
-   (src-tfile (cdr (assq :tangle (nth 4 block
+   (src-tfile (or (cdr (assq :tangle (nth 4 block))) "no"))
 		   (file-name (org-babel-effective-tangled-filename
buffer-fn src-lang src-tfile))
 		   (by-fn (assoc file-name blocks)))
@@ -510,7 +510,7 @@ The PARAMS are the 3rd element of the info for the same src block."
   (concat "file:"
   (file-relative-name (substring bare (match-end 0))
   (file-name-directory
-   (cdr (assq :tangle params)
+   (or (cdr (assq :tangle params)) "no"
 bare))
 
 (defvar org-outline-regexp) ; defined in lisp/org.el
@@ -580,7 +580,7 @@ non-nil, return the full association list to be used by
 			 (match-end 0)
 		   (point-min
 	  (point)
- (src-tfile (cdr (assq :tangle params)))
+ (src-tfile (or (cdr (assq :tangle params)) "no"))
 	 (result
 	  (list start-line
 		(if org-babel-tangle-use-relative-file-links
-- 
2.41.0

org-ql and inherited tags (?)

[Christian Barthel]

Hello,

i am using Emacs 29 and org-ql (20230525.1548).

I am seeing an error message that I tracked down
to setting org-use-property-inheritance.  Short
demo:

Here is a small org-file:

--8<---cut here---start->8---
## file: ~/.emacs_29_test/foo.org
* this
:PROPERTIES:
:ID:   123
:BLOCKEDBY: 123
:END:
--8<---cut here---end--->8---

An org-query like the one below works as expected.

--8<---cut here---start->8---
(setq org-agenda-files "~/.emacs_29_test/foo.org")
(org-ql-search org-agenda-files "(and (level <= 3) (property \"BLOCKEDBY\" 
\"123\"))")
;; this finds one item `this`
--8<---cut here---end--->8---

When I am setting `org-use-property-inheritance` and use the same query,
I get an error message:

--8<---cut here---start->8---
(setq org-use-property-inheritance '("DIR"))
(setq org-agenda-files "~/.emacs_29_test/foo.org")
(org-ql-search org-agenda-files "(and (level <= 3) (property \"BLOCKEDBY\" 
\"123\"))")


;; Error message:
byte-compile-log-warning: Invalid Org QL query: "Invalid Org QL query: \"‘DIR’ 
is a malformed function\", :warning", :error
--8<---cut here---end--->8---

I think that this might be related:
  

Any idea whats going wrong?

-- 
Christian Barthel

[BUG] org-get-outline-path misbehave in some scenarios when org-element-use-cache is t Inbox

[Rodrigo Morales]

I've noticed that =org-get-outline-path= report incorrect information
when =org-element-use-cache= is =t=. This mail shows some experiments
that demonstrates this bug.

* Experiment 1

In this experiment, we define a =func= which contains the sexps that
we want to run when =org-element-use-cache= is =t= and when it is
=nil=. In =func=, we use =org-map-entries= to loop through headlines
that have depth 2. In each headline, we move the point two lines below
and insert a new line containing =FOO=.

#+HEADER: :results output
#+begin_src elisp
(let ((func (lambda ()
  (with-temp-buffer
(org-mode)
(insert "* 1
,** 1-1
a
,** 1-2
a
,* 2
,** 2-1
b
,** 2-2
b
")
(princ (format "--- before\n%s\n--- before\n"
 (buffer-substring-no-properti
es
  (point-min) (point-max
(org-map-entries
 (lambda ()
   ;; We get the outline path before calling
   ;; (forward-line 2) to ensure that we are referring
   ;; to the headline in the current iteration
   (princ (format "org-get-outline-path: %s\n"
(org-get-outline-path t)))
   ;; Move two lines below the current headline A. After
   ;; executing (forward-line 2), the point is where
   ;; the next headline B starts.
   (forward-line 2)
   ;; We add a line which moves the headline B, one
   ;; line below
   (insert "FOO" "\n"))
 "LEVEL=2")
(princ (format "--- after \n%s\n---after\n"
 (buffer-substring-no-properti
es
  (point-min) (point-max
  (princ "Experiment 1.1 (org-element-use-cache nil)\n")
  (let ((org-element-use-cache nil))
(funcall func))
  (princ "Experiment 1.2 (org-element-use-cache t)\n")
  (let ((org-element-use-cache t))
(funcall func)))
#+end_src

#+RESULTS:
#+begin_example
Experiment 1.1 (org-element-use-cache nil)
--- before
,* 1
,** 1-1
a
,** 1-2
a
,* 2
,** 2-1
b
,** 2-2
b

--- before
org-get-outline-path: (1 1-1)
org-get-outline-path: (1 1-2)
org-get-outline-path: (2 2-1)
org-get-outline-path: (2 2-2)
--- after
,* 1
,** 1-1
a
FOO
,** 1-2
a
FOO
,* 2
,** 2-1
b
FOO
,** 2-2
b
FOO

---after
Experiment 1.2 (org-element-use-cache t)
--- before
,* 1
,** 1-1
a
,** 1-2
a
,* 2
,** 2-1
b
,** 2-2
b

--- before
org-get-outline-path: (1 1-1)
org-get-outline-path: (1 1-1 1-2)
org-get-outline-path: (1 2 2-1)
org-get-outline-path: (1 2 2-2)
--- after
,* 1
,** 1-1
a
FOO
,** 1-2
a
FOO
,* 2
,** 2-1
b
FOO
,** 2-2
b
FOO

---after
#+end_example

In the results above, we can see that in =Experiment 1.2=,
=org-get-outline-path= returns wrong information (note that the
results are lists of length 3), while in =Experiment 1.1= this doesn't
happen.

* Experiment 2

I noticed that when we pass one paameter (i.e. ="FOO\n"=) instead of
two as we did in the previous experiment (i.e. ="FOO" "\n"=) to
=insert=, the bug doesn't happen. See minimal reproducible example
below.

In this group of experiments we pass ="FOO\n"= instead of ="FOO" "\n"=
to =insert=.

#+HEADER: :results output
#+begin_src elisp
(let ((func (lambda ()
  (with-temp-buffer
(org-mode)
(insert "* 1
,** 1-1
a
,** 1-2
a
,* 2
,** 2-1
b
,** 2-2
b
")
(princ (format "--- before\n%s\n--- before\n"
 (buffer-substring-no-properties
  (point-min) (point-max
(org-map-entries
 (lambda ()
   (princ (format "org-get-outline-path: %s\n"
(org-get-outline-path t)))
   (forward-line 2)
   (insert "FOO\n"))
 "LEVEL=2")
(princ (format "--- after \n%s\n---after\n"
 (buffer-substring-no-properties
  (point-min) (point-max
  (princ "Experiment 2.1 (org-element-use-cache nil)\n")
  (let ((org-element-use-cache nil))
(funcall func))
  (princ "Experiment 2.2 (org-element-use-cache t)\n")
  (let ((org-element-use-cache t))
(funcall func)))
#+end_src

#+RESULTS:
#+begin_example
Experiment 2.1 (org-element-use-cache nil)
--- before
,* 1
,** 1-1
a
,** 1-2
a
,* 2
,** 2-1
b
,** 2-2
b

--- before
org-get-outline-path: (1 1-1)
org-get-outline-path: (1 1-2)
org-get-outline-path: (2 2-1)
org-get-outline-path: (2 2-2)
--- after
,* 1
,** 1-1
a
FOO
,** 1-2
a
FOO
,* 2
,** 2-1
b
FOO
,** 2-2
b
FOO

---after
Experiment 2.2 (org-element-use-cache t)
--- before
,* 1
,** 1-1
a
,** 1-2
a
,* 2
,** 2-1
b
,** 2-2
b

--- before
org-get-outline-path: (1 1-1)
org-get-outline-path: (1 1-2)
org-get-outline-path: (2 2-1)
org-get-outline-path: (2 2-2)
--- after
,* 1
,** 1-1
a
FOO
,** 1-2
a
FOO
,* 2
,** 2-1
b
FOO
,** 2-2
b
FOO

---after
#+end_example

In the results above, we can see that both 

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Tom Gillespie]

> Any other ideas? I'd be happy to see some brain-storming.

Maybe a #+keyword[options]: that doubles as a dynamic block or
something like that?
#+inline_task[options]: TODO some tiny task
#+inline_task[options]: TODO some small task
DEADLINE: <2023-11-11>
:PROPERTIES:
:SOMETHING: or other
:END:
#+inline_task_end:

Migration path should be straight forward, the exact implementation of
the behavior might need
a bit of work, and I'm not sure that the scheduling line will work in
that context, it is too fart
outside the usual behavior for keywords. However it might be possible
to move the deadline into [options]
the syntax would be a bit different than regular scheduling lines, but
it would at least be consistent
with keyword syntax.

The other question is whether you actually need an #+inline_task_end:
or whether there is another way.

The idea could use a few more iterations.

Re: [MAINTENANCE] Org orphanage?

[Ihor Radchenko]

Hrvoje Nikšić  writes:

> Can we discuss the technical details in a separate email thread or ticket?

I opened an issue on github: https://github.com/hniksic/emacs-htmlize/issues/47

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Henrik Frisk  writes:

>> ob-lilypond is distributed together with Org mode
> ...
> I know it is and I didn't know it was maintained so I've kept using this
> old version updating it myself. In that case you can probably safely ignore
> what I wrote below. Great to know it's part of org...

It is a bit of exaggeration to say that it is maintained, unfortunately.
The file does not currently have a dedicated maintainer and regular Org
contributors are not very familiar with lilypond...
So, we mostly fix the Elisp side bugs, keeping things in working state
(hopefully).

Luckily, we do not have many bug reports related to ob-lilypond.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Henrik Frisk]

On Tue, Aug 15, 2023, 12:41 PM Ihor Radchenko  wrote:

> Henrik Frisk  writes:
>
> > Sorry for being late in this discussion. As a user of ob-lilypond I'm
> very
> > happy about these changes. On my last install, as well as my current I
> have
> > had to change the following:
> >
> > (org-babel-get-header params :var) which appears to be outdated, to:
> >
> > (org-babel--get-vars params)
>
> There is no such function `org-babel-get-header'.
>
> > in the version of ob-lilypond.el from here:
> > https://github.com/mjago/ob-lilypond/blob/master/lisp/ob-lilypond.el.
> Which
> > version of the file are you patching now?
>
> ob-lilypond is distributed together with Org mode
> (
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ob-lilypond.el
> ).
> And you are looking at 12 years old early version of the library.
>

I know it is and I didn't know it was maintained so I've kept using this
old version updating it myself. In that case you can probably safely ignore
what I wrote below. Great to know it's part of org...

Re: [BUG] Error in data input and output format for org-columns--summary-estimate

[andrea]

   Howdy!
   I'm back to a previous element partially discussed as I found other org 
places where the duration had to be adapted to be able to deal with ranges: 
org-clock-get-clock-string and
   org-clock-notify-once-if-expired, both in og-clock.el; both get into action 
if you have a task you estimated and for which you're now tracking development 
time (quite handy, I have to say, as you're immediately warned you've running 
beyond estimations. For those two functions, I have introduced a similar change 
to the one I did originally to go from the basic string-to number on 
split-string to org-duration to minutes. Thanks, Sant Ignucius, for the 
debug-on-entry feature :))
   Two considerations here:
   1. I understand the fact that est+ doesn't have to necessarily be associated 
with effort, but it is quite clear from the docs which is the intent with which 
it was introduced: the only provided example is on times, and there we have to 
consider that time is expressed in durations.
   What I mean is that it does NOT make much sense to me to tell users the 
effort is to be written as 3d if given as a single value, and it has to be 
rewritten as 3-5 if we want to say "in a fork of 3 to 5 days", especially if 
somewhere else some other duration unit is used..
   2. Said differently, whether it was practically used also somewhere else, 
and not for time estimation, I can say nothing about; it is already quite hard 
to find it in doc, to date, and there  the only example given is about time.
   As without my changes the effort fork would not work properly in org-clock 
functions, if we really think estimation ranges shall be used also somewhere 
else I think we need to consider a possible generalization of what a duration 
is. In facts if we want to utilize it for other kind of measuring units 
(weight, money, etc.), it might make sense to pair it with a proper translation 
table like the one of duration that allows to convert days, hours, weeks, etc. 
into minutes, back and forth; this way we might allow both a proper type check 
according to the utilized measure unit, and would be able to avoid having to 
misleadlingly allow to sum tons to kg, for instance. (Recall: the ending letter 
today is just discarded hence 1kg-1ton is today taken as 1-1).
   Cheers,
 Andrea.

   Da "Ihor Radchenko" yanta...@posteo.net
   A and...@fedeli.eu
   Cc emacs-orgmode@gnu.org
   Data Tue, 18 Jul 2023 09:10:33 +
   Oggetto Re: [BUG] Error in data input and output format for 
org-columns--summary-estimate
   and...@fedeli.eu writes:

   >> About possibile abuses, org documentation, to date, clearly tells
   >> org estimate utilizes times.
   >
   >> May you please elaborate?

   > AF: Sure! Clause 8.5 of current
   > (2023.Jul.14) org documentation,
   > https://orgmode.org/manual/Effort-Estimates.html, refers to effort
   > estimates giving examples that are all appearing to fall in time
   > domain.

   I see what you mean.
   However, est+ column summary does not have to be applied to EFFORT
   columns.

   One can, for example, use %SCORE{est+} column specification to summarize
   values stored in SCORE property. Org has no right to demand SCORE to be
   in time units and only time units.

   > > Similarly, I'd not spend too much code to check the format; i
   > > understand the intent to preserve backward compatibility, bit if
   > > that format adaptation mistake slipped forward to these days I
   > > doubt that nice feature was used much so far...
   >
   > Yes, but it is easy to have a fallback, so why not.

   > Because this way you persist in allowing a mistaken usage of that
   > function. A number is a number but a duration is NOT just a number,
   > and having something like (just for example) 10kg-0.5ton be taken
   > as 10-0.5 is in my opinion NOT helpful to any user.

   We may provide a linter (for M-x org-lint) that will ensure EFFORT
   estimates to be in understandable format.

   --
   Ihor Radchenko // yantar92,
   Org mode contributor,
   Learn more about Org mode at .
   Support Org development at ,
   or support my work at 

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams  writes:

> Couldn't we use something like headings using ++'s instead of **'s as
> folded by default?

I am afraid that +++ may actually occur in real Org documents (e.g.
copy-paste from diff files).

Any other ideas? I'd be happy to see some brain-storming.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Tue, Aug 15, 2023 at 03:10:59PM +0100, Timothy wrote:
> They are a syntactic abomination.
>
> If there is any chance of making inlinetasks an extra that is
> outside core Org/the Org spec, I think that would be for the
> best. Having a 15+ level headlines sometimes transform into a
> completely different syntactic element is ... really not nice.

I've never used inline for exactly this reason, 15x*'s seems like
trying to use an overflow to hide data.

Couldn't we use something like headings using ++'s instead of **'s as
folded by default?

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [patch] ox-latex.el: fix blank lines behavior in verse block

[Juan Manuel Macías]

Ihor Radchenko writes:

> Sure, but look at the pdf. The generated pdfs are not different for some
> reason.

Ah, sorry. It was a foolish oversight of mine. The point is that a
\vspace after a line break in normal text has no effect. This does work:

lorem ipsum\\
\vspace*{10ex}\\
dolor

but it's a dirty workaround. In addition, there are more problems that I
had not noticed. If it is normal text, LaTeX indents the first line. A
\parindent=0 should be added, but that means complicating things
unnecessarily...

I think the best thing is to rethink the :literal attribute, as I
commented at the end of my other email:

- without :literal --> verse environment with a more "canonical" syntax.

- with :literal --> verse environment seen in the "old (org) style",
  preserving the blank lines. In that context \vspace does work.


-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Timothy]

Hi All,

On Sat, Aug 12, 2023, at 1:46 PM, Bastien Guerry wrote:

> Same here, I'd be tempted to deny Org citizenship to inline tasks: it
> always felt like a nice hack for a niche use-case, but a hack anyway.
>
> If it modifies Org syntax in surprising ways, this is another argument
> for removing org-inlinetask.el from Org's core.  Remember: this is not
> to say that inline tasks are forbidden, it's just a message for users
> that inline tasks are something not maintained by Org's core team.
>
>> And it is not clear how to fix this. We did not make inlinetasks into
>> standard Org syntax in the past and now it is in the weird state when we
>> have (featurep 'org-inlinetask) sprinkled across the code just to
>> accommodate for this conditional syntax.
>
> Yes, this is ugly.

As I've done the V2 rewrite of org-syntax and written a non-elisp Org parser 
from scratch, I feel like I'm in a decent position to comment on inline tasks.

They are a syntactic abomination.

If there is any chance of making inlinetasks an extra that is outside core 
Org/the Org spec, I think that would be for the best. Having a 15+ level 
headlines sometimes transform into a completely different syntactic element is 
... really not nice.

All the best,
Timothy.

Re: [BUG] org-set-tags-command hangs indefinitely in some indirect buffers

[Adam Beckmeyer]

> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=561c1d0db

Perfect. Can confirm that bug is no longer present even with my more complex 
org files.

Thanks so much!

--
Adam Beckmeyer

Re: [patch] ox-latex.el: fix blank lines behavior in verse block

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> The output is not different, which it should be, AFAIU. Am I missing 
>> something?
>
> I have tried your examples and I think both give the expected result.
> Look at this screenshot:
>
> https://i.imgur.com/ofl8Z9f.png

Sure, but look at the pdf. The generated pdfs are not different for some
reason.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [patch] ox-latex.el: fix blank lines behavior in verse block

[Juan Manuel Macías]

Ihor Radchenko writes:

> Thanks!
> I tested the patch with
>
> #+attr_latex:  :literal t
>
> #+begin_verse
>
>  This is just   a test.
>   ASF. 
>
> #+end_verse
>
>
> and then with
>
> #+attr_latex:  :literal t
>
> #+begin_verse
>
>  This is just   a test.
>
>   ASF. 
>
> #+end_verse
>
> The output is not different, which it should be, AFAIU. Am I missing 
> something?

I have tried your examples and I think both give the expected result.
Look at this screenshot:

https://i.imgur.com/ofl8Z9f.png

Note one important thing: the only horizontal spaces that are exported
"literally" (ie with \hspace...) are the ones at the beginning of the
line. This is the same as the old behavior, and works with both :literal
and the verse environment. Spaces between words are not exported. Well,
they are exported, but not as \hspace, so LaTeX resolves one or more
space to a single space. It could be an interesting feature that spaces
between words are also preserved, but none of the other backends do
that... Actually the :literal attribute has effect only on blank lines.

(Anyway, I think that without exporting the spaces between words, the
:literal attribute is a bit incomplete. But if those spaces are
exported, it would break compatibility with the other backends. The
horizontal space before the line makes sense for verses, because these
can often be indented arbitrarily in a poem. The other possibility is
that the :literal attribute also exports to a verse environment. In that
case, it would not break compatibility [the verse block in LaTeX would
just have two "modes": one more coherent with the syntax of the verse
environment and another one more similar to the behavior of the rest of
the backends and the "old" verse block behavior in LaTeX export]).

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: #+startup: noalign & C-c }

[Ihor Radchenko]

Edgar Lux  writes:

> Hi! Is there a way to prevent resizing of a table with 
> =org-table-toggle-coordinate-overlays=?

There is no such user option.
Internally, `org-table-align' is what takes care about adding the
coordinate overlays, so it might be non-trivial to avoid the alignment.

> P.S. Is it polite that I reply with a thanks? or is it better to stay silent 
> to avoid the extra e-mail (reading on your side)?

These things are filtered out automatically after seeing thousands of
emails. So, do not worry.

If you want to know posting rules, see
https://orgmode.org/worg/org-mailing-list.html#orgf51c63e

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [patch] Fix inner smart quotes in French

[Ihor Radchenko]

Bastien Guerry  writes:

 Are you referring to `org-export-smart-quotes-alist'? It is a defconst.
>>>
>>> Ah, indeed.  I'd say using a defcustom here would be useful.
>>
>> Is changing defconst to defcustom ok for bugfix?
>
> Nope, it's more an "evolution" than a bugfix.

Ok. I changed it to defcustom on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=570cdacdb

Note, however, that we have `org-export-dictionary' as a constant.
Also, language names are not standardized across
`org-export-dictionary', `org-export-default-language',
`org-clock-clocktable-language-setup', `org-export-smart-quotes-alist',
and `org-latex-language-alist'.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Re: what is the purpose of "This link has already been stored"?

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> See the attached tentative patch.
>
> LGTM.

Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6954fe93e

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: How to preserve indentation of title inside a latex src block when exporting to LaTeX?

[Edgar Lux]

This didn't work (I tried)

  ;; Indent title 
  (defun my-latex-filter-indent-title (text backend info)
"Ensure \"\\title\" is indented in LaTeX export."
(when (org-export-derived-backend-p backend 'latex)
  (replace-regexp-in-string
   ;; (rx (group (and (syntax escape) "title")))
   ;; (rx (and "  " (backref 1))) text)))
   "title"
   "  title" text)))

  (make-local-variable 'org-export-filter-plain-text-functions)
  (add-to-list 'org-export-filter-plain-text-functions
   'my-latex-filter-indent-title)
  ;;  indent title ends


On Aug 15, 2023 at 12:35 PM, Edgar Lux  wrote:Hello. 
How to preserve indentation of title inside a latex src block when
exporting to LaTeX?

For (annoying) reasons, I need a frontmatter block which is able to indent its
contents. I am almost there, but the title line is not. I can edit this
manually after export, but I would like to know if there is a way to do this...
wait... there are filters. Is a filter the only solution? Thanks. 

#+options: toc:nil title:nil timestamp:nil

#+begin_src emacs-lisp
  (org-babel-do-load-languages 
 'org-babel-load-languages 
 '( (latex   . t) ))
#+end_src

#+begin_frontmatter
  #+begin_src latex -i :exports results :eval yes :results replace
  \title{Determine in-situ matrix properties}
  \nothing{a}
  #+end_src
#+end_frontmatter

#+caption: Notice that title is not indented, but nothing is.
#+results:
: \begin{frontmatter}
: \title{Determine in-situ matrix properties}
:  \nothing{a}
: \end{frontmatter}

#+begin_src emacs-lisp
  (concat (emacs-version) "\n" (org-version))
#+end_src

#+RESULTS:
: GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, cairo
version 1.17.6)
:  of 2023-01-03
: 9.5.5

-- 
Sent with https://mailfence.com  
Secure and private email

-- 
Sent with https://mailfence.com  
Secure and private email

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Henrik Frisk  writes:

> Sorry for being late in this discussion. As a user of ob-lilypond I'm very
> happy about these changes. On my last install, as well as my current I have
> had to change the following:
>
> (org-babel-get-header params :var) which appears to be outdated, to:
>
> (org-babel--get-vars params)

There is no such function `org-babel-get-header'.

> in the version of ob-lilypond.el from here:
> https://github.com/mjago/ob-lilypond/blob/master/lisp/ob-lilypond.el. Which
> version of the file are you patching now?

ob-lilypond is distributed together with Org mode
(https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ob-lilypond.el).
And you are looking at 12 years old early version of the library.

> Another request would be to have the variables ly-XXX-pdf-path and
> ly-XXX-midi-path settable, or, perhaps, read from the lilypond settings of
> corresponding variables. I'm not an elisp programmer but I could look into
> that if it's of interest.

Sorry, but I am not sure what you are talking about. May you elaborate?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

How to preserve indentation of title inside a latex src block when exporting to LaTeX?

[Edgar Lux]

Hello. How to preserve indentation of title inside a latex src block when 
exporting to LaTeX?

For (annoying) reasons, I need a frontmatter block which is able to indent its 
contents. I am almost there, but the title line is not. I can edit this 
manually after export, but I would like to know if there is a way to do this... 
wait... there are filters. Is a filter the only solution? Thanks. 

#+options: toc:nil title:nil timestamp:nil

#+begin_src emacs-lisp
  (org-babel-do-load-languages 
 'org-babel-load-languages 
 '( (latex   . t) ))
#+end_src

#+begin_frontmatter
  #+begin_src latex -i :exports results :eval yes :results replace
  \title{Determine in-situ matrix properties}
  \nothing{a}
  #+end_src
#+end_frontmatter

#+caption: Notice that title is not indented, but nothing is.
#+results:
: \begin{frontmatter}
: \title{Determine in-situ matrix properties}
:  \nothing{a}
: \end{frontmatter}

#+begin_src emacs-lisp
  (concat (emacs-version) "\n" (org-version))
#+end_src

#+RESULTS:
: GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, cairo 
version 1.17.6)
:  of 2023-01-03
: 9.5.5

-- 
Sent with https://mailfence.com  
Secure and private email

Re: org-agenda-skip-function not honored by 'tags-tree' custom agenda view

[Ihor Radchenko]

João O'Neill Cortes  writes:

> Tested with org-mode version 9.7-pre.
> Looking at section 'A.7 Special Agenda Views' of the info org-manual.
>
> It is stated that 'tags-tree' searches can set
> 'org-agenda-skip-function' to some function that decides on the
> visibilty of each match.
> ...
> Is this a bug?

Sparse trees do not currently support `org-agenda-skip-function'.
So, I can say that it is a bug in the manual.
Or, we might support user-defined skip function in sparse trees.

Currently, the reason skip function is not used is in `org-scan-tags':

(unless (eq action 'sparse-tree) (org-agenda-skip el))

This is done to avoid `org-agenda-skip-comment-trees',
`org-agenda-skip-archived-trees', and `org-agenda-skip-function-global'
affecting sparse trees.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Htmlize support, maintenance, and Org mode

[Timothy]

Hi All,

I'm currently traveling, but it seems like it would be good to chime in here.

On Mon, Aug 14, 2023, at 5:22 PM, Ihor Radchenko wrote:
> Bastien Guerry  writes:
>
>> If not, then relying on engrave-faces, which is maintained and also
>> handles LaTeX, instead of htmlize, sounds like a good idea.
>
> I'd like to hear Timothy's opinion on this. He is the author of
> engrave-faces and the maintainer of ox-html.

So, I looked into htmlfontify ans htmlize quite a bit before and during my work 
on engrave-faces. I've forgotten quite a few of the details (particularly 
around internals) by this point, but still recall a fair bit and have an 
overall impression.

Engrave-faces heavily inspired by htmlize, and actually copies some methods 
from it. It was created to address two limitations I was running up against:
- The lack of support for other output formats
- The lack of support for not-the-current theme output

At this point, it's fairly stable and supports a superset of the capabilities 
of htmlize. It's a bit slower ATM, but I haven't found performance to be an 
issue in usage with Org exports. There are one or two more things it would be 
nice to do in future, but I don't anticipate any need to change the current 
public API.

I think it would make quite a bit of sense for it to be used more with Org, we 
can use it to provide a unified approach to source code highlighting. Currently 
this would just be LaTeX and HTML, but I'd like to extend code highlighting 
support to ASCII and ODT exports later on.

All the best,
Timothy.

Re: [patch] ox-latex.el: fix blank lines behavior in verse block

[Ihor Radchenko]

Juan Manuel Macías  writes:
> Ihor Radchenko writes:
>
>> Looks reasonable in general. Of course, we will also need to document
>> the new attribute.
>
> Here is the modified patch (with your suggestions, including the `rx' code)
> and the documentation of the new attribute.

Thanks!
I tested the patch with

#+attr_latex:  :literal t
#+begin_verse

 This is just   a test.
  ASF. 
   
#+end_verse

and then with

#+attr_latex:  :literal t
#+begin_verse

 This is just   a test.

  ASF. 
   
#+end_verse

The output is not different, which it should be, AFAIU. Am I missing something?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] org-set-tags-command hangs indefinitely in some indirect buffers

[Ihor Radchenko]

"Adam Beckmeyer"  writes:

> In some of my files, org-set-tags-command hangs indefinitely when invoked in 
> an indirect buffer. Attached is an example file where you can see the 
> behavior:
>
> 1. Open this file in org-mode.
> 2. Invoke org-tree-to-indirect-buffer in the "Hello World" heading
> 3. Invoke org-set-tags-command in the new indirect buffer.

Thanks for reporting!
Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=561c1d0db

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Export snippet matching without closing "@@"

[Ihor Radchenko]

"Tom Alexander"  writes:

> I suspect this is a regression. I am using this test document:
> ```
> @@latex:
> ...
> and dumped the AST with M-x eval-expression (message "%s" (pp-to-string 
> (org-element-parse-buffer)))
>
> When using the latest in main (commit 
> b89bc55867d7cb809c379d371d12d409db785154, Org mode version 9.7-pre 
> (release_N/A-N/A-b89bc5 @ /usr/share/emacs/site-lisp/org/)) the "@@latex:" 
> gets parsed as an export snippet despite not having a closing "@@" (because 
> the "@@" is in a different paragraph).

Thanks for reporting!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e340dde63

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Henrik Frisk]

Den fre 11 aug. 2023 kl 09:04 skrev Ihor Radchenko :

> Jonathan Gregory  writes:
>
> >> Jonathan, do you think that your original patch is still what
> >> you want to get merged?
> >
> > Yes, the one I sent on 20 Jul 2023. I haven't had any issues with
> > it so far.
>
> Ok. Would you mind adding a commit message, as described in
> https://orgmode.org/worg/org-contribute.html#first-patch?
>
> And do I understand correctly that no changes in
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
> are needed?
>
> Sorry for being late in this discussion. As a user of ob-lilypond I'm very
happy about these changes. On my last install, as well as my current I have
had to change the following:

(org-babel-get-header params :var) which appears to be outdated, to:

(org-babel--get-vars params)

in the version of ob-lilypond.el from here:
https://github.com/mjago/ob-lilypond/blob/master/lisp/ob-lilypond.el. Which
version of the file are you patching now?

Another request would be to have the variables ly-XXX-pdf-path and
ly-XXX-midi-path settable, or, perhaps, read from the lilypond settings of
corresponding variables. I'm not an elisp programmer but I could look into
that if it's of interest.

/Henrik