Re: Help me secure some free time for org-mode in 2020
Hi Jorge, thank you very much for the kind words and the donation! -- Bastien
Re: ob-scheme doesn't support :stdin?
I have been thinking for a while that it would be great to have some kind of test system for Babel language implementations. It seems there are lots of possible Babel features, that some languages support and others don't, and it would be good to have more clarity about that situation. Is there already any testing or support matrix along these lines? Best wishes, Neil On Tue, 21 Jan 2020 at 04:07, Vladimir Nikishkin wrote: > I just thought that practically speaking, I no interpreter should > really need stdin, right? > Since everything that is prepended with a shebang: #! interpreter > is at the same time a valid shell script, isn't it? > > сб, 18 янв. 2020 г. в 13:02, Kyle Meyer : > > > > Vladimir Nikishkin writes: > > > > > Is it true that ob-scheme doesn't support :stdin ? > > > > > > I just tried, and doesn't seem to work, although it works with > ob-shell. > > > > > > (This is not a complaint, I just would like to confirm that I > > > understand things correctly.) > > > > Yes, that's true as far as I can tell: > > > > $ git grep :stdin > > lisp/ob-awk.el:;; - :stdin takes an Org data or code block reference, > the value of > > lisp/ob-awk.el: (stdin (let ((stdin (cdr (assq :stdin params > > lisp/ob-sed.el: (stdin (let ((stdin (cdr (assq :stdin params > > lisp/ob-shell.el:(stdin (let ((stdin (cdr (assq :stdin > params > > testing/examples/ob-awk-test.org:#+begin_src awk :stdin genseq > :results silent > > testing/examples/ob-sed-test.org: #+BEGIN_SRC sed :stdin ex1 > > > > So it seems support for :stdin is limited to awk, sed, and shell. > > > > -- > Yours sincerely, Vladimir Nikishkin > >
Re: ob-scheme haunted source code block?
On Fri, 17 Jan 2020 at 12:01, Joost Kremers wrote: > Hi list, > > I've been learning some Scheme recently and decided to use Org > mode and babel so I could document my progress, keep notes, etc. > together with the code I write. I also installed the geiser > package to work with Scheme source files directly. > > This all worked perfectly, until I made the (apparent) mistake of > typing =C-c C-c= on an expression while editing a source code > block. That is, I had pressed =C-c '= in an Org buffer on a source > block and in the editing buffer that popped up, I hit =C-c C-c= > (bound to =geiser-eval-definition=) on a particular function (well > procedure...) definition. > > From that moment on, that particular procedure definition seems > haunted. Whenever I evaluate a source block containing it from > within an Org file, the associated REPL is doomed. It takes about > 30 seconds for the evaluation to complete, during which time Emacs > seems to hang (no CPU activity, just waiting). Any further > interaction with the REPL from that point on, either from other > source blocks in the same file (all source blocks in it use the > same session) or in the REPL buffer directly, causes the same > hang. > > I can `C-g` out of the hang, but this doesn't solve much because > any further interaction causes the same hang. > > Putting the relevant procedure definition in a Scheme source file > and evaluating that (within Emacs, through geiser) is > unproblematic, so the code itself is not to blame. > OK, up to this point I am thinking: this is all quite curious, but presumably not really a big problem, as you surely don't need to use this rather strange workflow... > The weirdest thing about this is that the problem is persistent. I > restarted Emacs and in my desperation even rebooted the computer, > but to no avail. > But this is indeed weird. Are you saying that you can reboot your computer, restart Emacs, open the relevant Org file, evaluate the source block (without any C-c ') and you still see the problem? If so, I wonder if it's a real but intermittent problem in your code that was somehow made more likely by the original workflow, and now you're just being unlucky? > > Does anyone have any idea what might be going on? I rgrepped > through my =.emacs.d= directory to see if the relevant procedure > name turns up anywhere but found nothing. I'm not really sure > where to look beyond that. > > Versions: > > IELM> emacs-version > "26.3" > IELM> org-version > "9.3.1" > > TIA > > Joost > > -- > Joost Kremers > Life has its moments > > Best wishes, Neil
Re: org-mode functional programming library
On Mon, Jan 20, 2020 at 6:48 PM Dwarshuis, Nathan J wrote: > I recently authored an package called "om.el" which is a functional > org-mode API akin to dash.el primarily using org-element. Briefly, it > provides a library of (mostly) pure functions that manipulate the parse > tree generated by org-element.el, and uses this to either edit or query the > buffer with all the advantages of functional programming (eg lack of side > effects, referential transparency, easier testing, etc). The github repo > for om.el is here: https://github.com/ndwarshuis/om.el. > > I'm posting to the mailing list a) for general feedback on this package > and b) because I am wondering if this would be a good package to include > with org-mode itself rather than in another repository such as MELPA. The > code for om.el is tightly integrated with org-element.el and it might make > sense for development between these to be closely intertwined. > > There is also an open submission for this to MELPA and the discussion is > here: https://github.com/melpa/melpa/pull/6623. > Oooo this looks cool. I have a simmering project to have an Evernote like system built on top of org mode and a set of directories where I've done a lot of work like this. I'll have to see if I can work this into that and if I can I'll be sure to open up issues/try to contribute patches etc.
bug report org mode
Hi,
I found following strange behaviour:
with
windwos 10
emacs-version: GNU Emacs 26.3 (build 1, x86_64-mingw32) of 2019-08-29
org-version: 9.3.1-elpaplus
if I use following sequence the coloring of the keywords is not working:
(org-id-update-id-locations)
(setq org-id-link-to-org-use-id t)
(setq org-agenda-deadline-leaders '("!D!" "D%02d: " "D-%02d:
"))
(setq org-agenda-scheduled-leaders '(" " "S%02d: "))
(setq org-todo-keywords
'((type
"TODO(t!)"
"STARTED(s@)"
"WAITING(w@)"
"DELEGATED(g@)"
"MEET(m!)"
"SOMEDAY(s!)"
"PROJECT"
"|"
"DONE(d!)"
"CANCELED(c!)")))
(setq org-todo-keyword-faces
'(
("TODO" :foreground "medium blue" :weight bold)
("MEET" :foreground "deep sky blue" :weight bold)
("STARTED" :foreground "dark orange" :weight bold)
("WAITING" :foreground "red" :weight bold)
("SOMEDAY" :foreground "dark blue" :weight bold)
("DELEGATED" :foreground "dark orange" :weight bold)
("CANCELED" :foreground "forest green" :weight bold)
("PROJECT" :foreground "#088e8e" :weight bold)))
According to my examination the problem is with org-id-update-id-locations.
Removeing that column makes it work again.
If I put that line behind it works also again
`org-next-link' skips links inside PROPERTIES drawer
Hello, I am testing Emacs 28 (Org 9.3) from the Git repository and I have noticed that, compared to version 26.3 (Org 9.1.9), `org-next-link' function is skipping links located inside the PROPERTIES drawer. (I have not tested version 27.) The same does not happen for the links outsize drawers or links inside a drawer other than PROPERTIES one, e.g., LOGBOOK drawer. As an example, consider the Org file between "=" lines below. Set the cursor at the beginning of the file. Then call `org-next-link'. = * Heading :PROPERTIES: :MYLINK: https://orgmode.org/ :END: Another link: https://duckduckgo.com/ = I would expect `org-next-link' to find the link inside the drawer (i.e., https://orgmode.org/) as in version 26.3. Instead, it goes directly to the second link (i.e., https://duckduckgo.com/). Let me know if this is an intentional behavior for newer versions of Org mode. If so, I think it could receive a customization option for this behavior. Bests, Pedro R.M. Júnior
org-contrib: Taskjuggler effort calculated via org instead of TJ3?
Hi, On version 9.3 (9.3-elpaplus @ $HOME/.emacs.d/elpa/org-plus-contrib-20191203/), `ox-taskjuggler' exports the :Effort: property calculated via `org-duration-to-minutes', e.g. 2d get exported as 48.0h instead of the literal 2d. This is unexpected and makes the Taskjuggler export unusable for me in the current form. Is there a rationale for this? Maybe I'm missing something and it's more reasonable to plan in working hours instead of working days. Otherwise, could that behaviour get changed or at least put behind a variable/customize interface? Regards, Benjamin
Bug: org babel plantuml Java parameter is ignored [9.3 (9.3-elpa @ /nix/store/azm93cbq487szgddp5hhi4vp1q9ryyp7-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/)]
Hi guys,
I want to use the plantuml org-babel integration, as seen here:
http://eschulte.github.io/babel-dev/DONE-integrate-plantuml-support.html
I don't have a globally available "java" executable and from the
source
code, it appears there is a ":java" parameter for org-babel to
specify
an executable. Looking at the source code, however, it seems that
this
parameter is never actually used (see org-babel-execute:plantuml
in
ob-plantuml.el). Is this intentional? Since I'm not an elips guru,
maybe
I just overlooked something. It, however, leads to me not being
able to
use plantuml properly on my machine.
Regards
Philipp
Emacs : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+
Version 3.24.12)
Package: Org mode version 9.3 (9.3-elpa @
/nix/store/azm93cbq487szgddp5hhi4vp1q9ryyp7-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-after-todo-state-change-hook '(org-checklist
my/remove-priority-when-task-done)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
org-odt-format-headline-function
'org-odt-format-headline-default-function
org-agenda-files '("~/clouds/syncthing/orgzly/plapadoo.org"
"~/clouds/syncthing/orgzly/projekte.org"
"~/clouds/syncthing/orgzly/todo.org"
"~/plapadoo/switch/todoswitch.org"
"~/clouds/syncthing/orgzly/habits.org"
"~/clouds/syncthing/orgzly/imported.org")
org-ascii-format-inlinetask-function
'org-ascii-format-inlinetask-default
org-reveal-start-hook '(org-decrypt-entry)
org-modules '(org-bbdb org-bibtex org-docview org-gnus org-habit
org-info org-irc org-mhe org-rmail org-w3m)
org-plantuml-jar-path
"/nix/store/35bdahp1qr0sklvzjnla0rmxpfp53mpi-plantuml-1.2019.13/lib/plantuml.jar"
org-super-agenda-mode t
org-clock-persist t
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME
CONTENTS)"]
org-archive-hook '(org-attach-archive-delete-maybe)
org-agenda-use-time-grid nil
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-finalize-hook '(org-recur--highlight-agenda)
org-clock-string-limit 10
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _
CONTENTS)"]
org-babel-pre-tangle-hook '(save-buffer)
org-file-apps '(("\\.pdf::\\([[:digit:]]+\\)\\'"
. org-pdfview-open)
("\\.pdf\\'" . org-pdfview-open) (auto-mode
. emacs)
("\\.mm\\'" . default) ("\\.x?html?\\'"
. default)
("\\.pdf\\'" . default))
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-babel-load-languages '((emacs-lisp . t) (shell . t) (plantuml
. t))
org-export-backends '(ascii html icalendar latex md odt)
org-checklist-export-function 'org-export-as-ascii
org-agenda-span 'fortnight
org-src-lang-modes '(("redis" . redis) ("php" . php)
("arduino" . arduino) ("C" . c) ("C++"
. c++)
("asymptote" . asy) ("bash" . sh)
("beamer" . latex) ("calc" . fundamental)
("cpp" . c++) ("ditaa" . artist)
("dot" . fundamental) ("elisp" . emacs-lisp)
("ocaml" . tuareg) ("screen" . shell-script)
("shell" . sh) ("sqlite" . sql))
org-icalendar-include-todo 'unblocked
org-occur-hook '(org-first-headline-recenter)
org-agenda-mode-hook '(org-recur-agenda-mode)
org-agenda-window-setup 'current-window
org-log-into-drawer t
org-learn-fraction 0.25
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-odt-format-inlinetask-function
'org-odt-format-inlinetask-default-function
org-show-notification-handler "notify-send"
org-babel-tangle-lang-exts '(("stata" . "do") ("tcl" . "tcl")
("vala" . "vala") ("vbnet" . "vb")
("emacs-lisp" . "el") ("elisp"
. "el"))
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-open-link
:export
org-attach-export-link :complete
org-attach-complete-link)
("id" :follow org-id-open)
("message" :follow org-mac-message-open)
("x-dev
Asymptote figure in footnote
Greetings.
This has to be a borderline case, but I need some Asympote-generated
figures in footnotes. The following does not seem to work.
[fn:: src_asy[:filename foo.pdf]{size(8cm,0); draw (unitcircle);}]
Any ideas?
Jarmo
Re: Asymptote figure in footnote
Hello,
Jarmo Hurri writes:
> This has to be a borderline case, but I need some Asympote-generated
> figures in footnotes. The following does not seem to work.
>
> [fn:: src_asy[:filename foo.pdf]{size(8cm,0); draw (unitcircle);}]
The following works here:
[fn:: src_asymptote[:file foo.pdf]{size(8cm,0); draw (unitcircle);}]
Regards,
--
Nicolas Goaziou
Re: Displaying remote images
Hello,
Jack Kamm writes:
> Apologies for the delay on this. I've now got a more complete patch for
> displaying remote images inline. Since downloading many remote images
> could potentially hang Emacs on a slow connection, I've added an option
> to control whether remote images are displayed. I've also added an
> option to cache the remote images by visiting them in Emacs buffers.
Thank you.
> The default behavior is not to display remote images, but to issue a
> message that references the option that controls remote image display.
I think displaying a message in this case can be annoying. It means the
default value is not satisfying for anyone.
> +(defcustom org-display-remote-inline-images 'skip-warn
> + "How to display remote inline images.
> +Possible values of this option are:
> +
> +skip-warn Don't display, and emit a message about it.
> +skip-silent Don't display, and don't warn about it.
> +download-always Always download and display remote images.
> +cache-in-buffer Display remote images, and open them in separate buffers
> for
> + cache'ing. Silently update the image buffer when a file
> + change is detected."
> + :type '(choice
> + (const skip-warn)
> + (const skip-silent)
> + (const download-always)
> + (const cache-in-buffers))
> + :group 'org-appearance)
I suggest to drop the `skip-warn' value altogether, and use
`skip-silent', renamed as `skip', as the default value.
It also needs a :package-version and a :safe keyword.
> +(defun org-inline-image--buffer-unibyte ()
> + (string-make-unibyte (buffer-substring-no-properties
> + (point-min) (point-max
I'm surprised such a function is necessary. In any case, it should be
named `org--inline-image-buffer-unibyte'.
> +(defun org-inline-image--create (file width)
It should be named `org--inline-image-create' or
`org--create-inline-image'.
> + (let* ((remote-p (file-remote-p file))
> + (file-or-data
> + (if remote-p
I suggest to move the `if' within the `pcase' with an initial `guard'.
> + (pcase org-display-remote-inline-images
> + (`download-always (with-temp-buffer (insert-file-contents file)
> +
> (org-inline-image--buffer-unibyte)))
Wouldn't `insert-file-contents-literally' fit the bill instead?
> + (`cache-in-buffers (let ((revert-without-query '(".*")))
> + (with-current-buffer
> + (find-file-noselect file)
> +(org-inline-image--buffer-unibyte
Wouldn't the RAW argument from `find-file-noselect' prevent
`org-inline-image--buffer-unibyte' from being used?
> + (`skip-warn (message
> + (concat "Set `org-display-remote-inline-images'"
> + " to display remote images."))
Use continuation delimiter instead.
> + nil)
> + (`skip-silent nil)
> + (_ (message (concat "Invalid value of "
> + "`org-display-remote-inline-images'"))
Ditto.
Regards,
--
Nicolas Goaziou
Re: [Question] adding document global properties drawer
Hello, stardiviner writes: > In an *empty* Org file buffer, I press =[C-c C-x p]= to add properties > drawer. It > works fine. But when the Org buffer has nodes already like this: > > #+begin_src org > | > > ,* node 1 > > context > #+end_src > > The "|" means the cursor point. > > Then I press =[C-c C-x p]= again try to add document global properties > drawer, It > insert nothing. No modification on buffer at all. Is this a bug? FWIW, I could not reproduce it. Regards, -- Nicolas Goaziou
Re: Asymptote figure in footnote
Nicolas Goaziou writes:
>> This has to be a borderline case, but I need some Asympote-generated
>> figures in footnotes. The following does not seem to work.
>>
>> [fn:: src_asy[:filename foo.pdf]{size(8cm,0); draw (unitcircle);}]
>
> The following works here:
>
> [fn:: src_asymptote[:file foo.pdf]{size(8cm,0); draw (unitcircle);}]
Thank you and sorry.
That was pathetic, but it has been a long day. And continues.
Do you have an idea of how to control the size of the pic in the
footnote? The default is .9\linewidth. I figured a workaround (below),
but would prefer the structure above.
The workaround is to produce the asy image with a regular src block,
exporting nothing, and then using inline latex in footnote as follows:
[fn:: @@latex:\includegraphics[width.3\linewidth]{sine-curve-a.pdf}@@]
And, once again, I am amazed by Org's capabilities! :D
Jarmo
isearch misses stuff (was: `org-next-link' skips links inside PROPERTIES drawer)
hi, On 1/20/20, Kyle Meyer wrote: >> is isearch intended to be also affected? or just org-next-link? i > > No, isearch isn't affected. thanks, that's a relief. then we have a "your life in plain text" (i.e. matches everything) search inside emacs that will also work with multi-buffer isearch etc. > Here are two options: > > * Set search-invisible to t. (The default value of `open' won't allow > you to match links.) i tried t, and it stopped at links without opening them. i'd prefer it open them, but it is good that it matched them. however, it made org entries not open during isearch. so i don't think this will work. the docstring says you can make things open by adding an overlay property. i'm not sure what those are. could this possibly allow isearch to find links while still opening org entries? > * Make the links visible with org-toggle-link-display before > searching. i don't think i would remember to do this, so i would have to defadvice isearch to do this before searching an org buffer, and then turn it off after, or something like that? if i got it to work, i'd wonder if it would work with multi-isearch.
Re: Asymptote figure in footnote
Hello, Jarmo Hurri writes: > Do you have an idea of how to control the size of the pic in the > footnote? The default is .9\linewidth. I figured a workaround (below), > but would prefer the structure above. I don't know how to do that in an inline footnote, but, in this case, I would certainly use a regular footnote containing an Asymptote source block. Regards, -- Nicolas Goaziou
Re: org-contrib: Taskjuggler effort calculated via org instead of TJ3?
Hello, Benjamin Kästner writes: > On version 9.3 (9.3-elpaplus @ > $HOME/.emacs.d/elpa/org-plus-contrib-20191203/), `ox-taskjuggler' > exports the :Effort: property calculated via > `org-duration-to-minutes', e.g. 2d get exported as 48.0h instead of > the literal 2d. > > This is unexpected and makes the Taskjuggler export unusable for me in > the current form. Is there a rationale for this? I don't know. I removed the transformation. Thank you for the report. Regards, -- Nicolas Goaziou
Re: org-contrib: Taskjuggler effort calculated via org instead of TJ3?
Benjamin Kästner writes: > Hi, > > On version 9.3 (9.3-elpaplus @ > $HOME/.emacs.d/elpa/org-plus-contrib-20191203/), `ox-taskjuggler' > exports the :Effort: property calculated via > `org-duration-to-minutes', e.g. 2d get exported as 48.0h instead of > the literal 2d. > > This is unexpected and makes the Taskjuggler export unusable for me in > the current form. Is there a rationale for this? Maybe I'm missing > something and it's more reasonable to plan in working hours instead of > working days. Otherwise, could that behaviour get changed or at least > put behind a variable/customize interface? > > Regards, > Benjamin >From memory, I seem to recall that this had something to do with the ambiguous understanding of what 2d really meant i.e. 48 hours, 16 hours (assuming 8 hour work day). I have no opinion regarding which is better, but I don't use taskjuggler any more (due to other 'limitations' with the export/configuration which I just cannot recall now - it was many years ago). Tim -- Tim Cross
Re: [RFC PATCH] Changes to pop-up source buffers
> I suppose that to some degree [*] the main benefit of this patch is that > it offers an option that calls quit-restore-window. Yes, I agree with this. Setting org-src-window-setup to other-window was almost good enough for me -- it even respected display-buffer-base-action -- except that it wouldn't close the popped up window. > And that makes me think that the current options that go through a > simple display-buffer-based call (current-window and other-window) would > benefit from calling quit-restore-window like your `plain` option does. > If you agree, perhaps it's worth adding another patch on top that does > that. I agree other-window would benefit from quit-restore-window, it makes sense to close the existing window if it's been popped up. I'm less sure about current-window. We could certainly call quit-restore-window here, but I'm not sure there's any benefit, as it shouldn't open new windows that need to be closed (unless you're modifying display-buffer-alist, in which case the `plain' option should be preferred anyways). I'm also hesitant because Samuel relies on this option for accessibility reasons, and if I accidentally introduced a bug, I might not immediately notice, since I don't use this option. I've attached a patch on top of my previous one, calling quit-restore-window when using other-window, but leaving current-window alone. > Hmm, weird. I tried again (Emacs 26.3, vanilla config) and still see > the behavior I reported. Oh well. I tested again, with "emacs -q" this time, and got the behavior you reported. So it must be something with my config. >From 0db0adc4f20d8c664976b89cbe033f5579e1fdc5 Mon Sep 17 00:00:00 2001 From: Jack Kamm Date: Tue, 21 Jan 2020 20:39:14 -0800 Subject: [PATCH] org-src: Add call to quit-restore-window in org-src-switch-to-buffer * lisp/org-src.el (org-src-switch-to-buffer): Add call to quit-restore-window in org-src-switch-to-buffer when org-src-window-setup is other-window --- lisp/org-src.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lisp/org-src.el b/lisp/org-src.el index 52e99cf04..bb1c57c65 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -809,7 +809,9 @@ Raise an error when current buffer is not a source editing buffer." (pop-to-buffer buffer)) (`current-window (pop-to-buffer-same-window buffer)) (`other-window - (switch-to-buffer-other-window buffer)) + (let ((cur-win (selected-window))) + (switch-to-buffer-other-window buffer) + (when (eq context 'exit) (quit-restore-window cur-win (`split-window-below (if (eq context 'exit) (delete-window) -- 2.25.0
