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

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

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

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

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

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

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

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

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

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

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

[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

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.

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

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

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

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.

Re: [MAINTENANCE] Org orphanage?

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

Re: [MAINTENANCE] Org orphanage?

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

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

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

Re: org-assert-version considered harmful

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

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

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

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

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

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

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

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

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

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

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

Re: org-assert-version considered harmful

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

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

* 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

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

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

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

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

Re: [MAINTENANCE] Org orphanage?

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

Re: [MAINTENANCE] Org orphanage?

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

[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/)]

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

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

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

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

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

Re: org-assert-version considered harmful

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

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

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.

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

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.

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

Re: org-ql and inherited tags (?)

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

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

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.

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

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

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

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