Re: Turn Emacs holidays into Org appointments?
Hi David and all, David Rogers writes: > Is there a way that I can use something like the Emacs holiday > forms ... but from inside an Org-mode appointment timestamp Yes, this should be possible. > Here's a mock example of what I'm trying to do: > > * Easter > <(holiday-easter-etc 0)> > ** stuff for Easter > > * The Sunday after Easter > <(holiday-easter-etc 7)> > ** stuff for after Easter Actually, you're pretty close already. Org understands diary sexp entries in timestamps, and diary sexp entries basically allow arbitrary elisp, so you should be able to use the diary functions in combination with the holiday functions to do what you want. See the 'Timestamps' entry in the Org manual, and the 'Special Diary Entries' entry in the Emacs manual, for more. Here is a quick and dirty proof of concept; see if it works for you: * The Sunday after Easter <%%(apply #'diary-date (caar (holiday-easter-etc 7)))> The angle brackets tell Org this is a timestamp. The '%%' says that the following sexp is a diary sexp. And the code inside it feeds the (M D Y) date representation returned by holiday-easter-etc into diary-date. You may need to fiddle with this a bit...holiday-easter-etc is a bit too closely tied to the calendar (it depends on a couple of calendar variables, displayed-year and displayed-month, that cannot be dynamically bound). But you could create your own version that doesn't have this limitation. Hope that helps. -- Best, Richard
Turn Emacs holidays into Org appointments?
Hello I'm using Org-mode to organize readings and music for Christian church services. These services are scheduled according to certain holidays, and Emacs already "knows" all of the holidays that matter for this discussion - they're viewable by selecting the appropriate settings for the calendar. (The ones that don't matter right now are those that are simply X days or X weeks from the important ones.) I don't currently view or use any of the Emacs holidays as they were intended, and I don't really need to. Is there a way that I can use something like the Emacs holiday forms - shown at https://www.gnu.org/software/emacs/manual/html_node/emacs/Holiday-Customizing.html - but from inside an Org-mode appointment timestamp, so that I can use the result in my "Work2022.org" file? Here's a mock example of what I'm trying to do: * Easter <(holiday-easter-etc 0)> ** stuff for Easter * The Sunday after Easter <(holiday-easter-etc 7)> ** stuff for after Easter This way, there would be less chance for error on my part, and the scheduling lines would stay the same from year to year, rather than having to look up individual dates and re-write them. I'd prefer them to show up as appointments and schedules that I can modify and rearrange one by one in the scheduling lines of my Org files, rather than as a group of holidays that get inserted into the agenda from a holidays file - but maybe that just isn't how Emacs is set up. I suppose if I ended up with my own extremely customized holidays file, and I added a link in each day's Org subtree to the corresponding line in the holidays file, that could be a workaround . . . -- Thanks David
Re: Org for non-users, part 2: `C-c C-e', a.k.a. `org-export-dispatch'
On Mon, 7 Feb 2022 at 10:55, Ihor Radchenko wrote: > > What are the recommended ways to abort org-export-dispatch without > > letting it destroy the "*Org Export Dispatcher*" window and its > > buffer? > > You cannot. That window acts similarly to transient, but simpler. You > can think of *Org Export Disipatcher* as an extended help for > read-char-exclusive. > > Best, > Ihor > Hi Ihor, What do you mean by "you cannot"? I was expecting an answer like this: That's difficult to do, but the temporary buffer is generated by the function `org-foo-bar'... you can try to make a copy of `org-foo-bar' called `org-foo-bar-hacked-version', add your own debugging functions to that copy - suggestion: the lines 42 and 99 are good places for that - and then you can change the function `org-plic-ploc', that is called by `org-export-dispatch', to make it call `org-foo-bar-hacked-version' instead of `org-foo-bar'... One possible meaning of "you cannot" is: Org is NOT MEANT to be explored in that way, and this "is not meant to" is in a very strong sense. The last time that a person gave technical information of that kind in the mailing list was 4 or 5 years ago, and we banished her from the community and excommunicated her. Her name shall not be mentioned. Frustrated cheers =(, Eduardo Ochs http://angg.twu.net/#eev
Re: Lazy load of org-protocol
On 2/7/2022 6:57 AM, Max Nikulin wrote: Maybe another option would be to add an --apply argument that really *does* consume the other command-line args and turns them into a properly-quoted function call. Roughly speaking, it would turn this: emacs --apply func foo bar baz into this: (apply #'func '(foo bar baz)) You have almost managed to sell this idea to me. However even --apply is just sugar for emacsclient --eval "(apply #'func command-line-args-left)" --arg 1 2 So it is --apply option that may require to write a dedicated function if --arg is not implemented. Another limitation of --apply is that the function must accept string arguments only, no lists or even integers or boolean. Yeah, `--arg' does have greater flexibility in that regard, but it comes at the cost of verbosity and some slight behavioral differences with the equivalent in the main emacs executable. For emacs itself, any elements of `command-line-args-left' that aren't consumed by a function will get opened as files, but I don't think that would be the case with emacsclient. Does this difference matter? Probably not. However, avoiding `command-line-args-left' just feels intuitively "cleaner" to me. Still, I think `--arg' should work and be backwards-compatible, so I don't mind it, even if I prefer the simplicity of `--apply'. On a related note, there is still an issue with `--eval' in some cases. It fails to work with emacsclient when invoking an alternate editor: emacsclient --alternate-editor emacs --eval '(message "hi")' If Emacs isn't already running, that will open a new buffer named '(message "hi")'. I think that's just a bug in how emacsclient handles `--eval', though fixing it would make org-protocol links work more reliably (if they used `--eval' as proposed, that is). - Jim
Re: [PATCH] Fix FAQ entry about mailto links.
Robert,
Thank you for pointing out that `org-link-mailto-program' should not be
recommended in FAQ any more.
I prepared an alternative patch that recommends to customize Emacs
variables at first. I hope, an example is safer now, however I can not
test it on MacOS. Could you, please, review the patch, since I may miss
something important from your point of view?
On 07/01/2022 18:03, Max Nikulin wrote:
On 07/01/2022 01:34, Robert Goldman wrote:
+You can also change the function used to a different one. For
+example, the following function (on MacOS) opens =mailto:= links in
+the =MailMate= program:
I am unsure if MailMate is acceptable since it is a proprietary
application. Org is a part of *GNU* Emacs, so it may be better to
mention some free mail user agent.
+#+begin_src elisp
+("mailto" :follow
^
It seems, `org-link-set-parameters' is missed.
I am sorry, I missed that you suggested to customize the
`org-link-parameters' variable, so function call is not necessary here.From 2ace0101654f61361b6f37bf3273f8520f2c Mon Sep 17 00:00:00 2001
From: Max Nikulin
Date: Mon, 7 Feb 2022 23:40:37 +0700
Subject: [PATCH] FAQ: Update suggestion for mailto: link handlers
org-faq.org (mailto-links): Mention `org-link-mailto-program' as removed
variable, recommend customization of `browse-url-mailto-function' or
`org-link-parameters' instead.
Robert Goldman in
https://list.orgmode.org/fead92a6-87de-4cff-8459-e3d012dd3...@sift.net
proposed a patch removing mention of `org-link-mailto-program' variable
that is not used in the code for some time. The patch has an example of
usage `org-link-parameters' to assign custom external handler for
mailto: links.
This change recommends to configure Emacs facilities used by Org as
well. It has a safer example for `org-link-parameters' customization.
---
org-faq.org | 87 ++---
1 file changed, 76 insertions(+), 11 deletions(-)
diff --git a/org-faq.org b/org-faq.org
index 4b34560c..b6bde3ca 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -1926,21 +1926,86 @@ For example:
#+index: Link!Mailto
-You can customize the function org-mode uses to open mailto links by
-setting the variable =org-link-mailto-program=:
+Org calls ~browse-url~ function for =mailto:= links, so it should obey
+your Emacs configuration. If something goes wrong then
+[[info:emacs#Browse-URL][info "(emacs) Browse-URL"]] may be a good starting point.
+
+By default mail is composed in an Emacs buffer. If you prefer some
+external application instead than set ~browse-url-mailto-function~ to
+nil, e.g. using
+[[elisp:(customize-variable 'browse-url-mailto-function)][=M-x customize-variable RET browse-url-mailto-function RET=]]
+and =mailto:= links will be opened accordingly to
+~browse-url~browser-function~ value.
+
+If you intention is to compose messages in Emacs then consult
+[[info:emacs#Mail Methods][info "(emacs) Mail Methods"]]. Check that ~browse-url-mailto-function~
+has its default value ~browse-url-mail~. Emacs has several mail
+packages, so next step may be
+[[elisp:(customize-variable 'mail-user-agent)][=M-x customize-variable RET mail-user-agent RET=]] to set the variable
+to e.g. =gnus-user-agent=.
+
+If you prefer an external application other than configured in desktop
+environment then you should write a custom URL handler function. Be
+careful, try to avoid shell (e.g. ~shell-command~ function) since it
+is easy to mess up with escaping of the URL argument and thus to allow
+execution of arbitrary code. Some parts of links may be treated as
+shell specials. Choosing of a proper function to invoke external
+application is a non-trivial task even for seasoned Emacs developers.
+Consult source code of ~browse-url-xdg-open~,
+~browse-url-default-macosx-browser~, or
+~browse-url-default-windows-browser~ for GNU/Linux,
+Mac\nbsp{}OS\nbsp{}X, or MS\nbsp{}Windows platforms accordingly.
-=M-x customize-variable org-link-mailto-program=
-
-The default function called is =browse-url=, which opens a mail
-composition buffer within Emacs. The type of buffer opened by
-browse-url depends on the setting of the variable =mail-user-agent=.
-Thus, if you want to ensure that mailto links use Gnus to open a
-message buffer, you could add the following to your =.emacs=:
+#+begin_comment
+Recurring source of pain is interaction of Emacs function with
+=xdg-open=, =kde-open5=, =gio open= utilities on Linux. While
+~call-process~ with 0 as ~DESTINATION~ argument for
+~browse-url-generic~ was settled in 2004, ~browse-url-xdg-open~ was
+evolving to similar code in 2011. Notice that application has no
+chance to notify Emacs about failure.
+
+Example of confusion that fortunately was not resulted in changing of
+code: [[https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9779#29]] There was
+a lengthy thread "& and M-& to run programs asynchronously" in 2009
+with strange conclusion that it is a bug in Gnome utility:
Re: Suggestion: convert dispatchers to use transient
I agree that transient dispatchers would be great and consistent. What is not so great with transient currently is it’s lacking support for lisp-variable/option workflows. Transient is good for command-line arguments, but setting options for emacs functions is not as streamlined (this would be relevant for the export dispatcher for example). Some new classes for these types of options would probably need to be defined, since the default infix-classes assume all options are strings. I recently did try to implement a transient dispatcher this for my orgqda package: https://gitlab.com/andersjohansson/orgqda/-/blob/main/orgqda-transient.el Partly inspired by org-ql: https://github.com/alphapapa/org-ql/blob/048de35b07d8d29fc6fa49c34d7ba1fd1c912011/org-ql-view.el#L501 I now store the options as plists in buffer-local-variables, which I am not sure is optimal and perhaps goes against the idea of saving options with transient. So still some work to do there. By the way. Getting started with transient is way easier with this tutorial than with the rather abstract info pages: https://github.com/magit/transient/wiki/Developer-Quick-Start-Guide Best, Anders Johansson
Re: Lazy load of org-protocol
On 06/02/2022 09:40, Tianshu Wang wrote: (defadvice server-execute (before enable-org-protocol activate) (unless (featurep 'org-protocol) (require 'org-protocol))) Thank you, such approach, unlike mine example, does not have code duplication. On the other hand it loads org-protocol on any remote command, not only for "files" representing org-protocol URIs. Maybe defadvice in org-protocol.el should be changed by newer advice-add with a function containing body of the old advice. On 07/02/2022 02:40, Jim Porter wrote: On 2/6/2022 8:42 AM, Max Nikulin wrote: On 06/02/2022 01:27, Jim Porter wrote: I think, the solution is to add -arg command to emacs server protocol that pushes its argument to a list and extend -exec command that would make such list available as argv or as `command-line-args-left' for evaluated expression. Of course, emacsclient option parser should be modified as well to support --arg option emacsclient --eval '(func)' --arg 1 2 3 emacsclient --eval '(func)' --arg -- 1 2 3 and maybe even for multiple eval+arg pairs emacsclient --eval '(f1)' --arg 'a1' --eval '(f2)' --arg 'a2' 'a3' I think something like this could work, so long as the arguments can be forwarded correctly in the alternate editor case. If I understand how emacsclient handles --eval, I think that might work, but it would still require writing Lisp functions that know how to handle argv or `command-line-args-left'. I'm also not totally sure how safe/sensible that is when the arguments aren't from the invocation of emacs itself, but from emacsclient (and thus, the args could be updated multiple times throughout a session). It probably wouldn't actually break anything, but it does seem a bit surprising to me... Of course, I mean let-bind of `argv' and `command-line-args-left' just for processing of the passed expression, not setq that would change them globally. Maybe another option would be to add an --apply argument that really *does* consume the other command-line args and turns them into a properly-quoted function call. Roughly speaking, it would turn this: emacs --apply func foo bar baz into this: (apply #'func '(foo bar baz)) You have almost managed to sell this idea to me. However even --apply is just sugar for emacsclient --eval "(apply #'func command-line-args-left)" --arg 1 2 So it is --apply option that may require to write a dedicated function if --arg is not implemented. Another limitation of --apply is that the function must accept string arguments only, no lists or even integers or boolean. This would work effectively like how I momentarily thought --funcall works. Then you could say: emacsclient --apply org-protocol-capture %u # or ... emacs --apply org-protocol-capture %u Just because of there were a couple of recent threads related to calling conventions for subprotocol handlers, it is better to provide a bit more "real" example emacsclient --eval '(org-protocol-check-filename-for-protocol (pop command-line-args-left) nil nil)' --args %u
Re: Org for non-users, part 2: `C-c C-e', a.k.a. `org-export-dispatch'
Eduardo Ochs writes: > a few weeks ago I recorded a video called "Org for non-users" - > link: > > http://angg.twu.net/2021-org-for-non-users.html Also, feel free to read commentary inside source code. There are a number of common concepts described in the top comments in the core Org files, including org-element.el. > that was about a way to understand some of the data structures that > are used in the support for code blocks. Now I would like to do > something similar with the exporter, but I am stuck at the first > step... When I run `M-x org-export-dispatch' or `C-c C-e' it creates a > second window whose mode line says "*Org Export Dispatcher*" - > > My first question is: > > What are the recommended ways to abort org-export-dispatch without > letting it destroy the "*Org Export Dispatcher*" window and its > buffer? You cannot. That window acts similarly to transient, but simpler. You can think of *Org Export Disipatcher* as an extended help for read-char-exclusive. Best, Ihor
Re: Conversion to Jupyter notebooks
I use ox-ipynb pretty regularly to make lecture notebooks. It isn't quite like most exporters, e.g. it doesn't support all kinds of links to sections, There is support for making different versions of the notebooks though, e.g. with/without solutions, or without sections that are just for you. That should all be described in the commentary in the library. John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Mon, Feb 7, 2022 at 5:14 AM Joost Kremers wrote: > On Mon, 7 Feb 2022, at 10:14, Ihor Radchenko wrote: > > ox-ipynb is being maintained at > > https://github.com/jkitchin/ox-ipynb > > Ah, great! I had somehow missed that... > > > -- > Joost Kremers > Life has its moments > >
Re: [BUG] org-todo (C-c C-t) bad negative prefix behavior [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]
Allen Li writes: > On Sat, Jan 1, 2022 at 9:31 AM Allen Li wrote: > >> It seems like the right fix here is to make - behave the same as -1, and >> raise a user error for any other negative numeric prefix, since it is >> likely not doing whatever the user wanted. >> > > Attached a small patch fixing this, which I tested manually. The patch looks reasonable. Marking the message as a patch to make it appear in https://updates.orgmode.org/ Best, Ihor
Re: [PATCH] org-list-send-item: allow dest to be a buffer position
Sacha Chua writes: > Ihor Radchenko writes: > >>> Passing an integer representing a buffer position to org-list-send-item >>> was failing because of the string-match-p, so here's something that lets >>> integers skip that part. I have copyright assignment papers on file. >> LGTM! Would you mind supplying a test for this function? > > Sure! Here's the new patch that includes the change and tests for the > different kinds of input accepted by org-list-send-item. Thanks! Pushed to bugfix as c5ceb6a2c. Best, Ihor
Re: Shell SRC blocks under Windows
On Sun, 06 Feb 2022 12:51:49 -0500 H. Dieter Wilhelm wrote > Matt writes: > > > On Sat, 05 Feb 2022 17:22:29 -0500 Matt wrote > > > > > > > > But I'm not sure if I'm halfway there with "sh"? I need to run the > > > > following MSYS2 command AND switch between two arguments (for > > building > > > > Emacs). > > > > > > > > \MSYS2\msys2_shell.cmd -mingw64 > > > > > > > > and > > > > > > > > \MSYS2\msys2_shell.cmd -msys. > > > > > > > > How could I achieve this within a src block? > > > > > > I'm not sure I follow you here. Can you please describe what > > > you're trying to do and the system you're using (e.g. Windows, > > > GNU/Linux, Haiku) as well the shell used to run the Emacs instance > > > you're doing this in? > > > > > Excuse me. Obviously you're using Windows. :) > > Yes I have to, but please don't mind, thank you for your interest. :-) > I don't mind. I had asked about the system to help troubleshoot yet that info was clearly given in the thread title. :) You said you weren't sure if you're halfway there with "sh". Is that feeling resolved for you?
[RFC PATCH 1/2] org-babel-tangle-single-block: Do not create comment link when not requested
* lisp/ob-tangle.el (org-babel-tangle-single-block): Do not spend extra time creating link to source block when :comments is set to "no". --- lisp/ob-tangle.el | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el index 7ae319d4f..85356d537 100644 --- a/lisp/ob-tangle.el +++ b/lisp/ob-tangle.el @@ -472,16 +472,20 @@ (defun org-babel-tangle-single-block (block-counter only-this-block) (extra (nth 3 info)) (coderef (nth 6 info)) (cref-regexp (org-src-coderef-regexp coderef)) -(link (let* ( - ;; The created link is transient. Using ID is - ;; not necessary, but could have side-effects if - ;; used. An ID property may be added to - ;; existing entries thus creatin unexpected file - ;; modifications. - (org-id-link-to-org-use-id nil) - (l (org-no-properties (org-store-link nil - (and (string-match org-link-bracket-re l) - (match-string 1 l +(link (if (string= "no" (cdr (assq :comments params))) "" + (let* ( +;; The created link is transient. Using ID is +;; not necessary, but could have side-effects if +;; used. An ID property may be added to +;; existing entries thus creating unexpected +;; file modifications. +(org-id-link-to-org-use-id nil) +(l (org-no-properties +(cl-letf (((symbol-function 'org-store-link-functions) + (lambda () nil))) + (org-store-link nil) + (and (string-match org-link-bracket-re l) +(match-string 1 l) (source-name (or (nth 4 info) (format "%s:%d" -- 2.34.1
[RFC PATCH 2/2] org-babel-expand-noweb-references: Cache block info
* lisp/ob-core.el (org-babel-expand-noweb-references--cache): (org-babel-expand-noweb-references--cache-buffer): New variables storing info cache. (org-babel-expand-noweb-references): Make use of global info cache to avoid extra parsing. Use `cl-macrolet' instead of defining transient lambda functions on every call. --- lisp/ob-core.el | 225 +++- 1 file changed, 127 insertions(+), 98 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 239a57f96..e767fd107 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -2790,6 +2790,10 @@ (defun org-babel-noweb-p (params context) (cl-some (lambda (v) (member v allowed-values)) (split-string (or (cdr (assq :noweb params)) "") +(defvar org-babel-expand-noweb-references--cache nil + "Noweb reference cache used during expansion.") +(defvar org-babel-expand-noweb-references--cache-buffer nil + "Cons of (buffer . modified-tick) cached by `org-babel-expand-noweb-references--cache'.") (defun org-babel-expand-noweb-references ( info parent-buffer) "Expand Noweb references in the body of the current source code block. @@ -2827,104 +2831,129 @@ (defun org-babel-expand-noweb-references ( info parent-buffer) (comment (string= "noweb" (cdr (assq :comments (nth 2 info) (noweb-re (format "\\(.*?\\)\\(%s\\)" (with-current-buffer parent-buffer -(org-babel-noweb-wrap -(cache nil) -(c-wrap - (lambda (s) - ;; Comment string S, according to LANG mode. Return new - ;; string. - (unless org-babel-tangle-uncomment-comments - (with-temp-buffer - (funcall (org-src-get-lang-mode lang)) - (comment-region (point) - (progn (insert s) (point))) - (org-trim (buffer-string)) -(expand-body - (lambda (i) - ;; Expand body of code represented by block info I. - (let ((b (if (org-babel-noweb-p (nth 2 i) :eval) -(org-babel-expand-noweb-references i) - (nth 1 i - (if (not comment) b - (let ((cs (org-babel-tangle-comment-links i))) - (concat (funcall c-wrap (car cs)) "\n" - b "\n" - (funcall c-wrap (cadr cs -(expand-references - (lambda (ref cache) - (pcase (gethash ref cache) - (`(,last . ,previous) - ;; Ignore separator for last block. - (let ((strings (list (funcall expand-body last -(dolist (i previous) - (let ((parameters (nth 2 i))) -;; Since we're operating in reverse order, first -;; push separator, then body. -(push (or (cdr (assq :noweb-sep parameters)) "\n") - strings) -(push (funcall expand-body i) strings))) -(mapconcat #'identity strings ""))) - ;; Raise an error about missing reference, or return the - ;; empty string. - ((guard (or org-babel-noweb-error-all-langs - (member lang org-babel-noweb-error-langs))) - (error "Cannot resolve %s (see `org-babel-noweb-error-langs')" - (org-babel-noweb-wrap ref))) - (_ "") -(replace-regexp-in-string - noweb-re - (lambda (m) - (with-current-buffer parent-buffer -(save-match-data - (let* ((prefix (match-string 1 m)) - (id (match-string 3 m)) - (evaluate (string-match-p "(.*)" id)) - (expansion - (cond - (evaluate -;; Evaluation can potentially modify the buffer -;; and invalidate the cache: reset it. -(setq cache nil) -(let ((raw (org-babel-ref-resolve id))) - (if (stringp raw) raw (format "%S" raw - ;; Return the contents of headlines literally. - ((org-babel-ref-goto-headline-id id) -(org-babel-ref-headline-body)) - ;; Look for a source block named SOURCE-NAME. If - ;; found, assume it is unique; do not look after - ;; `:noweb-ref' header argument. - ((org-with-point-at 1 - (let ((r (org-babel-named-src-block-regexp-for-name id))) -(and (re-search-forward r nil t) - (not (org-in-commented-heading-p)) - (funcall expand-body - (org-babel-get-src-block-info t)) - ;; Retrieve from the Library of Babel. - ((nth 2
[RFC PATCH 0/2] Make org-babel-tangle usable in after-save-hook on large org buffers
I would like to send an experimental patch improving performance of org-babel-tangle. The patch contains two major changes: 1. org-babel-tangle-single-block will not try to parse LINK to src block when :comments is set to "no" and simple return nil in relevant slot of the parsed src block structure. 2. org-babel-expand-noweb-references cache will be saved between the function calls (reset on buffer edits) Because I am not very familiar with org-babel internals, I would like more knowledgeable people to review the changes and let me know if I overlooked some unexpected side-effects. Also, testing tangle performance on real Org files with many code blocks would be appreciated. On my side, the tangling time has been reduced from >6 sec down to 0.1-0.2 sec (with this patch and org-element-cache combined). Best, Ihor Ihor Radchenko (2): org-babel-tangle-single-block: Do not create comment link when not requested org-babel-expand-noweb-references: Cache block info lisp/ob-core.el | 225 ++ lisp/ob-tangle.el | 24 ++--- 2 files changed, 141 insertions(+), 108 deletions(-) -- 2.34.1
Re: Test failure in test-org-colview
Marco Wahl writes: > Is this just me or does anybody else see these failures with the latest > checkout of main? All the tests are passing on my side when testing using Emacs 26,27,28, and 29 (build 1, x86_64-pc-linux-gnu, cairo version 1.16.0) of 2022-01-29. FYI, more often than not bugs/changes in recent Emacs can break Org tests. At least I remember such thing happening a couple of times within last year. Best, Ihor
Test failure in test-org-colview
Hello! Is this just me or does anybody else see these failures with the latest checkout of main? #v+ make test ... Ran 908 tests, 903 results as expected, 5 unexpected (2022-02-07 12:23:35+0100, 55.200528 sec) 16 expected failures 5 unexpected results: FAILED test-org-colview/columns-move-left "Cannot shift this column further to the right" FAILED test-org-colview/columns-move-right "Cannot shift this column further to the right" FAILED test-org-colview/columns-new consp FAILED test-org-colview/columns-next-allowed-value "Invalid column specification format: nil" FAILED test-org-colview/columns-update "Invalid column specification format: nil" #v- Thanks in advance for checking, -- Marco
Re: Conversion to Jupyter notebooks
On Mon, 7 Feb 2022, at 10:14, Ihor Radchenko wrote: > ox-ipynb is being maintained at > https://github.com/jkitchin/ox-ipynb Ah, great! I had somehow missed that... -- Joost Kremers Life has its moments
Re: Conversion to Jupyter notebooks
"Joost Kremers" writes: > All I could find on the internet was a script by John Kitchin[1] that's from > 2017 and it's apparently not entirely compatible with current Emacs and/or > Org mode, as it throws errors when I try to use it. I'm sure I could fix the > errors, but before I invest the time to do that, I wanted to ask here. ox-ipynb is being maintained at https://github.com/jkitchin/ox-ipynb Best, Ihor
Re: [CLOSED] TEC fixed this problem.
Hi Christopher, "Christopher M. Miles" writes: > Today, I found the Org Agenda sorting strategy problem is fixed by > commit "1b675f0ca84d637a3780cf3590308116e232fcfd". thanks for confirming and thanks to TEC for fixing it! Best, -- Bastien
Conversion to Jupyter notebooks
Hi list, I was wondering if anyone here has experience converting Org files to Jupyter notebooks, keeping the python source blocks as code blocks and correctly identifying the =#+RESULTS:=. Just dropping the results would be fine as well. I realise there are several ways to interact with Jupyter notebooks in Emacs, but that's not really what I'm looking for. I'd like a plain old Org file with source blocks that I can execute within Emacs and I would like to convert that into an .ipynb file that I can share with people that don't use Emacs. All I could find on the internet was a script by John Kitchin[1] that's from 2017 and it's apparently not entirely compatible with current Emacs and/or Org mode, as it throws errors when I try to use it. I'm sure I could fix the errors, but before I invest the time to do that, I wanted to ask here. TIA Joost Footnotes: [1] https://kitchingroup.cheme.cmu.edu/blog/2017/01/21/Exporting-org-mode-to-Jupyter-notebooks/ -- Joost Kremers Life has its moments
