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
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:
> 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
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
#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
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
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
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
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
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:
>> 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:
> 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:
> 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:
> 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
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:
> 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
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:
>> 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:
> 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:
> 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
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:
> LGTM. Thanks!
Thanks, I've applied now:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=da2b61b09e1eff957e6b2560a2f9c8509de6beac
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:
> 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:
> 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
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
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
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
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
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
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
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
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:
> 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:
> +(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
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:
>> 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
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
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
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
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
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
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
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
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 -
Hi all,
ob-reticulate is now available on MELPA.
You can find more information here:
https://github.com/jackkamm/ob-reticulate
Cheers,
Jack
de, but it probably can't, because it depends on the external
async.el.)
> p.s. After this is merged, it would be great to see support for other
> languages grow :)
I also have an async implementation for ob-R that's ready after this is
merged :)
Cheers,
Jack
[1] https://github
Hi Jeremie,
> Many thanks for this package. It seems like a better way all together
> to manipulate python output.
I don't disagree, at least when it comes to handling dataframes.
This is because ob-reticulate makes the block actually executed with
ob-R.el instead of ob-python.el. R has better b
Hi Adam,
> I further noticed that this overloading of the internal priority by
> including timestamp and habit data causes disruption to the behaviour
> I imagine most users would expect from `org-agenda-sorting-strategy'.
> For example, if you have `priority-down' as the first entry in the
> `age
Hi Timothy,
> This is moving at a glacial pace, but I'd love to see this merged ---
> there's clearly a lot of interest in this from the community if not
> within this mailing list (ob-async which is more limited has 250 stars
> on GitHub).
Yes, this has taken far too long -- sorry about that.
T
+1 from me. It is nil in my config, which feels better to me.
Hi Bastien,
Bastien writes:
> Please feel free to commit this patch in master so that more people
> can test it, we can test and fix oddities while preparing for 9.5.
OK, I have incorporated the minor fixes from Kyle's review and pushed to
master.
Cheers,
Jack
Hi ian,
ian martins writes:
> I gave this a try and it works for me. One thing I noticed is that if you
> run a call asynchronously, the final result ends up under the source block
> instead of the call. In the example below both RESULTS were written after
> I ran the call.
>
> #+name: test
Sorry for the noise, replying to add the X-Woof-Patch:applied header.
Eric S Fraga writes:
> On Tuesday, 4 May 2021 at 01:49, Timothy wrote:
>> For the future, I'd think Julia actually warrants 1st class inclusion in
>> Org, and I've instigated an effort to write an ob-julia that works well.
>
> +1! Happy to help test if you wish. I use Julia as my programming
>
Hi Greg,
Greg Minshall writes:
> but i also feel a need for something that might be called a lab
> notebook, a development log, of ideas, including dead ends, i pursue
> during the development process, with links, etc.. but, i'm not really
> sure how to structure this bit, how to integrate it i
Hi Jeremie,
Jeremie Juste writes:
> Just a precision async process is already available in R. Thanks again
> to Jack Kamm for this input.
I believe async evaluation in R still requires my external package:
https://github.com/jackkamm/ob-session-async
Are you sure you don't have t
Hello Uwe,
Uwe Brauer writes:
> (defalias 'org-babel-execute:matlab 'org-babel-execute:ipython)
ob-ipython is not part of org-mode core, so I don't think this can be
considered a bug here.
While the original ob-ipython is unmaintained, scimax [1] maintains a
fork of it, so you could consider s
Hi all,
> I obviously missing something. The above works for me without the
> patch. Unfortunately, I can't trace back the thread in order to
> understand the context.
I think this is a followup from this mail:
https://orgmode.org/list/87zgxc42qg@gmail.com/
wherein Jeremie states:
> The cu
Hi Jeremie,
>> The requirement for a second file parameter was added in Org 9.3 to
>> support the use case in this thread:
>>
>> https://orgmode.org/list/3ac2f42a-8ff2-1464-fa36-451e2ef0e...@pressure.to/
>>
>> But this syntax is annoyingly verbose for ob-R users, and also broke
>> lots of ob-R exa
Timothy writes:
> Would it be strange if running the code block with just
>
> :output graphics
>
> Automatically added "link" if *only* graphics is set, and generated a
> file name if no :file is set?
It wouldn't be strange. ob-jupyter [1] auto-generates file names for
images, and it's convenien
Hi Chuck,
> A user might like to construct a figure consisting of various subfigures such
> as in a subfloat environment.
>
> Will this be reasonably simple to accomplish if `:results graphics' (with no
> `file' element) automatically inserts a link?
>
> Currently, omitting the file element leav
Hello again,
>> A user might like to construct a figure consisting of various subfigures
>> such as in a subfloat environment.
>>
>> Will this be reasonably simple to accomplish if `:results graphics' (with no
>> `file' element) automatically inserts a link?
>>
>> Currently, omitting the file el
Hi Chuck,
> Here is an ECM that when exported with `C-c C-e l o y y` (or 'yes RET' for
> each `y' depending on your setup)
I don't see the example on your last email, could you try re-attaching
it?
Thanks,
Jack
Hi Chuck,
> If you modify the ECM to change `:exports results' to `:exports
> none' and clean older fig[12].png's from the directory, the export
> fails.
Thanks for this example. I had mistakenly thought that code blocks
with ":exports none" would be evaluated for side effects, but you are
right,
Hi Augusto,
> In Emacs 28, `python-shell-send-string' prints an additional newline
> between the prompt and output (among other things, so you can tell
> whether or not the inferior process is busy at any given time).
>
> However, this interferes with ob-python, see e.g.
> https://debbugs.gnu.org/
Hi Jeremie,
> For the parameter :async without any values assigned to it. I'm
> coordinating with ob-python.el and the orginal package
> https://github.com/jackkamm/ob-session-async.
>
> Jack do you see the need to change it and expect :async to have the
> value yes or no?
I wrote the :async hea
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.
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
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
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
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:
> 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
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:
> 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
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
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
Ihor Radchenko writes:
> I have no further comments.
> Feel free to push.
Applied. Thanks for your help and review!
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
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:
>> +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
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:
> 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
Ihor Radchenko writes:
> I have no further comments.
> Feel free to push.
Pushed now. Thank you and happy new year!
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 ++--
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:
> 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
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(+)
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
upport for using ":results value" with pandas, numpy, and
matplotlib objects. I am attaching a fix.
Ihor -- normally I would just push this to main, but I think it might be
worth pushing this to bugfix branch instead, so I wanted to check with
you first if it's alright for me to do
Ihor Radchenko writes:
> It's just a variable rename. Should be safe for bugfix I think.
Great, thank you. I've pushed to bugfix and merged into main.
Ihor Radchenko writes:
> Anush V writes:
>
>> Hello Org Maintainers,
>>
>> Is it possible to add an 'auto' option for the variable
>> org-babel-python-command-nonsession, similar to how
>> org-babel-python-command and org-babel-python-command-session already
>> support it?
>
> I am not sure. 'au
201 - 298 of 298 matches
Mail list logo
