Hi Christian,
Thanks for reporting this and providing a fix!
> The function `org-babel-python-evaluate-session' doesn't process temp
> file names with `org-babel-process-file-name' before inserting them into
> the Python code blocks. This causes a 'No such file' error when the
> executing the cod
Merged now -- thanks for your contribution.
Cheers,
Jack
header argument should match between reticulate
and R source blocks.
Cheers,
Jack
>From 0f691a200cf088c72f93f7552d73caeafb8d588f Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Mon, 24 Aug 2020 08:02:17 -0700
Subject: [PATCH] ob-reticulate: Babel source lang for R+Python reticulate
package
* lisp/o
Hi Jeremie,
> I tried to look around and noticed that the documentation regarding
> python with org-mode is aging a bit... Any help will be
> appreciated. I'll be ready to improve the documentation of org-babel
> python setup as soon as I'm more familiar with it myself.
Historically ob-python ha
t committed to ob-R.el before, so thought it would be best to
solicit feedback here before merging this in.
Cheers,
Jack
[1] https://orgmode.org/list/875zgjh8wn@gmail.com/
>From 1dc8e2d2cb01a4e6b82342ea8d8c965df8f5222c Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Fri, 28 Aug 2020 19:16
b9cf4182dd0fbb997 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sat, 29 Aug 2020 00:07:58 -0700
Subject: [PATCH] ob-R: Fix prompt mangling in session output
* lisp/ob-R.el (org-babel-R-evaluate-session): Force comint prompt
regexp to start at beginning of line, to prevent
org-babel-comint-with-ou
s an example of how to plot:
#+begin_src python :results output graphics file :file boxplot.svg
import matplotlib.pyplot as plt
import seaborn as sns
plt.figure(figsize=(5, 5))
tips = sns.load_dataset("tips")
sns.boxplot(x="day", y="tip", data=tips)
#+end_src
ries also be added?
Yes, I've done so now. I'm not sure whether it's better to treat it like
a row or column vector, but since it has an "index", which are the row
names in a DataFrame, I decided to treat it as a column.
>From 40db6b5497de78a9e69de219f4686b405db10c81
Hi Chuck,
"Berry, Charles" writes:
> This problem has been bugging people for years and previous attempts to solve
> it have always run up against creating more problems in the process of
> solving this one.
>
> If you do decide to dig into solving this, please be sure that remote
> sessions
and I'm not sure I'm up for it.
I also noticed that I had left a couple docstrings as TODOs -- I'll fix
those before finalizing the patch over the next couple weeks.
>From 76a1ad4d50e6638244d9aa17e45895b8b38b3cd0 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sun, 30 Aug
Hi Bastien,
> Would you be okay to add yourself as the ob-python.el maintainer?
Sure, I've added myself as maintainer to the header of ob-python.el.
> I suggest we have a policy that "Org maintainer(s)" have the last
> words on everything in Org's core, but that individual maintainers,
> when kn
Hi Bastien,
> - A local maintainer is expected to reply to requests and bug reports
> regarding the local functionalities he oversees.
>
> - A local maintainer can commit changes directly to the file(s) he
> maintains (either submitted changes or his own).
>
> - Core maintainers have the final
ylan's examples as unit
tests.
Cheers,
Jack
>From 76d0eaa31506ce8a2f81f64eae43161db5721317 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Mon, 7 Sep 2020 00:41:52 -0700
Subject: [PATCH] ob-R: Fix session output with substrings matching prompts
* lisp/ob-R.el (ess-send-string): Declare ex
I just realized my patch had an issue where it freezes if there is an
error in the source block.
I'm attaching a second patch, to be applied on top of the first one, that fixes
the issue.
diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index b37e3965a..5ddf0ebd1 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-
".
4. If you prefer to start "M-x shell" locally and then
ssh in, it's still possible to have default-directory set, but it
requires some configuration [1]. Or you could use "M-x cd" to set it as well.
[1]
https://emacs.stackexchange.com/questions/5589/automatically-u
Hi Chuck,
> I can confirm that this works on my setup in each of the scenarios in which
> `default-directory' got set correctly in the session buffer.
>
> At some point, my default-directory got reset to drop the tramp prefix
> "/scp:/user@host:" in one session after faithfully running the src b
Kyle Meyer writes:
> That's on a Debian system with the python executable pointing to Python
> 2.7.16. If I set org-babel-python-command to python3 (3.7.3) at the top
> of test-ob-python.el, I see the same thing. I haven't dug any farther
> yet. Jack, presumably you don't see the stall on your
"Berry, Charles" writes:
> Also, I wonder if the `:results value' case can be handled in a similar
> manner, viz.
>
> - (let ((tmp-file (org-babel-temp-file "R-")))
> + (let ((tmp-file (with-current-buffer session (org-babel-temp-file "R-"
Yes, if we did that then tmp-file would have a p
Hi Chuck,
> this is already present in `org-babel-R-evaluate-session' in the call to
> `org-babel-comint-eval-invisibly-and-wait-for-file'' just a couple of lines
> further down in the `(cl-case result-type (value ...))' branch.
>
> The other use of `tmp-file' in that block is the one that requi
Kyle Meyer writes:
> With Org's master (f17d301e1), the second one hangs for me with Emacs
> 26.3. Quickly stepping through org-babel-python--send-string, it
> appears to get stuck in the accept-process-output call.
>
> Using an Emacs built from master, there's no hang on my end either. If
> yo
s/ob-doc-python.html
[1] worg commit 59e320ad
Cheers,
Jack
>From 118d8b5eb817e9a21e9d84f2f942fcc841ddc51f Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Sat, 19 Sep 2020 08:44:30 -0700
Subject: [PATCH] ob-python: Improvements to :return header argument
* lisp/ob-python.el (org-babel-execute:py
Thanks -- I've pushed this to master now.
Jack
Bastien writes:
> Hi Jack,
>
> Jack Kamm writes:
>
>> For now, I think I prefer to keep ob-python leaner, so am going to hold
>> off on this.
>
> The leaner the less maintainance ahead :)
>
>> I'
Hi Adrian,
Adrian Kummerländer writes:
> I noticed that after updating to Org 9.4 many of my Python-based Org
> files fail to execute with various `io.TextIOWrapper' related error
> messages. The reason for this is that opening the exec tmpfile as `f'
> shadows this possibly user-defined variabl
Checking back in on this since Org 9.4 has been released. This issue
should be fixed now, and my tests corroborate this. If you're still
experiencing this problem after updating, please let me know.
Best,
Jack
Jack Kamm writes:
>> I redid the test but loaded the lastest org-mode an
Hi all,
I've put ob-reticulate.el on github so it can be more easily used:
https://github.com/jackkamm/ob-reticulate
I plan to submit it to MELPA or GNU ELPA over the coming weeks as well.
Cheers,
Jack
Thanks Bastien, the Woof! tool looks interesting.
By the way, on seeing this thread again, I realized this patch probably should
have been applied to the maint branch. So I've cherry picked it into there, and
merged back into master.
Bastien writes:
> Hi Jack and Adrian,
>
I
need to confirm copyright assignment on the Ruby implementation which
was externally contributed.
[0]
https://orgmode.org/list/87muj04xim.fsf@jaheira.i-did-not-set--mail-host-address--so-tickle-me/
[1] https://github.com/jackkamm/ob-session-async
>From 8b7695a148d1831c916737650e115833cb7fc752 Mo
Thank you Timothy! It looks great.
Bastien writes:
> Dear all,
>
> thanks to the initiative and the patient efforts of Timothy, our
> website has been revamped: new contents, new look and... the old
> unicorn!
>
> Thanks very much to Timothy and to everyone who contributed with
> feedback and id
Hi Jeremie,
Thanks for volunteering to maintain ob-R.el :)
I'm bumping this patch [0] to see if it could be merged into ob-R.el. It
fixes some long-standing issues with prompt mangling for :session blocks
with :results output.
Elsewhere in the thread, Chuck had a suggestion [1] to allow :results
hether the functionality is available, and to
silence compiler warnings. I'm not sure if this is the correct way to do
it.
>From c5f9d4043a6cf6a325d122be24214356f36446f1 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Wed, 28 Oct 2020 17:29:04 -0700
Subject: [PATCH] ol.el: New option &quo
Hi Timothy,
TEC writes:
> I feel that this also ties into my earlier idea of putting Emacs
> as/inside an LSP server for Org. I suspect there may be a a lot
> of
> potential in making it dead easy to use Emacs as a tool.
I'm too busy to help on this, but I think it's a very good idea and hope
Hi Steven,
Sorry for the delayed response.
> The problem, however, is that what is exported to html and displayed in the
> exported block is either the actual UUID or the tempfile path and not the
> results from evaluating the R code. In the case of the tempfile, the tempfile
> exists but is empt
Hi Sebastian --
> I am having problems with the fontification of python and ipython source
> blocks when the code contains curly brackets "{}" (other course blocks are
> ok). For instance, the following snippet
>
> #+BEGIN_SRC python :results drawer
> import matplotlib.pyplot as plt
> plt.plot([1,
a new project.el via ELPA.
> More on that below.
Good catch. I didn't realize I was using project.el from ELPA but it
turns out I was.
>From d156a9cfcdbfb9be72df3976e2355f48cf10 Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Wed, 28 Oct 2020 17:29:04 -0700
Subject: [PATCH] ol.el: New
Thanks, I've fixed the remaining issues you pointed out and pushed this
in 5371b30fe.
Cheers,
Jack
Hi Joost,
> What I'm trying to do is to import a Python file with a bunch of utility
> functions into the ob-python session. I thought this might be possible if I'd
> structure my code as a regular Python package, because that works if I want to
> import my utility functions into another Python fi
Jack Kamm writes:
> You need to make sure your module is either in the working directory you
> started the Python session in, or in your PYTHONPATH, for example by
> adjusting os.env["PYTHONPATH"] before attempting to import the module.
Sorry, this was incorrect, you nee
Joost Kremers writes:
> I haven't really considered the option to install the utility functions as a
> package in the virtual environment, because I expect to change and develop
> those
> functions together with the rest of the project. If it were a separate
> package,
> I'd need to reinstall i
Hi Paul,
I'm unable to reproduce the issue, and believe this issue has already
been fixed in the latest version of org-mode. See this patch [1]. Could
you please upgrade to Org 9.4 and test again?
Thanks,
Jack
[1]
https://orgmode.org/list/87h7t16red.fsf@pc.i-did-not-set--mail-host-address--so-t
> Jack, as the author of the org-display-remote-inline-images commit, what
> do you think about this patch?
This patch takes the same approach as an earlier attempt by Kit in 2014
[1]. That patch was never merged; Michael objected that the approach
seemed too complex, and suggested using file-loc
Canceled.
> I just added a call for help about this. Thanks!
This help request is old, and also it was never clear what concrete
enhancement was desirable, or what specific problem there was with the
existing cacheing mechanism. So I think it just adds noise to
updates.orgmode.org.
Therefore, I
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 head
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
>
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 p
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,
J
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 fi
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 issue
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 test.o
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 th
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 may
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
python-mode.
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 underlyi
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
fa61b8a3f445347 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
p
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' Eli
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 VE
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 it
t sure 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]
was missing
"\r", and 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
Fr
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
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 wh
means the string 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 cons
orgotten your 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] o
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:
https://list.orgmode.org/87355ikzwk.fsf@localhost/T/#m180c100587d3d88ab5787942271a546b5189199
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 rfc55
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 keywor
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
> keep
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 a lin
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 stil
is case, and we should 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
customiz
I will squash with 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 squ
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 matplotlib.pypl
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
> plt.plot([1,2,
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
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
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:
> 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 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
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
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
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
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
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
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
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,
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
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:
> 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
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:
> 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?
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
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:
> +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
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:
> 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
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
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:
> 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).
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:
> 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
101 - 200 of 298 matches
Mail list logo
