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
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
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,
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
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.
Ihor Radchenko writes:
> +(defun org-babel-session-buffer ( 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
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 return a
&
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
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-comint.el (org
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
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,
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
b-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: Jack Kamm
Date: Wed, 31 Jan 2024 20:06:00
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
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:
>>
>>
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
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
Ihor Radchenko writes:
> LGTM. Thanks!
Thanks, I've applied now:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=da2b61b09e1eff957e6b2560a2f9c8509de6beac
ndar--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(-)
diff --git a/doc
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
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
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.
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
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
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 to keep
`ess-make-buffer-curren
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
>
>
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
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
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
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
t-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.
That's a good catch.
I've fixed this by reverting `org-babel-execute:python'
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,
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: Changed options for defa
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:
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
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
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
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).
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 Sep 17 00:00:00 2001
From:
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
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:
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
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
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).
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
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
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-list-to-org' with a
list of type "descriptive" instead of "unordered" here:
https://git.sr.ht/~bzg/org-mode/tree/cc435cba71a99ee7b12676be3b6e1211a9cb7285/item/lisp/ob-core.el#L2535
>From c24d2eeb3b8613df9b9c23583a4b26a6c0934931 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Wed, 16 Aug 2023 20:
f4x+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: Results handling for dicts, dataframes, arrays,
plots
*
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
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
--
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
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
t; 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
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
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 ob-p
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
Liu Hui writes:
> Hi,
>
> This patch adds graphics output support for ob-python via matplotlib.
> Specifically, it allows to use header argument `:results file
> graphics' as follows:
>
> #+begin_src python :file "test.png" :results graphics file
> import matplotlib.pyplot as plt
>
Ihor Radchenko writes:
> Liu Hui writes:
>
>> This patch adds graphics output support for ob-python via matplotlib.
>> Specifically, it allows to use header argument `:results file
>> graphics' as follows:
>>
>> #+begin_src python :file "test.png" :results graphics file
>> import
the prior patch before applying to main.
>From 80c05e00335062cc96bdcd85ec507066af4a1d3b Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sat, 17 Jun 2023 07:55:17 -0700
Subject: [PATCH 2/3] ox-icalendar: Display warning for unsupported repeaters
This commit to be squashed with the previ
ld ignore it.
>From 1135e3e7cb08353892c439b085d3bf0bf1072ecb Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sun, 11 Jun 2023 07:50:20 -0700
Subject: [PATCH] ox-icalendar: Add support for unscheduled and repeating TODOs
* lisp/ox-icalendar.el (org-icalendar-todo-unscheduled-start): New
customization to control
Ihor Radchenko writes:
>> So technically, a standalone DEADLINE + repeater isn't allowed -- a
>> repeating task must always have a start date.
>
> May we then use org-deadline-warning-days/timestamp warntime spec as DTSTART?
> VALARM component is not fitting for warning days anyway.
>
>> But
Jack Kamm writes:
> writes:
>
>>> > There is a related issue about EOLs, not just \r\n -- each line should
>>> > be a maximum of 75 characters; this is handled by
>>> > org-icalendar-fold-string
>>>
>>> May you please provide
Ihor Radchenko writes:
> The question is: does iCalendar allow something like
>
> DTSTART;TZID=America/New_York:19970105T083000
> RRULE:FREQ=YEARLY
> DUE;TZID=America/New_York:20070105T083000
>
> and repeats past DUE?
>
> If not, we have to choose when exporting from Org source - either to
>
Ihor Radchenko writes:
> Another scenario we may need to consider is when schedule has a repeater
> while deadline does not, and vice versa. The former scenario is probably
> valid - a VTODO with limited number of occurrences.
That is an interesting idea; and we can use the UNTIL or COUNT
writes:
>> > There is a related issue about EOLs, not just \r\n -- each line should
>> > be a maximum of 75 characters; this is handled by
>> > org-icalendar-fold-string
>>
>> May you please provide a link to the iCalendar spec document section
>> describing this requirement?
>
> It's in
Ihor Radchenko writes:
> Sorry for the late reply.
>
> Do I understand correctly that all the ical lines must use \r\n? [1]
Following up here that I have pushed a fix for the EOL issue in
ox-icalendar:
feedback on the original VTODO-related
patches (thanks for that review). I'll work on that next, but it might
take me a bit longer.
>From aa59625cd08dcee767f42ad8d45d8902aa8d38bd Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sat, 1 Apr 2023 16:53:35 -0700
Subject: [PATCH] ox-icalendar: Use consiste
ng returned by `org-export-as' won't contain
CRLF. Instead, the newlines are converted during post-process.
>From 04761429f82bfd2aee63f4978afec3449abaa37d Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sat, 1 Apr 2023 16:53:35 -0700
Subject: [PATCH] ox-icalendar: Use consistent CRLF line endi
Ihor Radchenko writes:
> I now only have one minor concern about `org-icalendar-fold-string' when
> the original buffer contains DOS line endings. May they mess things up
> producing \r\r\n?
There are 2 issues here: what does `org-icalendar-fold-string' do when
string already contains \r, and
Ihor Radchenko writes:
> Thanks!
> Note that I did not implement my suggestion because I am concerned if
> putting CRLF is safe as every single line ending.
>
> I am looking at
> https://icalendar.org/iCalendar-RFC-5545/3-6-2-to-do-component.html, and
> I note that only BEGIN:VTODO and END:VTODO
d adds a unit test.
Note that fixing the line endings causes a surprising compatibility
issue with org-caldav. I fixed this problem on the org-caldav side, and
made a note in ORG-NEWS.
>From 712a4ef09b63b2f6bdec2a3967712be912dce0d2 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Thu, 30 M
the best way to
handle the case where SCHEDULED and DEADLINE have different repeaters,
so in that case I issue a warning and skip the repeater.
>From 1bd268ab260d5077d7456c0d64fea36128772f86 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sun, 26 Mar 2023 07:43:53 -0700
Subject: [PATCH 1/2] ox-icalen
Matt writes:
> Hi Jack and Jeremie! I'm curious your thoughts about what Ihor and I are
> discussing at the end of this message about `md5'.
Thanks for checking in. I don't see any problems with switching to
org-id-uuid or similar.
Feel free to update ob-python to do this, or I can also do
Ihor Radchenko writes:
> Which is org-caldav's problem not recognizing Org syntax.
I don't think this is a bug in org-mode or org-caldav, nor has to do
with property drawers.
org-caldav just uses ox-icalendar.el to export to ICS, and by default
SCHEDULED timestamp is not exported to calendar
Ihor Radchenko writes:
> Let's follow the usual approach and first deprecate it. It should become
> a constant with 'python value in org-compat.el. Deprecating is not make
> sure that other packages that might be testing the variable value do not
> get broken.
>
> Note that we usually `quote'
45347 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sat, 21 Jan 2023 08:24:41 -0800
Subject: [PATCH] ob-python: Remove python-mode.el support
* lisp/ob-python.el (org-babel-python-mode): Remove customization
variable.
(org-babel-python-initiate-session-by-key): Remove code to support
python-mode
Ihor Radchenko writes:
> However, supporting python-mode.el integration is difficult for Org
> team: neither the current ob-python maintainer nor the rest of Org team
> are familiar with python-mode.el.
>
> The bug discussed above already shows that parts of ob-python do not
> work properly with
Christian Köstlin writes:
> I think we know of the async problem, and you reported that as well,
> so I would expect
> if someone is able to fix it, he will also move the tests to "sharp" again.
Could you provide some references about the async problem, either how to
reproduce it or the
Hi Ihor,
Ihor Radchenko writes:
> However, async evaluation fails when org-babel-python-mode is set to
> 'python-mode.
As a stopgap, perhaps Org could issue an error message that async is not
implemented for python-mode.el
I was actually planning to deprecate ob-python support for
Ihor Radchenko writes:
> I suggest to bind org-id-track-globally to nil file-locally in that
> backup file.
Thanks for the suggestion. I tried it out, and it initially seemed to
work, but eventually the backup file ended up in org-id-files. It seems
like there is more than one way that files
Ihor Radchenko writes:
> Applied onto main via 8f5bf1725.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8f5bf172556564df89fb16ce8ecec68c5b7f0221
My sincere apologies, but after a bit of testing, I found that my
requested change had some unforeseen consequences, and I don't
Hello,
I found that Org entries containing markdown source blocks don't get
properly folded on the main development branch, when markdown-mode is
also loaded.
To reproduce:
1. Download markdown-mode from MELPA or Github. [1]
2. Fix the paths in the attached init.el.
3. emacs -Q -l init.el
Ihor Radchenko writes:
> This is indeed inconsistent. The current behaviour is to scan only files
> where it is known that IDs are present.
>
> Can you try the attached patch?
Thanks, Ihor. I tried your patch and it solved my issue -- both the
minimal example I sent, as well as the related
Hello,
The documentation for org-id-extra-files suggests that org-id-find
should search in Org files visited by Emacs:
> When Org reparses files to remake the list of files and IDs it is
> tracking, it will normally scan the agenda files, the archives
> related to agenda files, ... and any Org
Ihor Radchenko writes:
> Thanks for another detailed report!
> Fixed on main via 39005dc09.
>
> Let me know if you notice any other inconsistencies.
Thanks very much Ihor! Much appreciated :)
I'll let you know if I notice any other issues -- everything seems to be
working well so far.
Best,
Hi Ihor,
> Can you try the attached patch set?
Thanks for the very prompt patchset!
Testing on the minimal example, the patchset solves the problem I
reported.
After some brief testing with my usual config, it solves the problem of
headlines running together after capture, and also solves the
Hi Ihor,
> May you provide the output of M-x org-version?
Org mode version 9.5.4 (release_9.5.4-623-gc66bdb @
/home/jack/dev/org-mode/lisp/)
I also updated org-mode to the most recent version (last commit 5
hours ago).
> I cannot reproduce. Please, update your Org to the latest version, try
>
I started noticing a couple issues with folding, after updating my
org-mode in recent months:
1. Inserting text below or above a folded headline will cause it to
unfold. I am not sure if this is an intentional change, but I find the
new behavior confusing -- usually I am trying to enter a new
1 - 100 of 262 matches
Mail list logo
