Jack Kamm writes:
> IMO it should be possible for ox-icalendar to export events without
> DTEND since the iCalendar spec explicitly allows this. However it will
> take me some time to look into it.
Reviewing RFC 5545 again, it says:
> For cases where a "VEVENT" calendar
other duration besides 2 hours.
>From d9596bff6f85162362e3a836e7bc631fc9f8361e Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sun, 18 May 2025 19:47:34 -0700
Subject: [PATCH] Document ox-icalendar use of
org-agenda-default-appointment-duration
---
doc/org-manual.org | 6 ++
1 file changed, 6 insertions(+)
Ihor Radchenko writes:
> Thanks! The logic is not ideal, but babel is not ideal in general, so
> let's not worry too much about various edge cases. The patch is an
> improvement over the existing state of affairs anyway.
>
> Feel free to push.
Thanks, I've pushed to main now. Agree it's not idea
a check that the block's result contains the hash
(`uuid-or-tmpfile') that the async result replaces.
I also created a constant for the regexp in org-element.el, and added
unit tests in test-ob-python.el for inline and async inline session
blocks.
>From 29fc7ae73b2d9968a39b36eae787d03ff
Ihor Radchenko writes:
> Jack Kamm writes:
>
>> The following patch seems to fix the issue -- does something like this
>> seem reasonable?
>>
>> ...
>> +(defun org-babel-previous-src-block-or-inline ()
>> + "Jump to previous source block or i
he following patch seems to fix the issue -- does something like this
seem reasonable?
>From 9a639013cf1a469f41b210c3b2167746f77f58b0 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sun, 16 Mar 2025 21:12:34 -0700
Subject: [PATCH] Fix async inline babel blocks
---
lisp/ob-comint.el | 4 ++--
Ihor Radchenko writes:
>> +To export active timestamps only without diary timestamps, users can
>> +set ~org-export-with-timestamps~ and ~org-icalendar-with-timestamps~
>> +to ~active-exclude-diary~.
>
> Maybe you can emphasize more that "without diary timestamp" is the old
> behavior. We often u
Ihor Radchenko writes:
> Jack Kamm writes:
>
>> Ihor Radchenko writes:
>>
>>> I agree that it makes sense.
>>> However, it is technically a breaking change.
>>> May you please add a news entry as well?
>>
>> Thanks, I've updated the
Panayotis Manganaris writes:
> Thanks for the sanity check, Ihor. I must have had some piece of
> configuration that enabled this for me -- Super useful, I'll share it if
> I find it.
Perhaps you were using emacs-jupyter [1]? They use drawers to capture
multiple results from source blocks.
[1]
Ihor Radchenko writes:
> I have no further comments.
> Feel free to push.
Pushed now. Thank you and happy new year!
om `org-datetree-find-create-hierarchy' with org-capture.
Relatedly, I made `org-datetree-comparefun-from-regex' public to help
with building new types of datetrees.
>From b8447f23c5618239bb3926a59d111fd21d985afe Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sun, 29 Dec 2024 00:52:59 -0800
Subje
Ihor Radchenko writes:
>> +;; Support the old way of tree placement, using a property
>> +(let ((prop (and legacy-prop (org-find-property legacy-prop
>> + (if prop
>> + (progn
>> +(goto-char prop)
>> +(org-narrow-to-subtree)
>>
Ihor Radchenko writes:
> Jack Kamm writes:
>
>>> The API of `org-datetree--find-create' is generally very limiting.
>>> It would be nice to come up with something less limiting.
>>
>> Thanks for the feedback -- I'll start working on something alon
Ihor Radchenko writes:
> Jack Kamm writes:
>
>>> The API of `org-datetree--find-create' is generally very limiting.
>>> It would be nice to come up with something less limiting.
>>
>> Thanks for the feedback -- I'll start working on something alon
Ihor Radchenko writes:
> I have no further comments.
> Feel free to push.
Applied. Thanks for your help and review!
lean it (e.g. with `butlast').
Since it can be confusing to have 2 different behaviors, I've updated
the `disable-prompt-filtering' case to be more consistent, and leave the
cleaning of the eoe-indicator to the language-specific implementations
in ob-python and ob-R.
>From b96c5b9db5696
Ihor Radchenko writes:
> Jack Kamm writes:
>
>> Thanks for the suggestions, all of which I agree with. I've updated the
>> patches accordingly, and also rebased them to most recent versions of
>> bugfix/main.
>
> Thanks!
> I have no more comments. LGTM
ething?)
Thanks for the suggestions, all of which I agree with. I've updated the
patches accordingly, and also rebased them to most recent versions of
bugfix/main.
>From 16dfc0d4500ab941333a9e705b2ddac85c30efdc Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sun, 22 Sep 2024 13:48:45 -070
and rebased onto latest bugfix. I also attach a second
patch with the NEWS entry on main.
>From 000b7ea1025a7f076c0af0b69d6a2a653c415b40 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sun, 22 Sep 2024 13:48:45 -0700
Subject: [PATCH] Disable async prompt removal in ob-R,python
* lisp/ob-comint.
Ihor Radchenko writes:
>> I think it would be feasible to switch non-session blocks to use this
>> parser, which IMO is nicer behavior -- the "return" statements always
>> felt weird to me.
>>
>> But a major reason not to do it is to avoid breaking compatibility. Lots
>> of old ob-python nonsessi
Ihor Radchenko writes:
> I'm afraid that trying to replicate Python REPL behavior for
> non-interactive src blocks will be beyond what we can reasonably do in
> Org: we would somehow need to detect the last statement in the src
> blocks, which may or may not span a single line; and multiline stat
VE-DANGLING option. If we find we need this option later for some
reason, we can figure out the details about point/process-mark then.
I've reattached the patch with this option removed, and also rebased
onto latest main.
>From 629788caa86773199fc06af1797cf8fd67a7884a Mon Sep 17 00:00:00 200
Ihor Radchenko writes:
>> In the org-mode documentation I read:
>>
>> For languages like Python, an explicit return statement is mandatory
>> when using ‘:results value’.
>> https://orgmode.org/manual/Results-of-Evaluation.html
>>
>> So I think WORG needs to be fixed.
>>
>> Can you send
o skip
the prompt filtering if the major-mode is R or Python; then on main,
revert the hard-coded check, and update the signature of
`org-babel-comint-async-register' to set it properly with a
variable. But not sure it's worth the hassle -- I might just switch to
using main branch on my w
demonstrate
the improved robustness of this approach: previously, this test would
fail due to a false positive prompt, but it passes with the new
implementation.
>From 232f4c60323b13e3d46cb377095a8b2751f7ed74 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Thu, 17 Oct 2024 17:33:47 -0700
Su
538
[2]
https://github.com/emacs-ess/ESS/blob/d60c13a6a347ea7a91ea3408bb464cff0ab4fef6/lisp/ess-custom.el#L1829
>From 5c9d6f28f14c51fc542c997ed6aa6792e59857c6 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sun, 22 Sep 2024 13:48:45 -0700
Subject: [PATCH] Disable async prompt removal in ob-R,python
* lisp/ob-comint.
ch is the best solution. But whatever solution
we arrive at, I would like to request that it be applied to bugfix
branch.
>From 11177e57f8a0c77b6c6541b852c5d105d70afec0 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sun, 22 Sep 2024 13:48:45 -0700
Subject: [PATCH] ob-R: Fix over-aggressive asy
Ihor Radchenko writes:
> I agree that it makes sense.
> However, it is technically a breaking change.
> May you please add a news entry as well?
Thanks, I've updated the patch with a news entry now.
>From 5c40741664402a5984803dc3de452ea949885887 Mon Sep 17 00:00:00 2001
From
d in the agenda, and have angle
brackets.
[1]
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ox-icalendar.el?id=07dd3bcae6b7b5e0692fc40dd307a7e841179b52#n826
>From 32a5afd2803aa54e1e21b11d9d1e832e99538e9b Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sat, 14 Sep 2024 22:48:44 -
Ihor Radchenko writes:
> CCing the maintainer.
Thanks Ihor. This issue dovetails nicely with the other recent iCalendar
issue [1] that I am still looking into (sorry for the tardiness)
> In theory, you should be able to do something like
>
> #+ICALENDAR_VCALENDAR: X-MICROSOFT-CDO-INTENDEDSTATUS
Ihor Radchenko writes:
> Another concern is that we already have `org-export-with-tasks' where
> you can specify which todo keywords should be exported and which
> headings should be exported, according to their todo keyword. So,
> "no-export" appears to unnecessary.
That's a good point. Michael
Michaël Cadilhac writes:
> I have a task that was recurring, which I KILLED a few weeks ago. It
> now looks like:
>
> ** KILLED Do the right thing
>SCHEDULED: <2023-07-14 Fri +1w>
>
> ox-icalendar still exports it every week, because I have
> 'event-if-not-todo in org-icalendar-use-scheduled
Matt writes:
> AFAIK, aside from appending "&", =make-process= is the only way. It would
> probably make sense to continue using =shell= though. If I understand
> correctly, you (and others) jump between the Org buffer block and the comint
> buffer?
Yes, I typically use ob-R and ob-python i
Matt writes:
> The challenge I've found with Babel is figuring out how to make the changes.
> My current approach is to address bugs and to make changes that move us
> toward something like the ob-blub implementation. I wonder if it might help
> to discuss the core ideas and use a minimal re
Bruno Barbier writes:
> I'm not using it with official org backends (yet). I'm using it with
> several custom backends that I'm working on. One of the backend
> delegate the block executions to emacs subprocesses: so I have a kind of
> asynchronous executions for free for any language, includin
Ihor Radchenko writes:
>> Compiling
>> /home/jack/src/org-mode/2024-01-async-file-results-dir/lisp/ob-core.el...
>>
>> In org-babel-session-buffer:
>> ob-core.el:785:15: Warning: reference to free variable ‘buffer-name’
>
> But this is a real problem.
> See the attached updated version
Ihor Radchenko writes:
>> I agree that it would be good to redesign it, but am not sure where to
>> start.
>
> For example,
>
> 1. Change `org-babel-comint-async-register' to return UUID and to store
>PARAMS as passed by the backend (current approach with PARAMS being
>derived from src bl
Bruno Barbier writes:
> FWIW, I've been trying to use asynchronous blocks for everything, not
> only the source blocks that are based on the comint mode. I think it
> would be good if ob-core itself could provide an asynchronous API. I've
> modified my Org so that it does have such an API. Thi
Ihor Radchenko writes:
> +(defun org-babel-session-buffer (&optional info)
> + "Return buffer name for session associated with current code block.
> +Return nil when no such live buffer with process exists.
> +When INFO is non-nil, it should be a list returned by
> +`org-babel-get-src-block-info
Ihor Radchenko writes:
> What we can do is to introduce a new backend template function
> org-babel-session-buffer: that will be passed a session name and
> src block params and return the session buffer name.
>
> If such function is not defined, we fall back to assumption that session
> buffer i
Ihor Radchenko writes:
> Jack Kamm writes:
>
>> I think the correct solution would be for `org-babel-insert-result' to
>> not insert file results (or any other special results) for async session
>> blocks. Perhaps in this case, `org-babel-insert-result' could
Ihor Radchenko writes:
> Thanks!
> Attaching the two patches combined with some fixed to my patch.
>
> Please check if these two patches solve the discussed bug.
The original bug for async sessions looks fixed. But I encountered a
complication regarding the non-async bug of changing :dir. In par
ed on the session buffer's
value rather than the :dir header arg.
>From 1a1a22e4f4a12ebe83c3fef26fe727066fb14476 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Wed, 31 Jan 2024 20:06:00 -0800
Subject: [PATCH] ob-comint: Make file results from async sessions respect :dir
header
* lisp/ob
Ypo writes:
> I can't share my private org files. And I find myself unable to isolate
> the causes of the possible errors.
One strategy that might help is to "bisect" the Org file by repeatedly
splitting it into 2 files, and exporting each, to find where the
problematic entries are. By splittin
Bruno Barbier writes:
> Hi Ihor,
>
> Ihor Radchenko writes:
>
>>
>> This is most likely something about my current system setup - I can
>> reproduce with other Org mode and Emacs versions. But I have no clue
>> what is the cause.
>
> I'm getting the same as you with your MWE.
>
> The tag, us
Ihor Radchenko writes:
> The patch generally looks reasonable, although I am slightly concerned
> about interaction between :dir and session we describe in the manual:
>
> When ‘dir’ is used with ‘session’, Org sets the starting directory
> for a new session. But Org does not alter the d
enerally (not just
ob-python), and happens because `org-babel-comint-async-filter' does not
set `default-directory' before calling `org-babel-insert-result', unlike
`org-babel-execute-src-block'.
>From 1430a27e4416d5e88094a64360015a6a2ae7315c Mon Sep 17 00:00:00 2001
From: Ja
ypuntot writes:
> Problem! Found 1 error
>
> Errors
> Lines not delimited by CRLF sequence near line # 1
> Reference: RFC 5545 3.1. Content Lines
Which version of Org are you using? (M-x org-version)
Org 9.7 (unreleased) contains some fixes for how ox-icalendar handles
newlines. If you are usin
Ihor Radchenko writes:
> CCing ox-icalendar maintainer.
>
> ypuntot writes:
>
>> I am trying to create an android calendar based on the agenda, and the first
>> problem I am finding it's that I can't import it into android (ICSx^5). I am
>> receiving these errors when trying to do it:
>>
>> Co
Ihor Radchenko writes:
> Applied, onto main, fixing the oversight in
> org-src-associate-babel-session (now, it does not require session
> running).
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=319563cef
>
> Since ESS already released a new version with my patch for ESS inclu
Ihor Radchenko writes:
> Liu Hui writes:
>
>> Yes, I have updated the text and you're welcome to improve it. Thanks!
>> From c503b2ed5116e2abae25459b09abc919074ac54a Mon Sep 17 00:00:00 2001
>> From: Liu Hui
>> Date: Tue, 5 Dec 2023 11:40:38 +0800
>> Subject: [PATCH] Set Python shell in Org edi
Ihor Radchenko writes:
> LGTM. Thanks!
Thanks, I've applied now:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=da2b61b09e1eff957e6b2560a2f9c8509de6beac
L to `org-icalendar--vcalendar'
Co-authored-by: Ihor Radchenko
Co-authored-by: Jack Kamm
---
doc/org-manual.org | 9 +
etc/ORG-NEWS | 17
lisp/ox-icalendar.el | 47 ++--
3 files changed, 67 insertions(+), 6 deletions(
Ihor Radchenko writes:
> Thanks!
> You can replace Maintainer: line in ox-icalendar.el with your name.
Done.
> Sure.
> I checked my records and found one outstanding issue related to
> ox-icalendar -
> https://list.orgmode.org/orgmode/20211230225919.1a660...@hsu-hh.de/
>
> The patch proposed by
Ihor Radchenko writes:
> Ihor Radchenko writes:
>
>>> I have noticed that properties that stretch over multiple lines using
>>> the :value+: syntax are ignored by org-element-property and therefore
>>> also by e.g. org-export-get-node-property when exporting to ics via
>>> ox-icalendar.el (se
Ihor Radchenko writes:
>> My concern is that advising `ess-request-a-process' would cause
>> maintenance burden on ob-R. It would require some knowledge about the
>> ESS internals to maintain properly.
>
> Not really. I only meant writing an advice iff our request is accepted
> by ESS devs. Then,
Ihor Radchenko writes:
>> It's annoying there's no way to tell ESS to start new session instead of
>> evaluating in existing one. Here are a few alternatives we could
>> consider to deal with this:
>>
>> 1. Change the worg/ORG-NEWS, to suggest users make sure the session
>> exists (either by eval
Ihor Radchenko writes:
> See the attached tentative patch.
Thanks!
> ---
> etc/ORG-NEWS | 11 +++
> lisp/ob-R.el | 20 ++--
> lisp/ob-julia.el | 16 +---
> 3 files changed, 26 insertions(+), 21 deletions(-)
Not sure if you are doing this in a separa
Jack Kamm writes:
> Also it seems unnecessary to call `ess-make-buffer-current', as it's
> already called by `ess-force-buffer-current' (which is called by
> `ess-eval-region'). Though it doesn't hurt to call it, either.
On reflection, maybe it's better t
Ihor Radchenko writes:
> Note that I proposed to remove auto-starting session completely, which
> is in odds to what you propose below.
Sure, I'm fine with that -- it seems like a reasonable change.
> IMHO, it might be enough to adjust org-babel-R-associate-session as the
> following
>
> (defun
Ihor Radchenko writes:
> So, a good option could be
> (1) removing (org-babel-comint-buffer-livep session) from
> `org-src-associate-babel-session'
> (2) Removing `org-babel-edit-prep:R'
>
> With the above, we can use `org-babel-python-associate-session'
Sounds good to me.
> I imagine that
Ihor Radchenko writes:
> Now, the question is what to do with the existing implementation of
> `org-src-associate-babel-session'. It only runs
> org-babel--associate-session when
>
> (and session (not (string= session "none"))
>(org-babel-comint-buffer-livep session)
>(let ((f (in
Ihor Radchenko writes:
>> I agree that `python-shell-buffer-name' should be set according to the
>> :session header, and that Liu's patch fixes a problem in ob-python.
>>
>> Is there any objection if I go ahead and apply it?
>
> Because I am still thinking about the idea with global customization
Ihor Radchenko writes:
>> https://gitlab.com/jackkamm/org-grouped-weektree
>>
>> I'd appreciate feedback on 2 points:
>>
>> 1. Are any of these datetree formats worth upstreaming into org-mode
>>proper?
>
> That would make sense.
>
>> 2. Can we add a public interface for `org-datetree--find-c
Ihor Radchenko writes:
> python.el is convenient as it allows setting the session buffer name in
> advance via buffer-local variable. Then, all the normal python-mode
> commands, including `run-python' or `python-shell-send-region' will work
> as expected. However, other babel backends like ob-R
ing called
> from `org-babel-execute:python' that let-binds
> `org-babel-python-nonsession'.
>
> Since `org-babel-python-evaluate-external-process' is a public function,
> it may also be called independently. And it will not obey
> `org-babel-python-command' then.
Tha
I have started a package that defines org-capture datetrees following
year-quarter-week and year-month-week formats:
https://gitlab.com/jackkamm/org-grouped-weektree
I'd appreciate feedback on 2 points:
1. Are any of these datetree formats worth upstreaming into org-mode
proper?
2. Can we
Liu Hui writes:
> But it is indeed possible that two sessions are inconsistent, if users
> intend to have different org-babel-python-command and
> python-shell-interpreter, which are used by
> `org-babel-python-initiate-session' and `run-python', respectively.
I have just proposed this patch, wh
#x27;. But I submit the
patch for review before applying it, because it involves changing the
default values of some custom variables.
>From a49ddcb6ef72cfefab400e36e6d4a19e869c47a1 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Fri, 29 Dec 2023 13:22:18 -0800
Subject: [PATCH] ob-python: Chan
Ihor Radchenko writes:
> As long as it remains undocumented, we can break this in future (maybe
> years from now, but still...).
Fair enough, I've had to fix this feature from time to time due to
breakage in the past.
I just pushed d0d838b02 which should hopefully prevent future breakage:
http
Ihor Radchenko writes:
> I think we have a misunderstanding here.
>
> Didn't we just discuss that C-c C-p in python is not equivalent to
> `org-babel-python-initiate-session'?
ob-python works fine with sessions started externally by `run-python'.
And I have preserved this functionality, as I enj
Liu Hui writes:
> I just want to set 'python-shell-buffer-name' in the edit buffer
> according to the :session header and don't need to start the session
> even if the session doesn't exist.
Sorry that I missed this thread.
I agree that `python-shell-buffer-name' should be set according to the
Ihor Radchenko writes:
>> 1. In addition to printing `org-babel-python-eoe-indicator' after
>>execution, we could also print out a "beginning of execution"
>>indicator before execution, and then capture the output between the
>>beginning and end indicators. This is how the async sessi
Ihor Radchenko writes:
> We have fairly regular CI test failures for one of the ob-python tests.
> The test does not fail _every_ time, but I keep seeing the problem in
> various Emacs versions, including Emacs 29.
>
> Example log: https://builds.sr.ht/~bzg/job/1047678#task-build
>
> In the test
Ihor Radchenko writes:
> Henrik Frisk writes:
>
>> Recently (not sure when) the ics output came out malformed and a newline is
>> omitted between the end of one event and the beginning of another:
>>
>> END:VEVENT
>> BEGIN:VEVENT
>>
>> is now
>>
>> END:VEVENTBEGIN:VEVENT
>>
>> I can't figure out
Ihor Radchenko writes:
> LGTM! Feel free to push.
Pushed to bugfix (c81dba2fb) and merged to main (b49275acb). Pushed the
unit test as a separate commit to main only (8000b1120).
is hanging
while waiting for startup. However, we can just replace it with a
`sleep-for' instead, because we now wait for
`org-babel-python--initialized' anyways.
See the attached patch. Please let me know if it fixes the problem for
you.
>From d5721aa37a399afcd527906e5d9f1b6bce37fdb9 Mon Se
Ihor Radchenko writes:
> Jack Kamm writes:
>
>>>FAILED 376/1256 test-ob-python/session-multiline (0.011955 sec) at
>>> ../lisp/test-ob-python.el:105
>>
>> Hmmm. Do you have an idea of how long this has been happening, and how
>> frequentl
Ihor Radchenko writes:
> Hi,
>
> We have fairly regular CI test failures for one of the ob-python tests.
> The test does not fail _every_ time, but I keep seeing the problem in
> various Emacs versions, including Emacs 29.
>
> Example log: https://builds.sr.ht/~bzg/job/1047678#task-build
>
> In t
Jack Kamm writes:
> Liu Hui writes:
>
>> I think these objects need to be shown in a single column rather than
>> two. Besides, if the python code becomes too complex finally, I think
>> maintaining the python code outside the ob-python.el, as suggested by
>> Ih
Ihor Radchenko writes:
> +1
> Don't forget to update
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html
> (note how the docs already have an example of org formatting from python)
Thanks! Done now:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=579e8c57234
Liu Hui writes:
> I think these objects need to be shown in a single column rather than
> two. Besides, if the python code becomes too complex finally, I think
> maintaining the python code outside the ob-python.el, as suggested by
> Ihor, is a good idea.
Thanks for reporting these misbehaving e
Ihor Radchenko writes:
> We might add the code into a separate proper python file. Then, we can
> use the contents of that file to retrieve the variable value.
>
> We already do the same thing for CSL style files and odt schema/style.
Thanks, I think this is a good idea, and will make the python
Ihor Radchenko writes:
> Similar to the existing LaTeX formatters, one may write a Python package
> that will pretty-print Org markup as text.
This sounds interesting -- are these LaTeX formatters external to Org?
Could you provide a link/reference?
gerard.vermeu...@posteo.net writes:
> 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.
org-babel-python--def-format-value is a "private" variable (it has
double dash "--" in its name). There
Ihor Radchenko writes:
> This is an ORG-NEWS entry for Version 9.4. Is it an intentional change?
Sorry, that was an accident. I've reverted it now:
https://github.com/jackkamm/org-mode/commit/f12a695d67bc5c06013d9fbe0af844c9739e347a
>> @@ -142,7 +144,9 @@ (defun org-babel-python-table-or-string
Liu Hui writes:
> Hi,
>
> Thank you for the patch!
Thanks for your feedback, I've incorporated it into
https://github.com/jackkamm/org-mode/tree/python-results-revisited-2023
More specifically, here:
https://github.com/jackkamm/org-mode/commit/af1d18314073446045395ff7a3d1de0303e92586
> Do we n
Ihor Radchenko writes:
>>> #+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
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,
st.orgmode.org/caoqtw-n9re7fdrm1apmo8x5lrzmjfn_zjht3rvaf4x+s5m_...@mail.gmail.com/
[2] https://list.orgmode.org/87eenpfe77@gmail.com/
>From 468eeaa69660a18d8b0503e5a68c275301d6e6ae Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Mon, 7 Sep 2020 09:58:30 -0700
Subject: [PATCH] ob-python: Res
Ihor Radchenko writes:
> We may instead arrange org-lint and possibly ob-core to throw a
> warning when an src block uses confusing setting combinations.
> Without changing the underlying behaviour.
> Basically, discourage using confusing staff.
> ...
> We should update the docs to avoid such exa
Liu Hui writes:
> Thanks for pointing out the problem! I find the problem disappears
> after removing the `run-python` line, and I have updated the patch
> accordingly.
Thank you. I applied your patch to main branch.
I am curious why the previous version of your test was causing hanging
-- whet
Liu Hui writes:
> OK, I have added a test to the patch.
While your test works on its own, it seems to break subsequent tests
(the next test hangs).
My guess is that it has something to do with the fact that most of the
Python session tests share the same session, and ob-python is getting
confus
Ihor Radchenko writes:
> ":results file" imply that results of the code block are written to a file
> (the file is specified using header args).
>
> ":results file link" imply that results of the code block are interpreted
> as file link. The fact that presence of :file header arg overrides this
gt; should create a buffer named "*Python 3*"
>>
>> 4. Press C-c C-c on the src block. Then an error "No inferior Python
>> process running" is shown.
>
> Confirmed.
> CCing Jack Kamm, the maintainer.
And I can confirm now as well. Thanks for reporting, and for the patch.
The patch looks good, but it would be nice to include a unit test as
well -- could you update the patch to include one, Liu Hui?
Thanks,
Jack
Liu Hui writes:
> I think your proposal about ":results graphics" is more flexible and
> complies the documentation. Since the patch has no real problem and
> the feature is useful indeed, I hope it can be merged instead of mine
> after the problem of documentation is resolved.
Thanks for your g
Ihor Radchenko writes:
> Your patch appear to only add more confusion, IMHO.
>
> I feel that the description about :results file is confusing from the
> very beginning:
Well, I guess ":results file" has confusing behavior. So it's
difficult to write accurate, comprehensive, non-confusing
documen
Liu Hui writes:
> I don't think so. Some users may want to keep the figure between
> blocks, and they can always clear the figure themselves when
> necessary.
I'd rather not have to call pyplot.gcf().clear() every time, it doesn't
seem nice. ob-R doesn't require manually clearing the plot, and
Ihor Radchenko writes:
> Jack Kamm writes:
>
>> I think the Worg documentation is accurately describing the behavior of
>> ob-python -- it's just that ob-python uses ":results file" in a
>> nonstandard way.
>
> May you please point me to the place in
Ihor Radchenko writes:
> WORG documentation is not accurate here.
>
> If the block has :file parameter _or_ :file-exp parameter and #+name,
> the results of evaluation are inserted into a file. Otherwise, results
> of evaluation are interpreted as file name--*undocumented*.
>
> That said, your pa
1 - 100 of 295 matches
Mail list logo
