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

[Liu Hui]

Hi,

Thank you for the patch!

> 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.

Do we need to limit the table/list size by default, or handle them
only with relevant result type (e.g. `table/list')? Dataframe/array
are often large. The following results are truncated by default
previously, which can be tweaked via np.set_printoptions and
pd.set_option.

#+begin_src python
import numpy as np
return np.random.randint(10, size=(30,40))
#+end_src

#+begin_src python
import numpy as np
return np.random.rand(20,3,4,5)
#+end_src

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

d = {'col1': np.random.rand(100), 'col2': np.random.rand(100)}
return pd.DataFrame(d)
#+end_src

> +def __org_babel_python_format_value(result, result_file, result_params):
> +with open(result_file, 'w') as f:
> +if 'graphics' in result_params:
> +result.savefig(result_file)
> +elif 'pp' in result_params:
> +import pprint
> +f.write(pprint.pformat(result))
> +else:
> +if not set(result_params).intersection(\
> +['scalar', 'verbatim', 'raw']):
> +try:
> +import pandas
> +except ImportError:
> +pass
> +else:
> +if isinstance(result, pandas.DataFrame):
> +result = [[''] + list(result.columns), None] + \

Here we can use '{}'.format(df.index.name) to show the name of index

>  (defun org-babel-python-format-session-value
>  (src-file result-file result-params)
>"Return Python code to evaluate SRC-FILE and write result to RESULT-FILE."
> -  (format "\
> +  (concat org-babel-python--def-format-value
> +  (format "

Maybe `org-babel-python--def-format-value' can be evaluated only once
in the session mode? It would shorten the string sent to the python
shell, where temp files are used for long strings.

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

[Jack Kamm]

Ihor Radchenko  writes:

> What about 
>
>  #+begin_src python :results table
>return {"a": 1, "b": 2}
>  #+end_src
>
>  #+RESULTS:
>  | a | 1 |
>  | b | 2 |

I attach a 2nd patch implementing this. It also makes ":results table"
the default return type for dict. (Use ":results verbatim" to get the
dict as a string instead).

I am also putting a branch with these changes here:
https://github.com/jackkamm/org-mode/tree/python-results-revisited-2023

>
> or 
>
>  #+begin_src python :results list
>return {"a": 1, "b": 2}
>  #+end_src
>
>  #+RESULTS:
>  - a :: 1
>  - b :: 2

This seems harder, and may require more widespread changes beyond
ob-python. In particular, I think we'd need to change
`org-babel-insert-result' so that it can call `org-list-to-org' with a
list of type "descriptive" instead of "unordered" here:

https://git.sr.ht/~bzg/org-mode/tree/cc435cba71a99ee7b12676be3b6e1211a9cb7285/item/lisp/ob-core.el#L2535

>From c24d2eeb3b8613df9b9c23583a4b26a6c0934931 Mon Sep 17 00:00:00 2001
From: Jack Kamm 
Date: Wed, 16 Aug 2023 20:27:10 -0700
Subject: [PATCH 2/2] ob-python: Convert dicts to tables

This commit to be squashed with its parent before applying
---
 etc/ORG-NEWS  |  8 +++-
 lisp/ob-python.el | 12 +---
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 2630554ae..509011737 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -578,11 +578,9 @@ tested property is actually present.
 
 *** =ob-python.el=: Support for more result types and plotting
 
-=ob-python= now recognizes numpy arrays, and pandas dataframes/series,
-and will convert them to org-mode tables when appropriate.
-
-In addition, dict results are now returned in appropriate string form,
-instead of being mangled as they were previously.
+=ob-python= now recognizes dictionaries, numpy arrays, and pandas
+dataframes/series, and will convert them to org-mode tables when
+appropriate.
 
 When the header argument =:results graphics= is set, =ob-python= will
 use matplotlib to save graphics. The behavior depends on whether value
diff --git a/lisp/ob-python.el b/lisp/ob-python.el
index 35a82afc0..3d987da2f 100644
--- a/lisp/ob-python.el
+++ b/lisp/ob-python.el
@@ -144,9 +144,7 @@ (defun org-babel-python-table-or-string (results)
   "Convert RESULTS into an appropriate elisp value.
 If the results look like a list or tuple, then convert them into an
 Emacs-lisp table, otherwise return the results as a string."
-  (let ((res (if (string-equal "{" (substring results 0 1))
- results ;don't covert dicts to elisp
-   (org-babel-script-escape results
+  (let ((res (org-babel-script-escape results)))
 (if (listp res)
 (mapcar (lambda (el) (if (eq el 'None)
  org-babel-python-None-to el))
@@ -242,6 +240,14 @@ (defconst org-babel-python--def-format-value "\
 else:
 if not set(result_params).intersection(\
 ['scalar', 'verbatim', 'raw']):
+def dict2table(res):
+if isinstance(res, dict):
+return [(k, dict2table(v)) for k, v in res.items()]
+elif isinstance(res, list) or isinstance(res, tuple):
+return [dict2table(x) for x in res]
+else:
+return res
+result = dict2table(result)
 try:
 import pandas
 except ImportError:
-- 
2.41.0

Re: High CPU with org-set-tags-command in org-capture buffer

[Russell Adams]

On Wed, Aug 16, 2023 at 11:31:10AM -0600, Derek Chen-Becker wrote:
> Hi, I recently upgrade to Emacs 29.1 and I also pulled the latest org
> (commit cc435cba7), and I just noticed that when I'm in an org capture
> buffer and try to execute org-set-tags-command, the CPU goes to 100% and
> just seems to stay there (I gave up and hit ctrl-G after a couple of
> minutes). The same command works fine outside of a capture buffer. It looks
> like a duplicate of what was reported in
> https://lists.gnu.org/archive/html/emacs-orgmode/2023-05/msg00402.html. Am
> I correct that this is unresolved/unreproducible by others? If so, I'll see
> if I can get a minimal repro.

Are you running Helm? I think it does a full inventory of the file to
find tags to present to you to pick.

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

Re: High CPU with org-set-tags-command in org-capture buffer

[Ihor Radchenko]

Derek Chen-Becker  writes:

> ... It looks
> like a duplicate of what was reported in
> https://lists.gnu.org/archive/html/emacs-orgmode/2023-05/msg00402.html.

Hard to say, because I was not able to reproduce.

> ... Am
> I correct that this is unresolved/unreproducible by others? If so, I'll see
> if I can get a minimal repro.

That would be nice. I cannot help without being able to see the problem.

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

High CPU with org-set-tags-command in org-capture buffer

[Derek Chen-Becker]

Hi, I recently upgrade to Emacs 29.1 and I also pulled the latest org
(commit cc435cba7), and I just noticed that when I'm in an org capture
buffer and try to execute org-set-tags-command, the CPU goes to 100% and
just seems to stay there (I gave up and hit ctrl-G after a couple of
minutes). The same command works fine outside of a capture buffer. It looks
like a duplicate of what was reported in
https://lists.gnu.org/archive/html/emacs-orgmode/2023-05/msg00402.html. Am
I correct that this is unresolved/unreproducible by others? If so, I'll see
if I can get a minimal repro.

Thanks,

Derek

-- 
+---+
| Derek Chen-Becker |
| GPG Key available at https://keybase.io/dchenbecker and   |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+

Re: [POLL] [BUG] Inverse behavior from \ [9.6.4 (release_9.6.4-1-g76cf21 @ /Users/johnw/.emacs.d/lisp/org-mode/lisp/)]

[John Wiegley]

> Ihor Radchenko  writes:

> No further votes.
> I am thus leaving the current behavior.
> Closed, poll.
> Canceled, bug.

Understood, thank you very much for the consideration. I’m training my fingers
to the current behavoir.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

[BUG] Global agenda TODO list not able to filter to some custom [9.7 (9.7-??-6eb773053 @ /home/shortcut/.emacs.d/.local/straight/build-28.1/org/)] keywords

[spookygostee]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don’t know how to make a good report?  See



Your bug report will be posted to the Org mailing list.

When adding a custom sequence of todo keywords to `org-todo-keywords', “`[ ]' 
-> `[X]'”, the function `org-todo-list' will not filter to those entries with 
keyword `[ ]', and entries with keyword `[X]' will not be displayed at all.

Steps to reproduce:
1. Add the sequence `(sequence "[ ]" "[X]")' to the `org-todo-keywords' list.

2. Add an org file with the following contents /as entries/ to the front of the 
agenda list:

   ┌
   │ [ ] Unchecked and will appear in agenda
   │ [X] Checked and will not appear in agenda
   │ TODO Todo and will appear in agenda
   │ DONE Done and will appear in agenda
   └
   (due to a quirk of my email client, I cannot paste the above as actual 
entries. Their structure does not matter, so long as they are all entries.)

3. Call `org-todo-list'

   You will note that “Todo and will appear in agenda”, “Done and will appear 
in agenda”, and “Unchecked and will appear in agenda” are listed. However, 
“Checked and will not appear in agenda will not”.

4. Press `NUM r', where `NUM' is the number corresponding to the keyword `[ ]'

   No entries will be displayed.

5. Press `NUM2 r', where `NUM2' is the number corresponding to the keyword `[X]'

   No entries will be displayed.

Despite what my org mode version says, I have tested this on the latest commit 
available for Emacs 28.1.

Emacs  : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, 
cairo version 1.16.0)
 of 2022-05-31
Package: Org mode version 9.7 (9.7-??-6eb773053 @ 
/home/shortcut/.emacs.d/.local/straight/build-28.1/org/)

Re: BUG: org-cut-special on inlinetask kill until point-max

[Ihor Radchenko]

Michael Dauer  writes:

> No. Here also * h2 gets killed by org-cut-special.

You may need to pull the latest main.

> What is REPRO_ARGS? org-onlinetask.el is included org repo anyway?

See https://orgmode.org/manual/Feedback.html#Feedback
REPRO_ARGS are just extra arguments passed to Emacs when opening it in a
clean environment in current Org git repo.

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

Re: BUG: org-cut-special on inlinetask kill until point-max

[Michael Dauer]

No. Here also * h2 gets killed by org-cut-special.

What is REPRO_ARGS? org-onlinetask.el is included org repo anyway?

Ihor Radchenko  schrieb am Mi., 16. Aug. 2023, 14:11:

> Michael Dauer  writes:
>
> > Put the point on the second line - the inlinetask "ilt".
>
> I tried the following:
>
> 1. make repro REPRO_ARGS="/tmp/bug.org"
> 2. Move to **... ilt line
>
> * h1
> *** ilt
> *** END
> ** h11
> * h2
>
>
> 3. M-x org-cut-special
>
> * h1
> *** END
> ** h11
> * h2
>
> As expected.
>
> Then, I also tried
>
> 1. make repro REPRO_ARGS="-l org-inlinetask /tmp/bug.org"
> 2. Move to **... ilt line
>
> * h1
> *** ilt
> *** END
> ** h11
> * h2
>
>
> 3. M-x org-cut-special
>
> * h1
> * h2
>
> Is it what you are seeing?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [MAINTENANCE] Org orphanage?

[Jonas Bernoulli]

Bastien  writes:

> Ihor Radchenko  writes:
>
>>> Indeed, perhaps https://github.com/emacsorphanage is a good shelter
>>> for Org orphan packages already.
>>
>> It is a good shelter, but I was hoping to promote Sourcehut and
>> discourage people using Github to report issues in favour of Org mailing
>> list.
>
> I see, and I agree, especially if issues against Org orphan packages
> are to be reported on the Org mailing list at some point.
>
> Shall I create https://git.sr.ht/~bzg/org-orphan-packages ?
>
>> Otherwise, I have no objections to Jonas Bernoulli doing the background
>> maintenance. Less work for us at the end.
>
> It's probably wiser to expect org-orphan-packages maintainers to come
> from the Org community, rather than drawning Jonas Bernoulli into more
> maintenance workload...

That's certainly appreciated. ;P

I think what we have now is a good compromise.  We continue to use the
existing emacsorphanage for org-related packages, which previously were
maintained on github anyway.  If more org-related packages are abandoned
and they already use github, then I will continue to suggest to their
maintainers to transfer them to the emacsorphanage, but let you know
about it.  For ideological reasons, packages shouldn't be *moved to*
github, but if they are already there, it seems okay to keep them there
a bit longer.

Packages that need a new home and previously were maintained somewhere
other than github, should probably be hosted on https://git.sr.ht/~bzg
for now.

>> One thing we may do though is letting him know about
>> https://orgmode.org/worg/org-orphanage.html - he may contact us or use
>> GitHub mentions, and he may let us know when a new Org-related package
>> lands on his repo.

Will do.

 Jonas

Re: [MAINTENANCE] Org orphanage?

[Jonas Bernoulli]

Ihor Radchenko  writes:

> So, we now have https://orgmode.org/worg/org-orphanage.html

I just went through the list of packages mentioned there as being hosted
on https://github.com/emacsorphanage:

- org-grep should be delisted as it found a new home at
  https://sr.ht/~minshall/org-grep/

- ox-pandoc lists Alex Fenton @a-fent as an outside collaborator with
  admin rights

- org-page lists Kelvin Hu @sillykelvin as an outside collaborator with
  write access

- help-find-org-mode lists Eric Crosson as an outside collaborator with
  write access

IMO it would be a good idea if Bastien and/or Ihor joined the
emacsorphanage and explicitly added themselves to these packages as
admins.

I think I would have to make you owners of emacsorphanage to allow you
to do this and other useful things on your own.  I would happily give
you those rights.  You will know better than me who else should get
write access or even admin rights.  But I would ask you to not *delete*
any repositories before consulting with me.  Also, ping me after adding
a new repository.  How does that sound?

 Jonas

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

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías  writes:
>
>> 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.
>
> +1

Here is the modified patch.

--
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

>From 8c77b42404ef5d96b2944e8e43bbc6c9412ad808 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Mon, 14 Aug 2023 21:48:58 +0200
Subject: [PATCH] lisp/ox-latex.el: add the `:literal' attribute to verse
 block.

* (org-latex-verse-block): now the treatment of blank lines is
consistent with the syntax of the LaTeX `verse' environment, and the
one provided by the `verse' package. If the `:literal' attribute is
used, all blank lines are preserved and exported as
`\vspace*{\baselineskip}', including the blank lines before or after
contents.  The rx code has been suggested by Ihor Radchenko, to
improve readability.

* doc/org-manual.org (Verse blocks in LaTeX export): the new feature
is documented.
---
 doc/org-manual.org | 18 ++
 lisp/ox-latex.el   | 36 +++-
 2 files changed, 41 insertions(+), 13 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index e59efc417..e52792183 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -14425,10 +14425,10 @@ The LaTeX export backend converts horizontal rules by the specified
 #+cindex: verse blocks, in @LaTeX{} export
 #+cindex: @samp{ATTR_LATEX}, keyword
 
-The LaTeX export backend accepts four attributes for verse blocks:
-=:lines=, =:center=, =:versewidth= and =:latexcode=.  The three first
-require the external LaTeX package =verse.sty=, which is an extension
-of the standard LaTeX environment.
+The LaTeX export backend accepts five attributes for verse blocks:
+=:lines=, =:center=, =:versewidth=, =:latexcode= and =:literal=.  The
+three first require the external LaTeX package =verse.sty=, which is
+an extension of the standard LaTeX environment.
 
 - =:lines= :: To add marginal verse numbering.  Its value is an
   integer, the sequence in which the verses should be numbered.
@@ -14440,6 +14440,16 @@ of the standard LaTeX environment.
   verse.
 - =:latexcode= :: It accepts any arbitrary LaTeX code that can be
   included within a LaTeX =verse= environment.
+- =:literal= :: With value t, all blank lines are preserved and
+  exported as =\vspace*{\baselineskip}=, including the blank lines
+  before or after contents.  Note that without the =:literal=
+  attribute, one or more blank lines between stanzas are exported as a
+  single blank line, and any blank lines before or after the content
+  are removed, which is more consistent with the syntax of the LaTeX
+  `verse' environment, and the one provided by the `verse' package.
+  If the =verse= package is loaded, the vertical spacing between all
+  stanzas can be controlled by the global length =\stanzaskip= (see
+  https://www.ctan.org/pkg/verse).
 
 A complete example with Shakespeare's first sonnet:
 
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 31cad1dc4..d11e3befa 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -4116,10 +4116,11 @@ contextual information."
   (let* ((lin (org-export-read-attribute :attr_latex verse-block :lines))
  (latcode (org-export-read-attribute :attr_latex verse-block :latexcode))
  (cent (org-export-read-attribute :attr_latex verse-block :center))
+ (lit (org-export-read-attribute :attr_latex verse-block :literal))
  (attr (concat
-	(if cent "[\\versewidth]" "")
-	(if lin (format "\n\\poemlines{%s}" lin) "")
-	(if latcode (format "\n%s" latcode) "")))
+		(if cent "[\\versewidth]" "")
+		(if lin (format "\n\\poemlines{%s}" lin) "")
+		(if latcode (format "\n%s" latcode) "")))
  (versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
  (vwidth (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
  (linreset (if lin "\n\\poemlines{0}" "")))
@@ -4128,20 +4129,37 @@ contextual information."
   verse-block
   ;; In a verse environment, add a line break to each newline
   ;; character and change each white space at beginning of a line
-  ;; into a space of 1 em.  Also change each blank line with
-  ;; a vertical space of 1 em.
+  ;; into a normal space, calculated with `\fontdimen2\font'.  One
+  ;; or more blank lines between lines are exported as a single
+  ;; blank line.  If the `:lines' attribute is used, the last
+  ;; verse of each stanza ends with the string `\\!', according to
+  ;; the syntax of the `verse' package. The separation between
+  ;; stanzas can be controlled with the 

Re: org-assert-version considered harmful

[Stefan Monnier]

> My attempt to use shadowcheck idea you proposed failed with some very
> strange errors and I gave up.
> See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62762#311

For this one I can see the problem.  You define:

(defmacro org-require-with-shadowcheck (feature)
  [...]
  `(eval-and-compile ...))

so it will behave like a function, except that it's also
executed during macroexpansion, so the (require 'org-element) within
`org-set-modules` will be eagerly executed while loading `org.el` :-(

You should define `org-require-with-shadowcheck` as a function (just
like `require`).

> Although, part of the problem was
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65286 which does not seem
> to be reproducible by others.

Haven't tried to look into this one yet.


Stefan

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

[Bastien Guerry]

Ihor Radchenko  writes:

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

Thanks!

-- 
 Bastien Guerry

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?)

[Jonathan Gregory]

Hi Ihor,

On 11 Aug 2023, Ihor Radchenko wrote:

Ok. Would you mind adding a commit message, as described in 
https://orgmode.org/worg/org-contribute.html#first-patch?


Patch attached. I also attached a test file.

And do I understand correctly that no changes in 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html 
are needed?


Probably not, but I'll check.

--
Jonathan
commit 8916c9ebbefb1b1d448e0e39998f9b9a3b054680
Author: Jonathan Gregory 
Date:   Wed Aug 16 09:47:09 2023 -0300

lisp/ob-lilypond.el: Prevent full page results in basic-mode

* ob-lilypond.el (org-babel-lilypond-paper-settings): New variable.
Link: https://list.orgmode.org/87a5w15jur.fsf@localhost/

TINYCHANGE

diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el
index 9693b89e2..ad8371c5f 100644
--- a/lisp/ob-lilypond.el
+++ b/lisp/ob-lilypond.el
@@ -175,31 +175,51 @@ specific arguments to =org-babel-tangle=."
   (if (org-babel-tangle nil "yes" "lilypond")
   (org-babel-lilypond-execute-tangled-ly) nil))
 
+;; https://lilypond.org/doc/v2.24/Documentation/usage/other-programs
+(defvar org-babel-lilypond-paper-settings
+  "#(if (ly:get-option 'use-paper-size-for-page)
+(begin (ly:set-option 'use-paper-size-for-page #f)
+   (ly:set-option 'tall-page-formats '%s)))
+\\paper {
+  indent=0\\mm
+  tagline=\"\"
+  oddFooterMarkup=##f
+  oddHeaderMarkup=##f
+  bookTitleMarkup=##f
+  scoreTitleMarkup=##f
+}\n"
+  "The paper settings required to generate music fragments.
+They are needed for mixing music and text in basic-mode.")
+
 (defun org-babel-lilypond-process-basic (body params)
   "Execute a lilypond block in basic mode."
   (let* ((out-file (cdr (assq :file params)))
+ (file-type (file-name-extension out-file))
 	 (cmdline (or (cdr (assq :cmdline params))
 		  ""))
 	 (in-file (org-babel-temp-file "lilypond-")))
 
 (with-temp-file in-file
-  (insert (org-babel-expand-body:generic body params)))
+  (insert
+   (format org-babel-lilypond-paper-settings file-type)
+   (org-babel-expand-body:generic body params)))
 (org-babel-eval
  (concat
   org-babel-lilypond-ly-command
   " -dbackend=eps "
   "-dno-gs-load-fonts "
   "-dinclude-eps-fonts "
-  (or (cdr (assoc (file-name-extension out-file)
-		  '(("pdf" . "--pdf ")
-			("ps" . "--ps ")
-			("png" . "--png "
+  (or (assoc-default file-type
+ '(("pdf" . "--pdf ")
+			   ("eps" . "--eps ")))
 	  "--png ")
   "--output="
   (file-name-sans-extension out-file)
   " "
   cmdline
-  in-file) "")) nil)
+  in-file)
+ ""))
+  nil)
 
 (defun org-babel-prep-session:lilypond (_session _params)
   "Return an error because LilyPond exporter does not support sessions."
#+title: Test
#+PROPERTY: header-args:lilypond :noweb yes :exports results
#+PROPERTY: header-args:lilypond :prologue (org-babel-ref-resolve "settings[]")

Some text.

#+begin_src lilypond :file myfile.pdf
\score {
  \new Staff \relative c' {
\tempo 4 = 160
c4 e g b
c4 b d c
\tempo 4 = 96
d,4 fis a cis
d4 cis e d
  }
  \layout { }
  \midi { }
}
#+end_src

#+results:
[[file:myfile.pdf]]

Click [[file:myfile.midi][here]] to listen to the MIDI output.

#+name: settings
#+begin_src lilypond :exports none
\version "2.24.1"
% More lilypond settings here...
#+end_src

Re: Someone to help merging orgmode.org/contribute.html and orgmode.org/worg/org-contribute.html ?

[Bastien Guerry]

Ihor Radchenko  writes:

> I notice that the old https://orgmode.org/contribute.html is still lying
> around. Should we remove it? Or put a redirect?

I've put a redirect to https://orgmode.org/worg/org-contribute.html
and removed the old page.

Thanks!

-- 
 Bastien Guerry

Re: [BUG] (Error "rx '**' range error") [9.7 (9.7-??-d6f3aed @ /home/dodo/.emacs.d/.local/straight/build-29.1/org/)]

[Ihor Radchenko]

Dominic Ross  writes:

> I've been playing around with the themes of my Emacs. I had an org 
> buffer open when I quit Emacs (C-w q) and it asked me if I wanted to 
> save the org buffer. I selected y, then quit.
>
> When I reloaded Emacs, I pressed (SPC q l) to reload the last session, 
> and this error occurred. I'm not sure why, but I'd just added something 
> to the config.el file.

This usually happens when you try to run Org commands in non-Org buffer.

May you set debug-on-error to t in your config and share the backtrace
next time the error appears? The backtrace is necessary for me to
understand in more details what exactly is going on.

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

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

[Ihor Radchenko]

Tom Gillespie  writes:

> PS A new issue arises however caused by
> 487f39efa68fa2d857f8d446d1c4b3a3b3e3f482,
> which is that it is now confusing  to get the {{{results(=value=)}}}
> macro without verbatim which is what :results drawer meant in
> that context. I expect that change will break things for a number
> of people beyond myself. A bit of reading the code revealed that
> setting :wrap t makes it possible to get {{{results(value)}}} again,
> but line 2647 [1] seems to indicate that drawer is an expected
> and valid value for inline :results.
>
>
> 1.
>((or (member "drawer" result-params)
> ;; Stay backward compatible with <7.9.2
> (member "wrap" result-params))
> (goto-char beg) (when (org-at-table-p) (org-cycle))
> (funcall wrap ":results:" ":end:" 'no-escape nil
>  "{{{results(" ")}}}"))

It was a slip when the patch was applied.
See the table of :results params vs. expected output that Nicolas
provided in
https://list.orgmode.org/orgmode/87zjbqrapy@nicolasgoaziou.fr/

Or maybe I miss something.

May you please explain more about {{{results(=value=)}}} problem?
Isn't it sufficient to do src_elisp[:results verbatim]{'value} 
{{{results(=value=)}}}?

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

[BUG] (Error "rx '**' range error") [9.7 (9.7-??-d6f3aed @ /home/dodo/.emacs.d/.local/straight/build-29.1/org/)]

[Dominic Ross]

I've been playing around with the themes of my Emacs. I had an org 
buffer open when I quit Emacs (C-w q) and it asked me if I wanted to 
save the org buffer. I selected y, then quit.


When I reloaded Emacs, I pressed (SPC q l) to reload the last session, 
and this error occurred. I'm not sure why, but I'd just added something 
to the config.el file.


Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See

https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.




Emacs : GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.38, cairo version 1.17.8)
Package: Org mode version 9.7 (9.7-??-d6f3aed @ 
/home/dodo/.emacs.d/.local/straight/build-29.1/org/)


current state:
==
(setq
org-link-elisp-confirm-function nil
org-directory "~/org/"
org-after-refile-insert-hook '(save-buffer)
org-indirect-buffer-display 'current-window
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]
org-load-hook '(+org-init-org-directory-h +org-init-appearance-h 
+org-init-agenda-h

+org-init-attachments-h +org-init-babel-h +org-init-babel-lazy-loader-h
+org-init-capture-defaults-h +org-init-capture-frame-h
+org-init-custom-links-h +org-init-export-h +org-init-habit-h
+org-init-hacks-h +org-init-keybinds-h +org-init-popup-rules-h
+org-init-smartparens-h)
org-startup-folded nil
org-babel-after-execute-hook 
'(+org-redisplay-inline-images-in-babel-result-h)

org-link-abbrev-alist '(("doomdir" . "/home/dodo/.doom.d/%s")
("emacsdir" . "/home/dodo/.emacs.d/%s")
("doom-repo" . "https://github.com/doomemacs/doomemacs/%s;)
("wolfram" . "https://wolframalpha.com/input/?i=%s;)
("wikipedia" . "https://en.wikipedia.org/wiki/%s;)
("duckduckgo" . "https://duckduckgo.com/?q=%s;)
("gmap" . "https://maps.google.com/maps?q=%s;)
("gimages" . "https://google.com/images?q=%s;)
("google" . "https://google.com/search?q=;)
("youtube" . "https://youtube.com/watch?v=%s;)
("github" . "https://github.com/%s;))
org-agenda-files '("~/org/")
org-capture-templates '(("t" "Personal todo" entry
(file+headline +org-capture-todo-file "Inbox") "* [ ] %?\n%i\n%a"
:prepend t)
("n" "Personal notes" entry
(file+headline +org-capture-notes-file "Inbox") "* %u %?\n%i\n%a"
:prepend t)
("j" "Journal" entry (file+olp+datetree +org-capture-journal-file)
"* %U %?\n%i\n%a" :prepend t)
("p" "Templates for projects")
("pt" "Project-local todo" entry
(file+headline +org-capture-project-todo-file "Inbox")
"* TODO %?\n%i\n%a" :prepend t)
("pn" "Project-local notes" entry
(file+headline +org-capture-project-notes-file "Inbox")
"* %U %?\n%i\n%a" :prepend t)
("pc" "Project-local changelog" entry
(file+headline +org-capture-project-changelog-file "Unreleased")
"* %U %?\n%i\n%a" :prepend t)
("o" "Centralized templates for projects")
("ot" "Project todo" entry #'+org-capture-central-project-todo-file
"* TODO %?\n %i\n %a" :heading "Tasks" :prepend nil)
("on" "Project notes" entry
#'+org-capture-central-project-notes-file "* %U %?\n %i\n %a"
:heading "Notes" :prepend t)
("oc" "Project changelog" entry
#'+org-capture-central-project-changelog-file "* %U %?\n %i\n %a"
:heading "Changelog" :prepend t)
)
org-persist-after-read-hook '(org-element--cache-persist-after-read)
org-refile-targets '((nil :maxlevel . 3) (org-agenda-files :maxlevel . 3))
org-export-before-parsing-hook '(org-attach-expand-links)
org-cycle-tab-first-hook '(+org-yas-expand-maybe-h +org-indent-maybe-h
org-babel-hide-result-toggle-maybe org-babel-header-arg-expand
+org-clear-babel-results-h +org-cycle-only-current-subtree-h)
org-default-notes-file "/home/dodo/org/notes.org"
org-refile-use-outline-path 'file
org-archive-hook '(org-attach-archive-delete-maybe)
org-file-apps '((remote . emacs) (auto-mode . emacs) (directory . emacs)
("\\.mm\\'" . default) ("\\.x?html?\\'" . default) ("\\.pdf\\'" . default))
org-cycle-hook '(org-cycle-hide-archived-subtrees 
org-cycle-show-empty-lines

org-cycle-optimize-window-after-visibility-change
org-cycle-display-inline-images)
org-persist-before-read-hook '(org-element--cache-persist-before-read)
org-font-lock-set-keywords-hook '(doom-themes-enable-org-fontification)
org-modules '(ol-bibtex)
org-image-actual-width nil
org-attach-use-inheritance t
org-mode-local-vars-hook '(+indent-guides-disable-maybe-h +org-init-gifs-h)
org-mode-hook '(er/add-org-mode-expansions 
+lookup--init-org-mode-handlers-h

(closure (t) ( _)
(add-hook 'before-save-hook 'org-encrypt-entries nil t))
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-fold-show-all append local] 5]
#[0 "\301\211\207" [imenu-create-index-function org-imenu-get-tree] 2]
doom-disable-show-paren-mode-h doom-disable-show-trailing-whitespace-h
+org-make-last-point-visible-h evil-org-mode toc-org-enable
#[0 "\300\301\302\303\304$\207"
[add-hook 

Re: org-assert-version considered harmful

[Ihor Radchenko]

Stefan Monnier  writes:

>> After trying several more approaches,
>
> [ Side note: did you keep notes about the various approaches you tried
>   and their respective downsides?  E.g. I'm curious what were the
>   problems linked to my proposal of using a `require-with-check` like
>   the one below my sig.  ]

My attempt to use shadowcheck idea you proposed failed with some very
strange errors and I gave up.
See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62762#311

Although, part of the problem was
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65286 which does not seem
to be reproducible by others.

>> I now came up with yet another idea.  Instead of fiddling with load
>> internals, compilation, or load-path, what about making sure that Org
>> libraries include version info directly?
>
> That should work.  It implies a fair bit more churn in the code, tho,
> but I guess you plan to automate it via some scripts?

Yeah. It will require search-and-replace across Org between releases.
But, at least, it is the most reliable way I can see without falling
into subtle details of Emacs load system.

I did some automation in a form of =make test= barking when `provide' do
not match Org version:

>From 9caf9ca7207ecebed3499432828833187436940d Mon Sep 17 00:00:00 2001
Message-ID: <9caf9ca7207ecebed3499432828833187436940d.1692189593.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Wed, 16 Aug 2023 13:59:49 +0300
Subject: [PATCH] * testing/lisp/test-org-version.el: New test library

(test-org-version/provide): Test for all the versioned features to be
provided according to current Org version.
---
 testing/lisp/test-org-version.el | 54 
 1 file changed, 54 insertions(+)
 create mode 100644 testing/lisp/test-org-version.el

diff --git a/testing/lisp/test-org-version.el b/testing/lisp/test-org-version.el
new file mode 100644
index 0..3c12c8d46
--- /dev/null
+++ b/testing/lisp/test-org-version.el
@@ -0,0 +1,54 @@
+;;; test-org-version.el --- Test Org version consistency  -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2023  Ihor Radchenko
+
+;; Author: Ihor Radchenko 
+;; Keywords: internal
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see .
+
+;;; Commentary:
+
+;; This file implements internal checks for Org versioning.
+
+;;; Code:
+
+(require 'org-version)
+
+(ert-deftest test-org-version/provide ()
+  "Test versioned `provide' calls in Org libraries."
+  (let* (org-library)
+(dolist (org-library-file
+ (directory-files
+  (expand-file-name
+	   (concat org-test-dir "../lisp"))
+  t "\\.el$"))
+  (setq org-library
+(file-name-nondirectory
+ (file-name-sans-extension org-library-file)))
+  (unless (member org-library '("org-loaddefs" "org-version"))
+(with-temp-buffer
+  (insert-file-contents org-library-file)
+  (goto-char (point-max))
+  (should (re-search-backward
+   (rx-to-string
+`(seq
+  bol (0+ space)
+  "(provide" (0+ space)
+  "'" ,(concat org-library "-" (org-release))
+  (0+ space) ")"))
+   nil t)))
+
+(provide 'test-org-version)
+;;; test-org-version.el ends here
-- 
2.41.0


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

[PATCH] org.el: Respect org-extend-today-until in timestamps with ++

[General discussions about Org-mode.]

* org.el (org-auto-repeat-maybe): Changed org-auto-repeat-maybe, so that
switching a repeating todo with a timestamp of the form <… ++…> respects
`org-extend-today-until'.
---
 lisp/org.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index c037b3ee0..d9cc9bee6 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10099,9 +10099,10 @@ This function is run automatically after each state 
change to a DONE state."
 (- (org-today) (time-to-days time)) 'day)))
 ((equal "+" repeater-type)
  (let ((nshiftmax 10)
-   (nshift 0))
+   (nshift 0)
+(time-to-extend (seconds-to-time (* 3600 
org-extend-today-until
(while (or (= nshift 0)
-  (not (time-less-p nil time)))
+   (not (time-less-p nil (time-add 
time-to-extend time
  (when (= nshiftmax (cl-incf nshift))
(or (y-or-n-p
 (format "%d repeater intervals were not \
-- 
2.40.1

Re: [BUG] org-set-tags-command hangs indefinitely in some indirect buffers [9.7-pre (release_9.6.6-412-g2f7b35 @ /home/adam/.emacs.d/straight/repos/org/lisp/)]

[Adam Beckmeyer]

Here's a backtrace when C-g in the middle of the hanging `org-set-tags-command`:

Debugger entered--Lisp error: (quit)
  org-element-headline-parser(990890 t)
  #f(compiled-function (limit  granularity mode structure) "Parse the 
element starting at point.\n\nReturn value is a list like (TYPE PROPS) where 
TYPE is the type\nof the element and PROPS a plist of properties associated to 
the\nelement.\n\nPossible types are defined in 
`org-element-all-elements'.\n\nLIMIT bounds the search.\n\nOptional argument 
GRANULARITY determines the depth of the\nrecursion.  Allowed values are 
`headline', `greater-element',\n`element', `object' or nil.  When it is broader 
than `object' (or\nnil), secondary values will not be parsed, since they 
only\ncontain objects.\n\nOptional argument MODE, when non-nil, can be 
either\n`first-section', `item', `node-property', 
`planning',\n`property-drawer', `section', `table-row', or 
`top-comment'.\n\n\nIf STRUCTURE isn't provided but MODE is set to `item', it 
will be\ncomputed.\n\nThis function assumes point is always at the beginning of 
the\nelement it has to parse." #)(990890 element 
nil nil)
  org-element--parse-to(990890)
  org-element-at-point(990890)
  org-element-cache-map(#f(compiled-function (el) #))
  org-get-buffer-tags()
  org-set-tags-command(nil)
  funcall-interactively(org-set-tags-command nil)
  command-execute(org-set-tags-command)

Re: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++

[Valentin G. J. Herrmann]

I've now added org-test-with-time-locale so that the test results are 
independent of the running machine. I think it's much cleaner this way 
than using .*


On 14/08/2023 14.51, Ihor Radchenko wrote:

"Valentin G. J. Herrmann"  writes:


Ok, so I guess I was stupid in another way :E
I do in fact have the FSF copyright assignment (Though probably under an
old email address: herr.valentin.m...@gmail.com). I still included the
TINYCHANGE comment. The attached patch should finally work.


Bastien, may you please check the FSF records?


-   (string-match-p
-"2014-03-04 .* 02:00"
+   (string-search
+"<2014-03-04 Tue 02:00 +8h>"


This won't work for people testing in non-English language environments
where the day names are in native language.
.* was there for a reason.
From 44320eea066f6db6ee82e5fd78b74cdb3d026b82 Mon Sep 17 00:00:00 2001
From: Valentin Herrmann 
Date: Sun, 13 Aug 2023 18:44:49 +0200
Subject: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* org.el (org-auto-repeat-maybe): Changed org-auto-repeat-maybe, so that
switching a repeating todo with a timestamp of the form <… ++…> respects
`org-extend-today-until'.
* test-org.el (test-org/auto-repeat-maybe, org-test-with-time-locale):
Tests for interaction of `org-extend-today-until' and
`org-auto-repeat-maybe'. Added `org-test-with-time-locale' to make test
results independent of running machine. Explicitly avoid matching log
note with old timestamp in all the tests to avoid confusion.

Co-authored-by: Ihor Radchenko 

TINYCHANGE
---
 lisp/org.el  |  5 ++-
 testing/lisp/test-org.el | 78 +---
 2 files changed, 70 insertions(+), 13 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index c037b3ee0..325141b25 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10101,7 +10101,10 @@ This function is run automatically after each state change to a DONE state."
 		  (let ((nshiftmax 10)
 			(nshift 0))
 			(while (or (= nshift 0)
-   (not (time-less-p nil time)))
+   (if (equal what "h")
+   (not (time-less-p nil time))
+ (>= (org-today)
+	 (time-to-days time
 			  (when (= nshiftmax (cl-incf nshift))
 			(or (y-or-n-p
  (format "%d repeater intervals were not \
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 1b00f6c45..40820dfb5 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -75,6 +75,11 @@ Otherwise, evaluate RESULT as an sexp and return its result."
   `(let ((org-time-stamp-formats '("%Y-%m-%d" . "%Y-%m-%d %H:%M")))
  ,@body))
 
+(defmacro org-test-with-time-locale (time-loc  body)
+  (declare (indent 1))
+  `(let ((system-time-locale ,time-loc))
+ ,@body))
+
 
 ;;; Comments
 
@@ -8370,26 +8375,75 @@ Paragraph"
(buffer-string
   ;; Handle every repeater type using hours step.
   (should
-   (string-match-p
-"2014-03-04 .* 02:00"
-(org-test-at-time "<2014-03-04 02:35>"
+   (string-search
+"<2014-03-04 Tue 02:00 +8h>"
+(org-test-with-time-locale "en_US.UTF-8"
+ (org-test-at-time "<2014-03-04 02:35>"
   (org-test-with-temp-text "* TODO H\n<2014-03-03 18:00 +8h>"
 	(org-todo "DONE")
-	(buffer-string)
+	(buffer-string))
   (should
-   (string-match-p
-"2014-03-04 .* 10:00"
-(org-test-at-time "<2014-03-04 02:35>"
+   (string-search
+"<2014-03-04 Tue 10:00 ++8h>"
+(org-test-with-time-locale "en_US.UTF-8"
+ (org-test-at-time "<2014-03-04 02:35>"
   (org-test-with-temp-text "* TODO H\n<2014-03-03 18:00 ++8h>"
 	(org-todo "DONE")
-	(buffer-string)
+	(buffer-string))
   (should
-   (string-match-p
-"2014-03-04 .* 10:35"
-(org-test-at-time "<2014-03-04 02:35>"
+   (string-search
+"<2014-03-04 Tue 10:35 .+8h>"
+(org-test-with-time-locale "en_US.UTF-8"
+ (org-test-at-time "<2014-03-04 02:35>"
   (org-test-with-temp-text "* TODO H\n<2014-03-03 18:00 .+8h>"
 	(org-todo "DONE")
-	(buffer-string)
+	(buffer-string))
+  ;; Handle `org-extend-today-until'.
+  (should
+   (string-search
+"<2014-03-04 Tue ++1d>"
+(let ((org-extend-today-until 4))
+  (org-test-with-time-locale "en_US.UTF-8"
+   (org-test-at-time "<2014-03-04 02:35>"
+(org-test-with-temp-text "* TODO H\n<2014-03-03 ++1d>"
+	  (org-todo "DONE")
+	  (buffer-string)))
+  (should
+   (string-search
+"<2014-03-06 Thu 17:00 ++1d>"
+(let ((org-extend-today-until 4))
+  (org-test-with-time-locale "en_US.UTF-8"
+   (org-test-at-time "<2014-03-05 18:00>"
+(org-test-with-temp-text "* TODO H\n<2014-03-04 17:00 ++1d>"
+	  (org-todo "DONE")
+	  (buffer-string)))
+  (should
+   (string-search
+"<2014-03-04 Tue 10:00 ++8h>"
+(let ((org-extend-today-until 4))
+  (org-test-with-time-locale "en_US.UTF-8"
+   (org-test-at-time "<2014-03-04 02:35>"
+(org-test-with-temp-text "* 

Re: [MAINTENANCE] Org orphanage?

[Hrvoje Nikšić]

>
> It seems to me it would be a good idea if Hrvoje gave one or more Org
> maintainer commit access to this repository.  Alternatively we could
> maintain it at https://github.com/emacsorphanage/htmlize, and I could
> take care of giving commit access, but in that case Hrvoje would also
> have to get involved briefly at least, to transfer the repository to
> that organization.
>

I'd be fine with transferring commit access to the repo. Writing and
maintaining htmlize was much fun, but although I still use Emacs for my
day-to-day work, I haven't done any elisp in many years now. At this point
it's clear that I won't be getting back to it any time soon, so it's time
to pass on the maintainership of htmlize to someone who will take good care
of it. Someone from org mode seems like a great choice for that.

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

Kind regards,
Hrvoje

Re: [MAINTENANCE] Org orphanage?

[Jonas Bernoulli]

Ihor Radchenko  writes:

> Adding Jonas to the loop.
>
> For some more context, we are willing to help maintaining orphan
> Org-related packages if the requests are submitted to Org mailing list.

Thanks, and sorry I forgot about this.  I'll have to think about it some
more before I can make any general suggestions; today I am writing about
one package in particular that needs some help:

`htmlize' is currently maintained at https://github.com/hniksic/emacs-htmlize
but its maintainer hasn't been responding to any issues and pull-requests
for quite some time now and seems to be inactive on Github altogether.

(CCing Hrvoje, in case he has just turned of Github notifications.)

It seems to me it would be a good idea if Hrvoje gave one or more Org
maintainer commit access to this repository.  Alternatively we could
maintain it at https://github.com/emacsorphanage/htmlize, and I could
take care of giving commit access, but in that case Hrvoje would also
have to get involved briefly at least, to transfer the repository to
that organization.

Regardless of where this package will eventually end up being
maintained, it would be a good idea to keep it on Github at least until
most of the issues and pull-requests that have already been opened there
have been resolved.

 Cheers,
 Jonas

[BUG] org-set-tags-command hangs indefinitely in some indirect buffers [9.7-pre (release_9.6.6-412-g2f7b35 @ /home/adam/.emacs.d/straight/repos/org/lisp/)]

[Adam Beckmeyer]

Hi everyone,

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.

I noticed this problem on git master but bisected and found the bug was 
introduced by: 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2f7b35ac89470f17937f5c20524c38db103aaa4c

Emacs  : GNU Emacs 29.1 (build 2, x86_64-unknown-linux-gnu, X toolkit, cairo 
version 1.16.0)
 of 2023-08-02
Package: Org mode version 9.7-pre (release_9.6.6-412-g2f7b35 @ 
/home/adam/.emacs.d/straight/repos/org/lisp/)

Best


Adam Beckmeyer
*** 2021-08 August
 2021-08-23 Monday
*** Hello World   :Foobar:

Re: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++

[Valentin G. J. Herrmann]

In the attachments is a better version with tests that also addresses 
your latest critique.


On 13/08/2023 14.44, Ihor Radchenko wrote:
> Ihor Radchenko  writes:
>
>>>   (while (or (= nshift 0)
>>> -   (not (time-less-p nil time)))
>>> +   (not (time-less-p nil (time-add 
time-to-extend time

>>
>> And this compares "now" with year 1970. Will always return nil.
>
> Hmm. I somehow missed `time-add'.
> However, this is still fishy.
> What if we have something like <2023-08-13 2:00 ++8h>?
> `org-extend-today-until' should probably be ignored then.
>
Attachments:
0001-org.el-Respect-org-extend-today-until-in-timestamps-.patch 3.0 KB
[Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 
Thunderbird/102.14.0]

This user agent is already supported !
[http://www.mozilla.com/thunderbird/]
[Options]From 317ab3f132825af9e5caaf0dc1812df545f0ad5f Mon Sep 17 00:00:00 2001
From: Valentin Herrmann 
Date: Sun, 13 Aug 2023 09:48:42 +0200
Subject: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* org.el (org-auto-repeat-maybe): Changed org-auto-repeat-maybe, so that
switching a repeating todo with a timestamp of the form <… ++…> respects
`org-extend-today-until'.
---
 lisp/org.el  | 10 +++---
 testing/lisp/test-org.el | 33 +
 2 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index c037b3ee0..9c98d7538 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10111,9 +10111,13 @@ enough to shift date past today.  Continue? "
 			  (org-timestamp-change n (cdr (assoc what whata)))
 			  (org-in-regexp org-ts-regexp3)
 			  (setq ts (match-string 1))
-			  (setq time
-(save-match-data
-  (org-time-string-to-time ts)
+  (setq time
+(save-match-data
+  (org-time-string-to-time ts)))
+  (unless (equal what "h")
+(setq time
+  (time-add time
+(seconds-to-time (* 3600 org-extend-today-until)))
 		  (org-timestamp-change (- n) (cdr (assoc what whata)))
 		  ;; Rematch, so that we have everything in place
 		  ;; for the real shift.
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 1b00f6c45..0cf765af4 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -8390,6 +8390,39 @@ Paragraph"
   (org-test-with-temp-text "* TODO H\n<2014-03-03 18:00 .+8h>"
 	(org-todo "DONE")
 	(buffer-string)
+  ;; Handle `org-extend-today-until'.
+  (should
+   (string-match-p
+"2014-03-04 .* 18:00"
+(let ((org-extend-today-until 4))
+  (org-test-at-time "<2014-03-04 02:35>"
+(org-test-with-temp-text "* TODO H\n<2014-03-02 18:00 ++1d>"
+	  (org-todo "DONE")
+	  (buffer-string))
+  (should
+   (string-match-p
+"2014-03-04 .* 10:00"
+(let ((org-extend-today-until 4))
+  (org-test-at-time "<2014-03-04 02:35>"
+(org-test-with-temp-text "* TODO H\n<2014-03-03 18:00 ++8h>"
+	  (org-todo "DONE")
+	  (buffer-string))
+  (should
+   (string-match-p
+"2014-03-04 .* 18:00"
+(let ((org-extend-today-until 4))
+  (org-test-at-time "<2014-03-04 02:35>"
+(org-test-with-temp-text "* TODO H\n<2014-03-03 18:00 .+1d>"
+	  (org-todo "DONE")
+	  (buffer-string))
+  (should
+   (string-match-p
+"2014-03-04 .* 10:35"
+(let ((org-extend-today-until 4))
+  (org-test-at-time "<2014-03-04 02:35>"
+(org-test-with-temp-text "* TODO H\n<2014-03-03 18:00 .+8h>"
+	  (org-todo "DONE")
+	  (buffer-string))
   ;; Do not repeat inactive time stamps with a repeater.
   (should-not
(string-match-p
-- 
2.40.1

Re: Htmlize support, maintenance, and Org mode (was: [MAINTENANCE] Org orphanage?)

[Jonas Bernoulli]

Ihor Radchenko  writes:

> Jonas Bernoulli  writes:
>
>> `htmlize' is currently maintained at https://github.com/hniksic/emacs-htmlize
>> but its maintainer hasn't been responding to any issues and pull-requests
>> for quite some time now and seems to be inactive on Github altogether.
>
> Hmm... Org has built-in htmlize support and I did not know that it is
> not maintained actively.

I only installed htmlize because org-html-fontify-code told me to do so.
Should it not have done that?  I did not have any version of htmlize
installed prior to this.

>> Regardless of where this package will eventually end up being
>> maintained, it would be a good idea to keep it on Github at least until
>> most of the issues and pull-requests that have already been opened there
>> have been resolved.
>
> Or we can simply hand-pick that 13 open Github issues and transfer them
> manually. (Does not mean that we have to do it, but I see not why having
> a few issues on Github should be a blocker to anything)

The idea was to let those who have already opened pull-requests on
Github and have been patiently waiting for a response ever since, to
finish the work there.

Re: org-assert-version considered harmful

[Stefan Monnier]

Ihor Radchenko [2023-08-16 11:08:15] wrote:
> Ihor Radchenko  writes:
>> Stefan Monnier  writes:
>>> BTW, rather than unloading, `package.el` relies on forcibly "re"loading
>>> from the new version the already loaded files from the old version.
>>> It suffers from a different set of problem :-(
>>> [ I suspect `defvar` is the main problem for that solution.  ]
>>
>> Could it be possible to force require use certain package version and
>> automatically re-load a package when older version is being loaded?
>
> After trying several more approaches,

[ Side note: did you keep notes about the various approaches you tried
  and their respective downsides?  E.g. I'm curious what were the
  problems linked to my proposal of using a `require-with-check` like
  the one below my sig.  ]

> I now came up with yet another idea.  Instead of fiddling with load
> internals, compilation, or load-path, what about making sure that Org
> libraries include version info directly?

That should work.  It implies a fair bit more churn in the code, tho,
but I guess you plan to automate it via some scripts?


Stefan


(defun require-with-check (feature  filename noerror)
  "If FEATURE is not already loaded, load it from FILENAME.
This is like `require' except if FEATURE is already a member of the list
‘features’, then we check if this was provided by a different file than the
one that we would load now (presumably because `load-path' has been
changed since the file was loaded)."
  (let ((lh load-history)
(res (require feature filename noerror)))
;; If the `feature' was not yet provided, `require' just loaded the right
;; file, so we're done.
(if (not (eq lh load-history)) res
  ;; If `require' did nothing, we need to make sure that was warranted.
  (let ((fn (locate-file (or filename (symbol-name feature))
 load-path (get-load-suffixes
;; If the right file was indeed loaded already, we're done.
(if (assoc fn load-history) res
  (funcall (if noerror #'warn #'error)
   "Feature provided by other file: %S" feature)
  res)

Re: Someone to help merging orgmode.org/contribute.html and orgmode.org/worg/org-contribute.html ?

[Ihor Radchenko]

Bastien  writes:

>> in the absence of any other volunteer, i'd be happy to produce a merge
>> for review.  (though it might take a few weeks.)
>
> thanks a lot for volunteering, but I did the merge a few days ago.

I notice that the old https://orgmode.org/contribute.html is still lying
around. Should we remove it? Or put a redirect?

-- 
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?

[Ihor Radchenko]

Edgar Lux  writes:

>> And may you please elaborate why you need to preserve indentation? We
>> generally assume that common indentation is not significant.
>
> Collaborating with people who don't use Org, but only LaTeX, and possibly use 
> software which reformats the spacing automatically. Then, this spacing 
> becomes annoying from the perspective of version control systems on both 
> ends. Free world issues, I guess (at least it's not some proprietary format).

You might also do the equivalent reformatting using Auctex after export.

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

Re: BUG: org-cut-special on inlinetask kill until point-max

[Ihor Radchenko]

Michael Dauer  writes:

> Put the point on the second line - the inlinetask "ilt".

I tried the following:

1. make repro REPRO_ARGS="/tmp/bug.org"
2. Move to **... ilt line

* h1
*** ilt
*** END
** h11
* h2


3. M-x org-cut-special

* h1
*** END
** h11
* h2

As expected.

Then, I also tried

1. make repro REPRO_ARGS="-l org-inlinetask /tmp/bug.org"
2. Move to **... ilt line

* h1
*** ilt
*** END
** h11
* h2


3. M-x org-cut-special

* h1
* h2

Is it what you are seeing?

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

Re: [POLL] [BUG] Inverse behavior from \ [9.6.4 (release_9.6.4-1-g76cf21 @ /Users/johnw/.emacs.d/lisp/org-mode/lisp/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> Upon seeing the manual, I am inclined to keep the current behaviour,
> unless we have other voices supporting the change.

No further votes.
I am thus leaving the current behavior.
Closed, poll.
Canceled, bug.

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

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

[Tom Gillespie]

On Wed, Aug 16, 2023 at 2:09 AM Ihor Radchenko  wrote:
>
> Tom Gillespie  writes:
>
> > Subject: [PATCH] ob-tangle.el: restore :tangle closure evaluation before 
> > eval
> >  info
> > 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.
>
> What do you mean by "restore"? Were it evaluated in the past?
> May you please provide a reproducer?

Hrm. I think I may have mixed two commit lines. It is the case that
:tangle closures used to work, but you are right, the historical behavior
when tangling closures meant that all parameters were evaluated (tested
with the block below in 27 and 28).

#+begin_src elisp :var value=(error "oops") :tangle (or "no")
value
#+end_src

My use case is that I have blocks that I want to tangle that set :var
from e.g. the library of babel, which isn't always loaded, but which also
is not required if :tangle is no.

> > -(defun org-babel-tangle--unbracketed-link (params)
> > +(defun org-babel-tangle--unbracketed-link (params  
> > info-was-evaled)
>
> This is not acceptable. Taking care about evaluating INFO should be done
> in a single place instead of adding checks across the babel code. If we
> go the proposed way, I expect a number of bugs appearing when somebody
> forgets to change the eval check in some place.

I don't like the solution either. I see two potential alternatives.
1. change the structure of the info list to indicate whether it has
already been evaluated
2. always call org-babel-read on (cdr (assq :tangle params)) even
if it may already have been evaluated which can lead to some unexpected
and potentially nasty results.

I don't think we can consolidate evaluating parameters
into one place in the general case because there are
order dependencies where a setting in one param header
should mask others (as is the case here). In principle we
could consolidate them, but I think that would add significant
complexity because we would have to push all the logic for
handling whether a given ordering restriction applies inside
that location. e.g. if I have a block set :eval (if ev "yes" "no")
it would be bad form to evaluate the parameters before determining
whether the :eval closure evaluates to "yes" or "no". Should that
go inside org-process-params, or should it be handled locally
by e.g. org-babel-tangle and org-babel-execute-src-block separately?

Thoughts?

Re: BUG: org-cut-special on inlinetask kill until point-max

[Michael Dauer]

Put the point on the second line - the inlinetask "ilt".

Am Mi., 16. Aug. 2023 um 13:47 Uhr schrieb Ihor Radchenko <
yanta...@posteo.net>:

> Michael Dauer  writes:
>
> 
> > * h1
> > *** ilt
> > *** END
> > ** h11
> > * h2
> > <<<
> > org-cut-special somewhere on the send line kills all but the first line.
>
> I am unable to reproduce.
> May you please provide more detailed steps?
> In particular, which line are you referring to?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: BUG: org-cut-special on inlinetask kill until point-max

[Ihor Radchenko]

Michael Dauer  writes:


> * h1
> *** ilt
> *** END
> ** h11
> * h2
> <<<
> org-cut-special somewhere on the send line kills all but the first line.

I am unable to reproduce.
May you please provide more detailed steps?
In particular, which line are you referring to?

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

BUG: org-cut-special on inlinetask kill until point-max

[Michael Dauer]

>>>
* h1
*** ilt
*** END
** h11
* h2
<<<
org-cut-special somewhere on the send line kills all but the first line.

Org mode version 9.7-pre (release_9.6.7-594-gf03b83
I don't think that this bug existed in the previous versions.

Re: org-assert-version considered harmful

[Ihor Radchenko]

Ihor Radchenko  writes:

> Stefan Monnier  writes:
>
>> BTW, rather than unloading, `package.el` relies on forcibly "re"loading
>> from the new version the already loaded files from the old version.
>> It suffers from a different set of problem :-(
>> [ I suspect `defvar` is the main problem for that solution.  ]
>
> Could it be possible to force require use certain package version and
> automatically re-load a package when older version is being loaded?

After trying several more approaches, I now came up with yet another
idea. Instead of fiddling with load internals, compilation, or
load-path, what about making sure that Org libraries include version
info directly?

Every library will have

(require 'org-foo-9.X "org-foo")
(require 'org-bar-9.X "org-bar")
...
(provide 'org-lib)
(provide 'org-lib-9.X)

Then, we will make sure that the right version of the library is always
loaded. Simply because (provide 'org-lib-9.X) will be unique for
different Org releases.

There might still be a problem where we solve cyclic dependencies by
using declare-function, but those places should be fixed anyway, sooner
or later.

WDYT?

-- 
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]

Tom Gillespie  writes:

>> 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:

I am not sure if I like [options]. If we support property drawer, why
would we need additional options? I'd rather stick closer to the heading
syntax (but without that 15x... madness).

I also _slightly_ do not like #+... syntax because I expect some
interference with fontification code for "meta lines".

> 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.

It would actually be a headache to move planning into options.
A number of places in Org hard-code planning line regexp and will have
to be modified significantly to accommodate [options]. In particular, I
have org-agenda in mind (the place I rarely dare to touch)

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

Another idea might be similar to footnote definitions that mark their
end with double blank line. But I do not like footnote definition syntax
because it makes it impossible to have something like

[fn:1] Footnote definition containing src block
#+begin_src elisp
"This has


two newlines and not an src block anymore because
footnote definition ending takes precedence"
#+end_src

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

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

[Ihor Radchenko]

and...@fedeli.eu writes:

>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 :))

May you share your changes? I am not sure if I fully understand what and
why you did without seeing the diff.

>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..

It should not. The reason `org-columns--summary-estimate' uses
split-string is because it may have to work with recursively calculated
estimates from subtrees. EFFORT property itself does not officially
support ranges.

-- 
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?

[Ihor Radchenko]

Edgar Lux  writes:

> 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. 
>
> #+begin_frontmatter
>   #+begin_src latex -i :exports results :eval yes :results replace
>   \title{Determine in-situ matrix properties}
>   \nothing{a}
>   #+end_src
> #+end_frontmatter

I think that you may post-process the result (see :post header arg), adding 
indentation.

-i only affects the code block itself, not its results.

And may you please elaborate why you need to preserve indentation? We
generally assume that common indentation is not significant.

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

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

[Ihor Radchenko]

Tom Gillespie  writes:

>> It was a slip when the patch was applied.
>> May you please explain more about {{{results(=value=)}}} problem?
>> Isn't it sufficient to do src_elisp[:results verbatim]{'value} 
>> {{{results(=value=)}}}?
>
> The issue is the opposite I think. Currently the default value (i.e. absent)
> for :results does not produce {{{results(value)}}} as suggested, and instead
> producers {{{results(=value=)}}}. ...
>
> It looks like there used to be an option [:results wrap] which was deprecated
> a _very_ long time ago. [:results drawer] replaced that, and while there is
> some confusion about the name (because there is no actual drawer in an
> inline result) the behavior was meant to replace the old :results wrap 
> behavior
> where the name does make sense since {{{results(value)}}} do "wrap" the value.

Thanks!
In addition, the docstring of `org-babel-insert-result' says

drawer -- results are added directly to the Org file as with
  "raw", but are wrapped in a RESULTS drawer or results
  macro, allowing them to later be replaced or removed
  automatically.

But not in the manual:

‘drawer’
 Result wrapped in a ‘RESULTS’ drawer.  Useful for containing ‘raw’
 or ‘org’ results for later scripting and automated processing.
 Usage example: ‘:results value drawer’.

Also, removal of :results wrap seemingly missed the inline src block use
case: https://list.orgmode.org/orgmode/876271cjpb@bzg.ath.cx/

Bastien, may you comment?

:results drawer feels confusing for inline src blocks.

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

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

[Tom Gillespie]

> My confusion about you patch comes from the fact that
>
> #+begin_src emacs-lisp :tangle (if (= 1 1) "yes")
> 2
> #+end_src
>
> works just fine on main.

It appears to work fine on main, but that is because
what is actually happening behind the scenes is that in the test
(unless (or (string= src-tfile "no") ...) ...) the actual comparison is
(string= "(if (= 1 1) \"yes\")" "no") which appears to work, but is
not comparing the result of the closure, only its string value.

> I admit that I don't fully understand your use case.

I want to use a closure to conditionally control whether a block will tangle.
If I hardcode :tangle no, then :var x=(error "oops") will not evaluate. The
(error "oops") is a placeholder for a number of things that will result in
an error if the condition for :tangle (when condition "file-name") is not
satisfied.

> Something like (org-babel-get-heading-arg :tangle info/params)

I need to go to bed, because I definitely started on an implementation
of that I forgot about it as a potential solution. Yes, this seems like
a better and clearer way to go about it.

> May you please elaborate?

Disregard, your suggestion clarified what you meant, and in
that case, yes we can consolidate.

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

[Ihor Radchenko]

Tom Gillespie  writes:

>> What do you mean by "restore"? Were it evaluated in the past?
>> May you please provide a reproducer?
>
> Hrm. I think I may have mixed two commit lines. It is the case that
> :tangle closures used to work, but you are right, the historical behavior
> when tangling closures meant that all parameters were evaluated (tested
> with the block below in 27 and 28).
>
> #+begin_src elisp :var value=(error "oops") :tangle (or "no")
> value
> #+end_src

This example clearly shows that evaluating everything is a bad idea.
:var has no effect during tangling anyway.

> My use case is that I have blocks that I want to tangle that set :var
> from e.g. the library of babel, which isn't always loaded, but which also
> is not required if :tangle is no.

My confusion about you patch comes from the fact that

#+begin_src emacs-lisp :tangle (if (= 1 1) "yes")
2
#+end_src

works just fine on main.

I admit that I don't fully understand your use case.

>> > -(defun org-babel-tangle--unbracketed-link (params)
>> > +(defun org-babel-tangle--unbracketed-link (params  
>> > info-was-evaled)
>>
>> This is not acceptable. Taking care about evaluating INFO should be done
>> in a single place instead of adding checks across the babel code. If we
>> go the proposed way, I expect a number of bugs appearing when somebody
>> forgets to change the eval check in some place.
>
> I don't like the solution either. I see two potential alternatives.
> 1. change the structure of the info list to indicate whether it has
> already been evaluated
> 2. always call org-babel-read on (cdr (assq :tangle params)) even
> if it may already have been evaluated which can lead to some unexpected
> and potentially nasty results.

I think that instead of repeating (cdr (assq :tangle params)) we need a
common API that will abstract away evaluation and modify PARAMS by side
effect if necessary.

Something like (org-babel-get-heading-arg :tangle info/params)

> I don't think we can consolidate evaluating parameters
> into one place in the general case because there are
> order dependencies where a setting in one param header
> should mask others (as is the case here).

May you please elaborate?

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

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

[Tom Gillespie]

> It was a slip when the patch was applied.
> See the table of :results params vs. expected output that Nicolas
> provided in
> https://list.orgmode.org/orgmode/87zjbqrapy@nicolasgoaziou.fr/
>
> Or maybe I miss something.
>
> May you please explain more about {{{results(=value=)}}} problem?
> Isn't it sufficient to do src_elisp[:results verbatim]{'value} 
> {{{results(=value=)}}}?

The issue is the opposite I think. Currently the default value (i.e. absent)
for :results does not produce {{{results(value)}}} as suggested, and instead
producers {{{results(=value=)}}}. This means that without :results drawer
there isn't an obvious way to get {{{results(value)}}} because you can't e.g.
use [:results default], or if a user overrides the default value for
inline header
args at file level then they have no way to reset to the default.

It looks like there used to be an option [:results wrap] which was deprecated
a _very_ long time ago. [:results drawer] replaced that, and while there is
some confusion about the name (because there is no actual drawer in an
inline result) the behavior was meant to replace the old :results wrap behavior
where the name does make sense since {{{results(value)}}} do "wrap" the value.

I think that covers it, but let me know if something doesn't make sense. Best,
Tom

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

[Ihor Radchenko]

Jack Kamm  writes:

> 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}

What about 

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

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

or 

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

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

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

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

[Ihor Radchenko]

Tom Gillespie  writes:

> Subject: [PATCH] ob-tangle.el: restore :tangle closure evaluation before eval
>  info
> 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.

What do you mean by "restore"? Were it evaluated in the past?
May you please provide a reproducer?

> -(defun org-babel-tangle--unbracketed-link (params)
> +(defun org-babel-tangle--unbracketed-link (params  info-was-evaled)

This is not acceptable. Taking care about evaluating INFO should be done
in a single place instead of adding checks across the babel code. If we
go the proposed way, I expect a number of bugs appearing when somebody
forgets to change the eval check in some place.

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

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

[Tom Gillespie]

Confirming fixed. Thanks!

PS A new issue arises however caused by
487f39efa68fa2d857f8d446d1c4b3a3b3e3f482,
which is that it is now confusing  to get the {{{results(=value=)}}}
macro without verbatim which is what :results drawer meant in
that context. I expect that change will break things for a number
of people beyond myself. A bit of reading the code revealed that
setting :wrap t makes it possible to get {{{results(value)}}} again,
but line 2647 [1] seems to indicate that drawer is an expected
and valid value for inline :results.


1.
   ((or (member "drawer" result-params)
;; Stay backward compatible with <7.9.2
(member "wrap" result-params))
(goto-char beg) (when (org-at-table-p) (org-cycle))
(funcall wrap ":results:" ":end:" 'no-escape nil
 "{{{results(" ")}}}"))

Re: org-ql and inherited tags (?)

[Ihor Radchenko]

Christian Barthel  writes:

> i am using Emacs 29 and org-ql (20230525.1548).
>
> ...
> ;; 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---

This message has nothing to do with Org mode itself. Looks like
something in org-ql.

I recommend reporting to org-ql repo.

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

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

[Ihor Radchenko]

Rodrigo Morales  writes:

> 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.

Thanks for reporting!
It was a bug in parser cache code.
Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=27a41d418

> With regards to experiment 2, we know that passing either ="FOO\n"= or
> ="FOO" "\n"= insert the same content, so I'm wondering how come
> passing different parameters to =insert= which result in the same
> outcome can affect the behavior of =org-get-outline-path=.

The difference is that "FOO\n" is processed a single buffer
modification (insert a string), while "FOO" "\n" triggers two
modifications (insert string, insert another string). The latter case
was not processed properly, missing that "\n" created a new heading:
1. Insert "FOO" ->
FOO** 1-2
2. Insert "\n"  ->
FOO
** 1-2

-- 
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

[Ihor Radchenko]

Juan Manuel Macías  writes:

> 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.

+1

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

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

[Ihor Radchenko]

Tom Gillespie  writes:

>> org-element-at-point is not supposed to return objects. So, there is no
>> problem here.
>
> Right. My original issue description is wrong for this part. It seems that
> org-babel-get-src-block-info returns nil when immediately before the start
> of the ala |src_ in #+caption: but will return non-nil in other contexts. In
> the #+caption: it will only work if the cursor is past the s ala s|rc_. Or
> if in non evil mode when the cursor is on the s in src_.

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=54c09c84e
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9fd547dd3

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