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

[gerard . vermeulen]

On 17.08.2023 14:10, Ihor Radchenko wrote:

gerard.vermeu...@posteo.net writes:

Your patches allow anyone to change 
org-babel-python--def-format-value.

For instance, I want to use black to "pretty-print" certain tree-like
structures


May you simply add an extra code to transform output as needed?


Yes, it is a way to switch between Jack's first and second set of 
patches if
one would like.  Or to add code to transform other Python data 
structures.

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

[Juan Manuel Macías]

Ihor Radchenko writes:

> Thanks!
>
>> * (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
>
> Please use double space between sentences and start sentences with
> capital letter.
>
>> +- =: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).
>
> s/`verse'/=verse=/
>   
> And you need to update `test-ox-latex/verse' test - it is currently failing.

Sorry for the typos... Here goes the corrected patch again, with the
updated test.

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com
>From bd956aa947e080ef10aa851f339414dc1cda1baf 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.

* testing/lisp/test-ox-latex.el (test-ox-latex/verse): Updated.
---
 doc/org-manual.org| 18 ++
 lisp/ox-latex.el  | 36 ++-
 testing/lisp/test-ox-latex.el |  8 
 3 files changed, 45 insertions(+), 17 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index e59efc417..ce0521dee 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 

Re: [BUG] org-element-cache Org parser error [9.7 (9.7-??-d6f3aed @ /home/guillaume.muller/.emacs.d/.local/straight/build-28.1/org/)]

[Ihor Radchenko]

Guillaume MULLER  writes:

> When I start DoomEmacs, I get this message:
>
> ---
> Warning (org-element-cache): org-element--cache: Org parser error in 
> packages.el::4667. Resetting.
>   The error was: (error "rx ‘**’ range error")
>   Backtrace:
> nil
>   Please report this to Org mode mailing list (M-x org-submit-bug-report). 
> Disable showing Disable logging
> Warning (org-element-cache): org-element--cache: Org parser error in 
> packages.el::4667. Resetting.

Something is calling Org mode function inside package.el file, which is
not an Org mode file.

You can try to toggle-debug-on-error to reveal the culprit.

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

[BUG] org-element-cache Org parser error [9.7 (9.7-??-d6f3aed @ /home/guillaume.muller/.emacs.d/.local/straight/build-28.1/org/)]

[Guillaume MULLER]

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.


When I start DoomEmacs, I get this message:

---
Warning (org-element-cache): org-element--cache: Org parser error in 
packages.el::4667. Resetting.
 The error was: (error "rx ‘**’ range error")
 Backtrace:
nil
 Please report this to Org mode mailing list (M-x org-submit-bug-report). 
Disable showing Disable logging
Warning (org-element-cache): org-element--cache: Org parser error in 
packages.el::4667. Resetting.
---


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

current state:
==
(setq
 org-link-elisp-confirm-function nil
 org-directory "~/.doom.d/org/"
 org-cite-insert-processor 'citar
 org-after-refile-insert-hook '(save-buffer)
 org-indirect-buffer-display 'current-window
 org-roam-db-gc-threshold 2305843009213693951
 org-bibtex-headline-format-function #[257 "\300%1\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-roam-mode-hook '(turn-on-visual-line-mode)
 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-init-roam-h)
 org-startup-folded nil
 org-babel-after-execute-hook '(+org-redisplay-inline-images-in-babel-result-h)
 org-link-abbrev-alist '(("doomdir" . "/home/guillaume.muller/.doom.d/%s")
 ("emacsdir" . "/home/guillaume.muller/.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-roam-node-display-template #("${doom-hierarchy:*} ${doom-type:12} 
${doom-tags:42}" 20 35 (face font-lock-keyword-face) 36 51 (face org-tag))
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-format-latex-options '(:foreground default :background default :scale 1.5 
:html-foreground "Black"
:html-background "Transparent" :html-scale 1.0 
:matchers
("begin" 

Re: [BUG] ob-sqlite: can not override header argument

[Ihor Radchenko]

Max Nikulin  writes:

> It seems there is no way to override for a specific code block header 
> arguments specified for the whole file through #+property:
>
> #+property: header-args:sqlite :header
> #+begin_src elisp :results none
>(require 'ob-sqlite)
> #+end_src
>
> I have tried "nil", etc. for ":header", but column names are always 
> added to results.

Yes, it is not.
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-sqlite.html

header
if present, turn on headers in the output format. 

Mere presence of this header argument triggers inclusion. Nothing is
said about overriding it.

I think that we may allow :header/:echo/:bail/... no to disable the cmd
switches. Patches welcome!

> Bonus: it seems condition for :csv is inverted, so -csv is always added. 
> I have not managed to override comma using :separator since -csv is 
> added later.

The source says

  ;; for easy table parsing, default header type should be -csv
  (cons "csv" (if (or (member :csv others) (member :column others)
  (member :line others) (member :list others)
  (member :html others) separator)
  ""
"-csv"))

So, it is at least intentional.
Note that (member :csv others) yielding "" is also intentional because
it is already added by that time in %others.

It is also documented to be the default:

csv
the default SQLite output format for Babel SQLite source code blocks.

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

[POLL] Should org-copy/cut/paste-special handle inlinetasks specially? (was: BUG: org-cut-special on inlinetask kill until point-max)

[Ihor Radchenko]

Michael Dauer  writes:

> I understand your view. From the user perspective inline task are still
> more a specialization of a task, which is a specialisation of a heading.
>
> Here is my implementation of how I see it that it should behave:
> (defun pm-cut-special ()
>   "Like org-cut-special but also works on inlinetask."
>   (interactive)
>   (if (not (eq 'inlinetask (save-excursion (org-back-to-heading t)
> (org-element-type (org-element-context)
>   (funcall-interactively 'org-cut-special)
> (org-inlinetask-goto-beginning)
> (let ((begin (point)))
>   (org-inlinetask-goto-end)
>   (kill-region begin (point))
>   (message "Cut: Inline Task"

I looked into this further, and I can see that in the earlier versions
of Org org-cut-special on inlinetask killed that inlinetask, not the
containing subtree:

* Heading
Text
** Inlinetask
** END
More text
* Another heading

C-c C-x C-w

* Heading
Text

More text
* Another heading

It was by accident, AFAIU. Also, when point was at END, it was buggy
(only removed "END" line).

So, technically, the current behaviour cutting the actual subtree (not
inlinetask) can be considered a feature regression (if we call the
previously existing bug a "feature").

I think that it would be slightly better to keep special behaviour for
inlinetasks. But other opinions would be appreciated.

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

Re: org-assert-version considered harmful

[Ihor Radchenko]

Max Nikulin  writes:

> On 16/08/2023 18:08, Ihor Radchenko wrote:
>> 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)
>
> Are you going to update patch version of particular library on each 
> change of macro definitions?

At least, each time we release a new non-bugfix Org version.
Maybe also each time we make breaking change in a macro. But that
should not normally happen on bugfix, only when we merge main into
bugfix. So, just during major/minor releases should be good enough.

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

Re: org-assert-version considered harmful

[Max Nikulin]

On 16/08/2023 18:08, Ihor Radchenko wrote:

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)


Are you going to update patch version of particular library on each 
change of macro definitions?

Re: [BUG][SECURITY] ob-sqlite header args allows execution of arbitrary shell commands

[Max Nikulin]

On 13/08/2023 14:52, Ihor Radchenko wrote:

What do you think about creating a new API to built shell commands and
then using it across all the babel backends?


I support the idea in general, but not its particular implementation as 
`org-make-shell-command' in your patch.


It does not address the issue I raised.

#+begin_src sqlite :db '(literal "/tmp/ob.sqlite$(date 
>/tmp/ob-sqlite-vuln.log)")

  select 1
#+end_src

still executes a shell command without user prompt. Moreover for 
org-babel such value does not look like as something that may be 
evaluated, it is just a list. So the proposed syntax is more explicit 
(and I like it), but it does not prevent unsolicited execution of shell 
command.


I would consider some way to specify whether COMMAND should be quoted as 
well. Path to an executable may contain a space or other special 
character at least for some shells. On the other hand it is more usual 
case to specify some arguments to the command.


I am unsure if a note should be added to the `org-fill-template' 
docstring that the function should not be used for building shell commands.

Re: [BUG][SECURITY] ob-sqlite header args allows execution of arbitrary shell commands

[Max Nikulin]

On 13/08/2023 14:52, Ihor Radchenko wrote:

+ (when separator (format "-separator %s" separator))


It should be escaped as a whole. It seems sqlite3 command line arguments 
parser does not support -separator=| variant, so two words should be 
quoted separately. Try :separator |


sqlite3: Error: unknown option: -separator |
Use -help for a list of options.
[ Babel evaluation exited with code 1 ]

[BUG] ob-sqlite: can not override header argument

[Max Nikulin]

It seems there is no way to override for a specific code block header 
arguments specified for the whole file through #+property:


#+property: header-args:sqlite :header
#+begin_src elisp :results none
  (require 'ob-sqlite)
#+end_src

I have tried "nil", etc. for ":header", but column names are always 
added to results.


#+begin_src sqlite :results verbatim :header no
select 1 as "one", 2 as "two"
#+end_src

#+RESULTS:
: one,two
: 1,2

Bonus: it seems condition for :csv is inverted, so -csv is always added. 
I have not managed to override comma using :separator since -csv is 
added later.


I am just testing a patch for ob-sqlite, I am not a real user of it.

Re: [MAINTENANCE] Org orphanage?

[Corwin Brust]

Hi all; I added worg co-curator krupalinbox to CC.

On Thu, Aug 17, 2023 at 8:41 AM Jonas Bernoulli  wrote:
>
> Ihor Radchenko  writes:
>
> > I may miss more org-related repositories from emacsorphanage list.
>
[SNIP]
>
> >> IMO it would be a good idea if Bastien and/or Ihor joined the
> >> emacsorphanage and explicitly added themselves to these packages as
> >> admins.
[SNIP]
>
> When that is not the case, then it is preferable to move a package to
> the orphanage, at least initially, and give the volunteer access there.
> That way we maintain some control; IMO we have an obligation to do that.
> We already had to make use of that control and revoke access a few times.
>

I would be happy to help with administration here.   I have a GitHub
account, as well as commit on bastian's sr.ht.

In fact, I wonder if worg curators should have some general
responsibilities to help with the orphanage.

Speaking for myself, I can help:
- send the various "let me know" emails discussed in this thread
- suggest packages that need love to (prospective) volunteers
- review the bonafides (experience/involvement and, via Eli/SM,
assignment status ) for prospective adopting maintainers
- assign permissions
- move repos
- apply well tested patches to orphaned packages

Of course, I understand and won't be offended should be more comfort
all around if Bastian and Igor take care of some or all of this
personally.

Irrespective of whether worg curators should help with this (or some
other vols, or just the org maintainers, or...), I think it would make
sense to document these "responsibilities" (and the detail of the
plans made in this thread, in general), along with the whos and hows.

Re: [MAINTENANCE] Org orphanage?

[Jonas Bernoulli]

Ihor Radchenko  writes:

> What about https://github.com/flexibeast/org-vcard and
> https://github.com/nikclayton/ob-sql-mode ?

Are you saying these packages are unmaintained and asking whether they
should be moved to the orphanage?

When I feel like that about a package, I usually open an issue on the
stale upstream repository and/or send the author an email, introducing
them to the orphanage, and offering them to do some light maintenance
there.

I try to avoid implying that this is the only or best option, pointing
out that it might make more sense to give commit access to people who
have made valuable contributions in the past.  That can go along with
creating a new "organization" for that repository, to make it more
visible, that this is now a team effort, but keeping the repository
under the user account of the original author is also an option.

Only when there are no volunteers do I actually prefer moving to the
repository to the orphanage.  The name of this organization is quite
apt: if there are packages in need, we offer to help out, but it is
of course always better if they find a new permanent home.

> Also, we might want to add org-json and org-redmine to
> https://orgmode.org/worg/org-orphanage.html

Yes.

> I may miss more org-related repositories from emacsorphanage list.

As you probably have, I entered "org" and similar terms into the search
field at https://github.com/orgs/emacsorphanage/repositories and the
packages you just mentioned and the once that are already listed at
worg, is all I got.  But it is of course possible (though probably not
all that likely) that there are a few others in the orphanage that are
hiding better.

>> 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?
>
> That would make sense, yes.

Done (as you know, just a note to others who only read here).


As a side-note, the reason I don't want to delete repositories without
careful consideration, is that I want to preserve the existing issues
and pull-requests.  When a package finds a new home outside of github,
then we cannot migrate the existing issues there but they are still of
value, not least because they are mentioned in commit messages.  In the
future we might be able to migrate issues and such to other forges;
would be a shame if the data were lost by then.

(In a sense my Forge package can already be used for this.  It stores
this data in a local sqlite database, but that is intended for use by a
single, local, user.  It could be used for disaster recovery, but if the
plan is to publish the data, then it isn't the appropriate tool.)


Unmaintained packages frequently come up on Melpa, so we have documented
how we try to handle that.  A lot of what is being said there, also
applies when packages in need are brought up elsewhere.

https://github.com/melpa/melpa/wiki/Unmaintained-Packages-and-Forks.

Note in particular (picking up on a topic mentioned above):

> The new maintainer must have experience. E.g. maintains/contributes to
> an existing elisp package, has other visible community contributions,
> or can be vouched for by such a person.

When that is not the case, then it is preferable to move a package to
the orphanage, at least initially, and give the volunteer access there.
That way we maintain some control; IMO we have an obligation to do that.
We already had to make use of that control and revoke access a few times.

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

[Michael Dauer]

I understand your view. From the user perspective inline task are still
more a specialization of a task, which is a specialisation of a heading.

Here is my implementation of how I see it that it should behave:
(defun pm-cut-special ()
  "Like org-cut-special but also works on inlinetask."
  (interactive)
  (if (not (eq 'inlinetask (save-excursion (org-back-to-heading t)
(org-element-type (org-element-context)
  (funcall-interactively 'org-cut-special)
(org-inlinetask-goto-beginning)
(let ((begin (point)))
  (org-inlinetask-goto-end)
  (kill-region begin (point))
  (message "Cut: Inline Task"

(defun pm-copy-special ()
  "Like org-copy-special but also works on inlinetask."
  (interactive)
  (if (not (eq 'inlinetask (save-excursion (org-back-to-heading t)
(org-element-type (org-element-context)
  (funcall-interactively 'org-cut-special)
(org-inlinetask-goto-beginning)
(let ((begin (point)))
  (org-inlinetask-goto-end)
  (copy-region-as-kill begin (point))
  (message "Copied: Inline Task"

(defun pm-paste-special (arg)
  "Like org-paste-special but also works on inlinetask."
  (interactive "P")
  (if (not (eq 'inlinetask
   (with-temp-buffer
 (org-mode)
 (insert (current-kill 0 t))
 (goto-char (point-min))
 (org-element-type (org-element-context)
  (funcall-interactively 'org-paste-special arg)
(unless (eq (point) (pos-bol))
  (forward-line))
(yank)))

There is a fine-tuning outstanding: The criteria whether to paste before or
after the current line should not be the point on the begin-of-line but the
beginning of the actual heading (after the asterisks).



Am Do., 17. Aug. 2023 um 13:30 Uhr schrieb Ihor Radchenko <
yanta...@posteo.net>:

> Michael Dauer  writes:
>
> > I probably mis-interpreted the code. Because then I would also fail for
> > normal headings. Just thinking about the symptoms I think the issue Is
> that
> > (org-end-of-subtree) works with type 'headline. And inlinetask is a
> > different type, right?
>
> Yes. Inlinetask is not considered a subtree of its own.
> Just like other foldable elements (lists/drawers/blocks) are not
> considered subtrees.
>
> > IMO org-mode should consistently treat inlinetasks including the END line
> > as a branch. Then org-cut-special would do something useful on them, i.e.
> > cutting the inlinetask includinging its contents and the END line.
>
> It would not be consistent. We already do not treat, for example, lists
> special in `org-cut-special'.
>
> --
> 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?

[Ihor Radchenko]

Jonas Bernoulli  writes:

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

+1

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

[Ihor Radchenko]

Jonas Bernoulli  writes:

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

Thanks!

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

Fixed.
https://git.sr.ht/~bzg/worg/commit/667e1142

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

What about https://github.com/flexibeast/org-vcard and
https://github.com/nikclayton/ob-sql-mode ?

Also, we might want to add org-json and org-redmine to
https://orgmode.org/worg/org-orphanage.html I may miss more org-related
repositories from emacsorphanage list.

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

That would make sense, yes.

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

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

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

> Your patches allow anyone to change org-babel-python--def-format-value.
> For instance, I want to use black to "pretty-print" certain tree-like 
> structures

May you simply add an extra code to transform output as needed?

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

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

[Ihor Radchenko]

Jack Kamm  writes:

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

Thanks!

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

Actually, (org-list-to-org '(unordered ("a :: b") ("c :: d")))
will just work.

We do not support nested lists when transforming output anyway. So,
unordered/descriptive does not matter in practice.

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

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

[Ihor Radchenko]

Jack Kamm  writes:

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

Some comments on the patch itself.

> @@ -2041,8 +2056,8 @@ to switch to the new signature.
>  *** Python session return values must be top-level expression statements
>  
>  Python blocks with ~:session :results value~ header arguments now only
> -return a value if the last line is a top-level expression statement.
> -Also, when a None value is returned, "None" will be printed under
> +return a value if the last line is a top-level expression statement,
> +otherwise the result is None. Also, None will now show up under
>  "#+RESULTS:", as it already did with ~:results value~ for non-session
>  blocks.

This is an ORG-NEWS entry for Version 9.4. Is it an intentional change?
  
> @@ -142,7 +144,9 @@ (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 (org-babel-script-escape results)))
> +  (let ((res (if (string-equal "{" (substring results 0 1))
> + results ;don't covert dicts to elisp
> +   (org-babel-script-escape results

You may also need to update the docstring for
`org-babel-python-table-or-string' after this change.

> - body)))
> -   (`value (let ((tmp-file (org-babel-temp-file "python-")))
> +(if graphics-file
> +(format 
> org-babel-python--output-graphics-wrapper
> +body graphics-file)
> +  body
> +   (`value (let ((results-file (or graphics-file
> +(org-babel-temp-file "python-"

What about :results graphics file ?

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

> I probably mis-interpreted the code. Because then I would also fail for
> normal headings. Just thinking about the symptoms I think the issue Is that
> (org-end-of-subtree) works with type 'headline. And inlinetask is a
> different type, right?

Yes. Inlinetask is not considered a subtree of its own.
Just like other foldable elements (lists/drawers/blocks) are not considered 
subtrees.

> IMO org-mode should consistently treat inlinetasks including the END line
> as a branch. Then org-cut-special would do something useful on them, i.e.
> cutting the inlinetask includinging its contents and the END line.

It would not be consistent. We already do not treat, for example, lists
special in `org-cut-special'.

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

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

[Ihor Radchenko]

 writes:

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

Thanks for reporting!

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

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

> Here is the modified patch.

Thanks!

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

Please use double space between sentences and start sentences with
capital letter.

> +- =: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).

s/`verse'/=verse=/
  
And you need to update `test-ox-latex/verse' test - it is currently failing.

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

Jonathan Gregory  writes:

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

Thanks!
Applied, onto main.
Fixed.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f78a3c2bd

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

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

What I see when tangling a file with the above code block is

Debugger entered--returning value: ("emacs-lisp" "2" ((:colname-names)
 (:rowname-names) (:result-params "replace")
 (:result-type . value) (:results . "replace")
 (:exports . "code")
 (:tangle . "yes") <-- evaluated
 (:lexical . "no")
 (:eval . "never-export") (:comments . "link")
 (:hlines . "no") (:noweb . "yes") (:cache . "no")
 (:session . "none")) "" nil 2 "(ref:%s)")
  (org-babel-get-src-block-info)
* (# 1)
* (apply # 1)
* (org-babel-tangle-single-block 1)
  (org-babel-tangle-collect-blocks nil nil)
  (org-babel-tangle nil)
  (funcall-interactively org-babel-tangle nil)

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

Do you mean something like

#+PROPERTY: headline-args :var x=1

#+begin_src elisp :tangle (if (= x 1) "yes" "no")
...
#+end_src
?

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

Let me know if you need any help.

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

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

[gerard . vermeulen]

On 17.08.2023 06:04, Jack Kamm wrote:


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


Happy to see that ob-python gets so much love!

Your patches allow anyone to change org-babel-python--def-format-value.
For instance, I want to use black to "pretty-print" certain tree-like 
structures

and I have now in my init.el:

(with-eval-after-load 'ob-python
  (setq org-babel-python--def-format-value "\
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 black
f.write(black.format_str(repr(result), mode=black.Mode()))
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] + \
[[i] + list(row) for i, row in result.iterrows()]
elif isinstance(result, pandas.Series):
result = list(result.items())
try:
import numpy
except ImportError:
pass
else:
if isinstance(result, numpy.ndarray):
result = result.tolist()
f.write(str(result))"))

Without your patches I use advice to override
org-babel-python-format-session-value, which is worse IMO.

This also allows anyone to format for instance AstroPy tables
(https://docs.astropy.org/en/stable/table/).

I do not know how much this "abuse" of defconst is frowned
upon (elisp manual says defconst is advisory), but maybe it
can be advertised as a feature.

Best regards -- Gerard

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

[Michael Dauer]

I probably mis-interpreted the code. Because then I would also fail for
normal headings. Just thinking about the symptoms I think the issue Is that
(org-end-of-subtree) works with type 'headline. And inlinetask is a
different type, right?

IMO org-mode should consistently treat inlinetasks including the END line
as a branch. Then org-cut-special would do something useful on them, i.e.
cutting the inlinetask includinging its contents and the END line.

Am Do., 17. Aug. 2023 um 10:42 Uhr schrieb Michael Dauer <
mick.da...@gmail.com>:

> I looked directly into the code and I think I found the issue:
> (org-copy-subtree) calls (org-end-of-subtree) without providing an
> element. But without an element this function just jumps to (point-max).
> I would expect a different behavior or (org-end-of-subtree). Since element
> is optional it should take the element at point.
>
>
> Am Mi., 16. Aug. 2023 um 18:02 Uhr schrieb Ihor Radchenko <
> yanta...@posteo.net>:
>
>> 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

[Ihor Radchenko]

Michael Dauer  writes:

> I looked directly into the code and I think I found the issue:
> (org-copy-subtree) calls (org-end-of-subtree) without providing an element.
> But without an element this function just jumps to (point-max).

This is not true. Please make sure that you are using the latest Org.

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

I looked directly into the code and I think I found the issue:
(org-copy-subtree) calls (org-end-of-subtree) without providing an element.
But without an element this function just jumps to (point-max).
I would expect a different behavior or (org-end-of-subtree). Since element
is optional it should take the element at point.


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

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