Re: Survey: changing a few default settings for Org 9.4
> > > However, hiding emphasis and macro markers can make editing text at > > the boundaries of emphasized text non-intuitive, which I can imagine > > might frustrate some new users, so that should probably be carefully > > considered. > +1e6 > Interestingly, hiding emphasis and macro markers are the two changes > that get the *less* votes, so we probably won't change these. > Thank you! Hiding those will somehow take away the "Org-ness" in my humble opinion :)
[SOLVED] Re: [PATCH] support colorful blocks display on org-agenda
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bastien writes: > stardiviner writes: > >> (add-hook 'org-agenda-finalize-hook #'org-agenda-time-grid-colorful-spacing) > > FWIW I don't think this should go in Org's core, it is a useful > command to customize Org agenda colors. > > Can you suggest the author to add this to > https://orgmode.org/worg/org-hacks.html ? Pushed to Worg now. Done. :) - -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl5OpxsUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsPSSAf+M7hw6Q+Id9o5NOEFSYzT6J89sezp jEenA69/ejthXXgVJjfYw+urfVkM2akD7UvxYhQ/yqKwgEI5gFg8DifF2/w2HSqF AIMdUro7LLcWXkOO/Xj3mHmUMex/zmcZZruqJy6oEgc8xLRVhEFf3dbMIUcrn6qv gNWmxHlmlMRrL/l4IG1PxQHP7Db4EV5Uw2zsnVuOUXBGRhyPaHcgFnFeg6lihDZi TfjI70T+6Sx4urGvzwwZcdggYB7Pc24PaTcXvTgKEFnzhzwGAA4xoziqZk3BhLns D4ZYdvHReugK+OyMfcPpFDcYxw+jUf7yhMCd7bd47gMWLChwtL/1JhMwcQ== =cG4k -END PGP SIGNATURE-
Re: ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
* Bastien wrote: > Hi Karl, Hi, > another suggestion: just send us a minimal extract of your files so > that we see how org-depend is called, together with what you do and > what goes wrong when you do it. Perhaps this will lead to something. Sure. https://github.com/novoid/dot-emacs/blob/master/config.org contains: | (setq my-user-emacs-directory "~/.emacs.d/") | (use-package org-depend | :load-path (lambda () (expand-file-name (concat my-user-emacs-directory "contrib/org-mode/contrib/lisp/"))) | ) ... which loads org-depend from my maint Org mode (currently: 9.3 (release_9.3-102-gd20e45.dirty @ mixed installation![...]). I only use org-depend for: * TODO Example 1 :PROPERTIES: :ID: 2020-02-20-foo :END: * TODO Example 2 :PROPERTIES: :BLOCKER: 2020-02-20-foo :END: Very rarely, I am using: * TODO Example 3 :PROPERTIES: :TRIGGER: 2020-02-20-foo :END: Most of the time, source-destination are within the same file. However, in some cases of using BLOCKER, the two headings might be in two different files. That's basically it: mostly BLOCKER and a few TRIGGER. I'm unsure if there is currently a TRIGGER that is still waiting to be activated. (By the way: is there a built-in feature to look for IDs that are linked somewhere (BLOCKER properties or ID links) that are broken?) Ad "what goes wrong when you do it": in my daily work, org-depend is working fine. The only thing that does not work is exporting my agenda with: | emacs --batch --load /home/vk/.emacs.d/init.el --eval '(progn (my-export-agenda))' and: | (defun my-export-agenda() |"Exports Org-mode agenda to ics file" |(interactive) |(save-some-buffers) | |;; I don't want the error messages in my exported agenda: |(setq org-agenda-files (remove "~/org/errors.org" org-agenda-files)) | |(setq max-specpdl-size 1) ;; does not solve issue |(setq max-lisp-eval-depth 5) ;; does not solve issue | |(org-agenda-list nil nil 60) |(org-agenda-write (concat my-user-emacs-directory "var/export/agenda-export.ics")) |) With disabled org-depend, it is working and finishes in ~5 minutes. With enabled org-depend it (sometimes) end up in an error as described. This can take hours. > I've never used org-edna, I'm curious to know if there are many users. Me too ;-) It's a bit more complicated in syntax but has advanced features org-depend does not offer. The main reason why I'm thinking of switching is that org-edna supports something like TRIGGER that also adds relative SCHEDULED date-stamps. This allows for "if $THAT task gets done, mark $NEXT task as a TODO item and add a SCHEDULED with three days in the future" which is very handy in some cases. > Thanks, Oh, it's me, who is very thankful, considering the tricky situation to investigate this issue. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: [SOLVED] Re: [PATCH] support colorful blocks display on org-agenda
stardiviner writes: >> Can you suggest the author to add this to >> https://orgmode.org/worg/org-hacks.html ? > > Pushed to Worg now. Done. :) Thanks! -- Bastien
How to display overlay or propertize text on file: link type about the file?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I have a requirement, I want to display file: link's file type info on the link. For example, an Org file: link #+begin_src org [[file:~/Org/logo.png][logo]] [[file:~/Org/document.pdf][document]] [[file:~/Org/book.epub][book]] #+end_src I want to display link as: #+begin_src org logo (image: png) document (document: pdf) book (ebook: epub) #+end_src I'm inspired by this code snippet: #+begin_src emacs-lisp (org-link-set-parameters "file+sys" :complete 'org-file-complete-link :face (lambda (path) (if (file-exists-p path) 'org-link 'org-warning))) #+end_src Is it possible to display those info between parentheses with an overlay or propertied text? If someone have any idea or how to implement this, please help me. Thanks in advanced. - -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl5OrLYUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsPElQf/W71U1JQ9ZeFjCWCxICs0q87016Iq 8FQ5Fr3lSmRb6NRLqzqAAbY6b14roxtixxmllvArJgd7bz280xTZs3NGgYMm/HMf sZ+vtkpiHgJk31KXxAk/LT1OcgzYOrSv7g6c8Y3Gg8G5eSDmKGu+tMwqFzYtVmk2 6G0/wz9ezsdYAFLlNrX/FhcVaxCUSSdG08z0Ip/Op1I4iqh3Y86N7LalPVZWNa9H eZSFsf3Z8NqfVnCmTvmyJon4x1SGvJ8Iaf4QUiE7huNeizJK2+CSIhjSu8yDBGr4 2oMPrkAm1XkJDLMQh0FLjIrIJUoTLzLonEYtlmg3thvFEMqFuF8ziYaGdw== =sZhk -END PGP SIGNATURE-
Make ob-python.el support ":results pp" pretty print result
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I found ob-python does not support ":results pp" pretty print result. And Python has a module "pprint". What about add support this? - -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl5Oqu4UHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsM3gQgAn8oTYDwb1SvETMrOsOyfFnzXrbr1 i77t376xloPALkNUnmMj3myU7g13yKgYS04O5Lngki/Pb1jeQqFcua8BP76UDPJ/ V+u9VQGQ4CbBVoPD+fpsSri3hEpmSq/pw8SWGxXUoBbffozc7weDBqwvdwGdovuS 8UbbrQ9GVSKQkYGC2bW9/P7459urSzAUVuH838bq8ACGdWF4fEqSribVkx9EJyui kqDunu5c0EMCefN7q1Ydor7cjZEwWdb2NZ4IO2HTQac2V4B+R+1YQBHF+kgHgT6S r+9Ol62Tk5L6GqJLgzRGOPl0JvBuFLa6O1jyzYrowpWVty6w6C0cwO9JMQ== =+RhY -END PGP SIGNATURE-
[PATCH] support change ob-php.el default PHP command and specifying command options
I first created a very simple ob-php.el because it does not exist in Org Mode. But it's really just a very simple code. Now a friend of mine is using it, I wish to improve it. Seems current ob-php.el does not support some cases like PHP code "include ". Current patch is a more flexible solution. Might provide some freedom for user to adopt. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 From b158232fdc418437aebe2baacabeef289e0537c3 Mon Sep 17 00:00:00 2001 From: stardiviner Date: Thu, 20 Feb 2020 23:14:15 +0800 Subject: [PATCH] contrib/lisp/ob-php.el: Support change evaluate command specify options. * contrib/lisp/ob-php.el (org-babel-php-command): Add new customizable option `org-babel-php-command` to change default command. * contrib/lisp/ob-php.el (org-babel-php-command-options): Add new customizable option `org-babel-php-command-options` to specify command options. * contrib/lisp/ob-php.el (org-babel-execute:php): Use new commands in execute function. --- contrib/lisp/ob-php.el | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/contrib/lisp/ob-php.el b/contrib/lisp/ob-php.el index 1befbd248..43aede26c 100644 --- a/contrib/lisp/ob-php.el +++ b/contrib/lisp/ob-php.el @@ -21,6 +21,16 @@ (defgroup ob-php nil "org-mode blocks for PHP." :group 'org) +(defcustom org-babel-php-command "php" + "The command to execute babel body code." + :group 'ob-php + :type 'string) + +(defcustom org-babel-php-command-options nil + "The php command options to use when execute code." + :group 'ob-php + :type 'string) + (defcustom ob-php:inf-php-buffer "*php*" "Default PHP inferior buffer." :group 'ob-php @@ -29,10 +39,9 @@ (defcustom ob-php:inf-php-buffer "*php*" ;;;###autoload (defun org-babel-execute:php (body params) "Orgmode Babel PHP evaluate function for `BODY' with `PARAMS'." - (let* ((cmd "php") + (let* ((cmd (concat org-babel-php-command " " org-babel-php-command-options)) (body (concat ""))) -(org-babel-eval cmd body) -)) +(org-babel-eval cmd body))) ;;;###autoload (eval-after-load "org" -- 2.25.0 signature.asc Description: PGP signature
Re: [PATCH] Fix ob-python.el initiate session error with py-shell
, On 20.02.20 06:45, stardiviner wrote: Hi, python-mode.el developer here. Since python.el is built-in to Emacs, I think that things should continue to work for python-mode.el users, even if we entirely switch over to only using python.el. Thanks supporting python-mode.el. Both python-modes should not conflict - except for the key-setting, which is taken by the last one loaded: py-mode-map didn't work for some reasons, so both provide now python-mode-map. The only thing I'm not sure about, is whether the equivalent of "python-shell-send-region" in python-mode.el will work with shells started by python.el. If not, this could probably be addressed with a patch to python-mode.el. It should work. Will check it. Please feel free to send a bug-report resp. feature request to https://gitlab.com/python-mode-devs/python-mode/issues in case of python-mode.el related stuff. You could test this by explicitly setting `org-babel-python-mode' to `python' (it is probably set to `python-mode' on your system, which is the default when python-mode.el is detected). I'll add a TODO for myself to explicitly mark python-mode-related variables as deprecated. I'm also planning a major update to the Worg documentation of ob-python when 9.4 comes out, and will mention the deprecation there as well. Thanks for your work! Jack - -- [ stardiviner ] BTW there are some reasons, why python-mode.el still exists: no known indentation bugs, finer navigation commands etc. Maybe have a look at open python.el bugs and check them against python-mode.el Best, Andreas
Re: [PATCH] support colorful blocks display on org-agenda
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bastien writes: > Hi Stardiviner, > > stardiviner writes: > >> I reconsidered this patch, what about make it an minor-mode for Org >> Mode and put it in contrib/ directory? WDYT? > > I suggest using worg/org-hacks.org instead: this describes precisely > what it is, a nice hack, isn't it? > > Days for the "contrib/" directory are counted: before Org 9.5, I will > extract it from Org's repository, make it an independant repository on > code.orgmode.org and make it available through Org ELPA. > > So you'd better not add things there. > > Thanks, Alright, I at least did tried. :) Hehe - -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl5OowQUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsOgogf/S9vhApnOUloiYIfAWMAmZQ8R2184 KS3a2JuOlfLGDMMr9Pr00f+7pOK0iVmlWchKC+bqzhHoq7GBCnbclk0GhH51WcEA Bd96/7l54eAvqiSSraA/c/80kb+e8RXTXsSTTHuUFkOXMAYuip7qkHLSofyHhKV5 9cBitAAnThxLwCjqdHBLwo1A/6lQ3t9H81MJoam7FZRWyCEniJ2R2icuIdEG+Pfb co0q9py0ts3meGmR4ANvhAi7perIbTIvdu64Nbjnhgnh97WNWmU1L9qcJhROw/It zpE1ILLBu4A47XGx40v2McITvh6NCY1bw3ZXIsc6XK4L/Ow6RyCvzQCYog== =iUPw -END PGP SIGNATURE-
Re: Make ob-python.el support ":results pp" pretty print result
Hi stardiviner, stardiviner writes: > I found ob-python does not support ":results pp" pretty print result. And > Python > has a module "pprint". What about add support this? Well, there is code in ob-python.el that uses the pprint module when ":results pp", but I must admit I've never used it and don't know whether it is currently working. I'm also unsure there's a difference in how session and non-session blocks deal with this. I'll plan to test it out later this weekend or next week and see if I can fix any issues. Or, if you're able, please feel free to submit a patch (but please let me know if you plan to work on this, so we can avoid duplicating effort). Ideally, a patch for this would also include a unit test, to make sure this doesn't break in future.
Re: Possible to exclude/include tags for agenda custom commands?
Eric Abrahamsen writes: > Bastien writes: > >> Hi Eric, >> >> Eric Abrahamsen writes: >> >>> In my current Org, version 9.3.6-elpaplus, I need a "+" in front of a >>> select tag, ie the "MAYBE" above needs to be "+MAYBE", otherwise nothing >>> is selected at all. >> >> FWIW yes, this should be "+MAYBE". > > Thanks for confirming! I'll also note that, while this works perfectly well, every time I refresh my custom agenda I see: Making org-agenda-tag-filter buffer-local while locally let-bound! Maybe there's still some work to be done here?
Re: Possible to exclude/include tags for agenda custom commands?
Bastien writes: > Hi Eric, > > Eric Abrahamsen writes: > >> In my current Org, version 9.3.6-elpaplus, I need a "+" in front of a >> select tag, ie the "MAYBE" above needs to be "+MAYBE", otherwise nothing >> is selected at all. > > FWIW yes, this should be "+MAYBE". Thanks for confirming!
Re: [PATCH] Fix ob-python.el initiate session error with py-shell
Hi, Bastien writes: > Also, for included ob-*, the idea would be to use the mode that are > bundled with Emacs core. For Python, it would mean that ob-python.el > should support python.el, not python-mode.el. I agree that ob-python.el should only rely on functionality from python.el, and shouldn't need to know about other packages. This will reduce the maintenance burden for ourselves. At the same time, I would like the user to use whatever Python-related modes they like when editing the org Python source buffer, such as python-mode.el, elpy, etc., without issue. That doesn't mean that we'll put workarounds and references to external packages in ob-python.el, but rather that we'd keep ob-python simple and easy for external packages to interop with. I think this is more or less the case today, and we're on the same page here. Just wanted to make this goal explicit.
Re: Possible to exclude/include tags for agenda custom commands?
Bastien writes:
> Hi Eric,
>
> Eric Abrahamsen writes:
>
>> I'll also note that, while this works perfectly well, every time I
>> refresh my custom agenda I see:
>>
>> Making org-agenda-tag-filter buffer-local while locally let-bound!
>
> Can you send enough information so that we can reproduce the problem?
Yes, that wasn't a very helpful report, was it?
First of all, here's the custom command I'm using, to organize an
upcoming trip to New York:
("n" "New York Feb 2020"
((tags-todo "nyfeb2020")
(agenda "is this string meaningless?"
((org-agenda-start-day "2020-02-25")
(org-agenda-span 15
((org-agenda-tag-filter '("+nyfeb2020"
I edebug `org-agenda-redo', and hit "g". In this function,
`org-agenda-tag-filter' is nil. I don't know if it's supposed to be or
not, but it is.
The error arises out of `org-agenda-run-series', so we go there, and
find it comes from `org-let':
(let ((org-agenda-tag-filter '("+nyfeb2020")))
(org-agenda-prepare name))
`org-agenda-run-series' gets called twice every time I update the
agenda; the error only arises from the first time. The
`org-agenda-tag-filter' variable is buffer-local to my custom agenda,
which is why Emacs complains that it's being let-bound. I don't see
where `org-agenda-tag-filter' is made buffer-local.
I hope that helps!
Eric
Re: [PATCH] Fix ob-python.el initiate session error with py-shell
Hi all, in future releases of Org, we will move toward stricter rules on what to accept as ob-* libraries and what modes these libraries should rely upon. This was briefly mentioned in this email: https://lists.gnu.org/archive/html/emacs-orgmode/2020-02/msg00714.html For example, we can have a rule that we don't include ob-* libraries for languages that are not somehow known by Emacs. It would mean that e.g. ob-clojure.el would have to live outside Org's core. Also, for included ob-*, the idea would be to use the mode that are bundled with Emacs core. For Python, it would mean that ob-python.el should support python.el, not python-mode.el. This is not to say that python.el is better than python-mode.el: I have no opinion on this and I'm confident both meet different users. But that's something to consider. We can always have another ob-python-mode.el file for users who use python-mode.el: even the names would make it clear that Org babel uses one mode and not the other. I suggest we have the discussion on such rules after Org 9.4, but in the meantime, this is something you may consider when fixing hacking on ob-python.el. Best, -- Bastien
Re: Feature request: shared radio targets with archive files
Hi Karl, Karl Voit writes: > Can somebody estimate on the effort and potential negative > implications (performance, caching issues, ...) when this feature > would be extended, so that radio targets of foo.org also work[2] in > foo.org_archive and vice versa? Radio targets only work within the same file. Just like HTML anchor links: voila. Allowing a radio target to be reached outside the current file would lead to blur the distinction between radio targets and... links. That said, you can write your own function, taking inspiration from org-link--search-radio-target and adding it to org-open-link-functions, where your function searches the target outside of the current buffer. Not sure, of course, whether this is trivial or not :) HTH, -- Bastien
Re: Possible to exclude/include tags for agenda custom commands?
Stig Brautaset writes:
> Hi Bastien,
>
> Bastien writes:
>>> I can easily do this in the list of TODOs, with a tag search. However, I
>>> haven't figured out how to do this for the agenda. Is it possible? If
>>> so, how?
>>
>> From what I understand, check `org-agenda-tag-filter' to see how to
>> use it within an agenda custom command.
>
> Thank you! That did indeed do it.
Coincidentally, I was just trying to figure this problem out, so this
snippet is helpful. It's weird, because I'm almost certain I've done
this before, but couldn't remember how.
> FWIW my stanza looks like this now:
>
> (setq org-agenda-custom-commands
> '(("w" "Work Agenda"
> ((agenda "" ((org-agenda-span 'day)))
> (todo "TODO"
>((org-agenda-max-entries 5)
> (org-agenda-todo-ignore-scheduled 'all)
> (org-agenda-todo-ignore-deadlines 'all)
> (org-agenda-todo-ignore-timestamp 'all
> ((org-agenda-tag-filter '("-@home" "-MAYBE"
>("h" "Home Agenda"
> ((agenda "")
> (todo "TODO"
>((org-agenda-max-entries 5)
> (org-agenda-todo-ignore-scheduled 'all)
> (org-agenda-todo-ignore-deadlines 'all)
> (org-agenda-todo-ignore-timestamp 'all
> ((org-agenda-tag-filter '("-@work" "-MAYBE"
>("m" "Maybe"
> ((todo "PROJ")
> (tags-todo "-PROJ/TODO"))
> ((org-agenda-tag-filter '("MAYBE"
>("P" "Projects" tags-todo "-MAYBE/PROJ"
In my current Org, version 9.3.6-elpaplus, I need a "+" in front of a
select tag, ie the "MAYBE" above needs to be "+MAYBE", otherwise nothing
is selected at all. If this is how it's meant to be, maybe we could
amend this example?
Thanks!
Eric
Re: Possible to exclude/include tags for agenda custom commands?
Hi Eric, Eric Abrahamsen writes: > I'll also note that, while this works perfectly well, every time I > refresh my custom agenda I see: > > Making org-agenda-tag-filter buffer-local while locally let-bound! Can you send enough information so that we can reproduce the problem? Thanks! -- Bastien
Re: [PATCH] Fix ob-python.el initiate session error with py-shell
Hi Jack, Jack Kamm writes: > I think this is more or less the case today, and we're on the same page > here. Just wanted to make this goal explicit. OK, thanks for the precision! -- Bastien
Re: Possible to exclude/include tags for agenda custom commands?
Hi Eric, Eric Abrahamsen writes: > In my current Org, version 9.3.6-elpaplus, I need a "+" in front of a > select tag, ie the "MAYBE" above needs to be "+MAYBE", otherwise nothing > is selected at all. FWIW yes, this should be "+MAYBE". -- Bastien
Re: [PATCH] support change ob-php.el default PHP command and specifying command options
Hi Stardiviner, stardiviner writes: > I first created a very simple ob-php.el because it does not exist in Org Mode. > But it's really just a very simple code. Now a friend of mine is using it, I > wish to improve it. Seems current ob-php.el does not support some cases like > PHP > code "include ". > > Current patch is a more flexible solution. Might provide some > freedom for user to adopt. Applied, thanks. -- Bastien
Feature request: shared radio targets with archive files
Hi! Only recently, I found radio targets[1] very handy to implement a glossary within an Org file. This way, any instance of "PIM" can be linked to one single definition of "- <<>> :: Personal Information Management" for example. My question (and feature request): Can somebody estimate on the effort and potential negative implications (performance, caching issues, ...) when this feature would be extended, so that radio targets of foo.org also work[2] in foo.org_archive and vice versa? I often have the use-case that I wrote down some definitions as sub-heading to a task. Its related radio target gets a broken one as soon as I archive the associated and finished task heading. Example: ** Reading a paper on keyboards This is highly relevant to PIM research. [...] ** DONE Reading a paper about notebooks *** Notes on the paper about notebooks - <<>> :: Personal Information Management - mentioned in the research chapter - <<>> :: Another common mediocre example - rings a bell somehow The first PIM instance is highlighted and linked to its definition below. As soon as the DONE task gets archived, the first PIM instance is no longer linked to its definition since the related target got moved to the archive. Of course, *all* instances within the archive file are unlinked to their definition targets in the non-archive file as well. The example works both ways. Thanks for your ideas [1] https://orgmode.org/manual/Radio-Targets.html [2] as in: "links in both files get highlighted" and "all links can be followed to their target" -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
Hi Karl, Karl Voit writes: > With disabled org-depend, it is working and finishes in ~5 minutes. With > enabled org-depend it (sometimes) end up in an error as described. Do you need org-depend when exporting? If not, I simply suggest to turn org-depend off... or to let-bind `org-trigger-hook' and `org-blocker-hook' to nil in your function. Probably org-depend does a lot of moving back and forth in files to check for IDs, and that may explain the time spend by this command when you export many files. -- Bastien
Re: Bug or not a bug? dot expansion in ob-shell
+1 - this is basically my feeling as well. I've spent the last couple of days thinking about the additional option suggestion, but something just didn't feel right to me. I think Nick has hit the nail on the head. Adding the additional option seems to be making things more confusing. The basic idea that result value is what the block returns i.e. the return value of the last statement for shell blocks and result output is what the code in the block sends to stdout/stderr. This seems the most intuitive to me. Nick Dokos writes: > Hi Bastien, > > Bastien writes: > >> Hi Diego, >> >> Diego Zamboni writes: >> >>> I'm late to the discussion so I apologize in advance, but this fix >>> seems counterintuitive to me. In my mind, for any shell code: >>> >>> - Return value: exit code of the last command >>> - Output: whatever the commands print >> >> Yes, that's what is *now* possible if you set >> ob-shell-return-value-is-exit-status to t. >> >> Unless I miss something, it was not possible before today. >> >> #+begin_src shell >> echo Hello! >> #+end_src >> >> would simply return "Hello!" as a return. >> >> No exit code was *never* output. >> >>> So to me, it's intuitive that =:exports value= would return the exit >>> code of the last command, and =:exports output= would produce the >>> output of the commands. I don't understand why a new option is >>> needed. >> >> ... because it was not the case before. Or maybe *I* miss something. >> >> Can you show me something that was working before and that is not >> anymore? >> >> Thanks, > > I welcome the fix but not the option: the option situation in Org mode > was pretty horrible, then ca 2010, you did a survey and some options > were eliminated (not sure about the year or whether it *was* you who > did the survey, but I'm pretty sure there was one): that was the right > direction to go, but it wasn't enough. Org mode needs to be put into > an option diet, so adding another one here (and a rather gratuitous > one in my view) is not the way to go. > > `:results value' should *always* produce the value of the last expression, > which for shell programs is the exit status of the last command. > > `:results output' should *always* produce all of the output of the program. > > An argument can be made that `:results value' is the default, but it > is the less useful option for shell programs. So maybe for shell > blocks, make the default to be `:results output' instead: people get > what they always got before the fix without lifting a finger, the exit status > is now available with `:results value', and the option can go away > quietly and quickly, before it becomes another contributor to the Org > mode technical debt. -- Tim Cross
TODO status in a drop-down list of buffers contents
In an imenu drop-down list of a buffers contents, how can I get it to show just the TODO status, and just show the sections title once the TODO is removed, please? Thanks Sharon. -- A taste of linux = http://www.sharons.org.uk TGmeds = http://www.tgmeds.org.uk DrugFacts = https://www.drugfacts.org.uk Debian 10.2, fluxbox 1.3.7, emacs 26.3, org 9.3.6 signature.asc Description: PGP signature
Re: Step by step tutorial on Worg on how to create a new export backend
Bastien writes: > Then, after you commit an edited version of these instructions, maybe > Robert and Marcin can help reviewing and enhancing it to ensure it is > self-sufficient and explicit enough? I have pushed a (ever so) slightly edited version as new file in a branch to worg here: https://code.orgmode.org/bzg/worg/src/org-export-backend-tutorial/org-tutorials/org-export-backend.org Would Robert/Marcin like to take it from here? Stig
Re: Bug or not a bug? dot expansion in ob-shell
Hi Bastien, Bastien writes: > Hi Diego, > > Diego Zamboni writes: > >> I'm late to the discussion so I apologize in advance, but this fix >> seems counterintuitive to me. In my mind, for any shell code: >> >> - Return value: exit code of the last command >> - Output: whatever the commands print > > Yes, that's what is *now* possible if you set > ob-shell-return-value-is-exit-status to t. > > Unless I miss something, it was not possible before today. > > #+begin_src shell > echo Hello! > #+end_src > > would simply return "Hello!" as a return. > > No exit code was *never* output. > >> So to me, it's intuitive that =:exports value= would return the exit >> code of the last command, and =:exports output= would produce the >> output of the commands. I don't understand why a new option is >> needed. > > ... because it was not the case before. Or maybe *I* miss something. > > Can you show me something that was working before and that is not > anymore? > > Thanks, I welcome the fix but not the option: the option situation in Org mode was pretty horrible, then ca 2010, you did a survey and some options were eliminated (not sure about the year or whether it *was* you who did the survey, but I'm pretty sure there was one): that was the right direction to go, but it wasn't enough. Org mode needs to be put into an option diet, so adding another one here (and a rather gratuitous one in my view) is not the way to go. `:results value' should *always* produce the value of the last expression, which for shell programs is the exit status of the last command. `:results output' should *always* produce all of the output of the program. An argument can be made that `:results value' is the default, but it is the less useful option for shell programs. So maybe for shell blocks, make the default to be `:results output' instead: people get what they always got before the fix without lifting a finger, the exit status is now available with `:results value', and the option can go away quietly and quickly, before it becomes another contributor to the Org mode technical debt. -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: Bug or not a bug? dot expansion in ob-shell
+1 - I also think that this is the correct behavior, and that the average user's expectations can be best fulfilled by making ":results output" the default. Adding the option will make it more difficult to share code blocks and documents. Best regards, Derek On Thu, Feb 20 2020, Tim Cross wrote: > +1 - this is basically my feeling as well. I've spent the last couple of > days thinking about the additional option suggestion, but something just > didn't feel right to me. I think Nick has hit the nail on the head. > > Adding the additional option seems to be making things more confusing. > The basic idea that result value is what the block returns i.e. the > return value of the last statement for shell blocks and result output is > what the code in the block sends to stdout/stderr. This seems the most > intuitive to me. > > > Nick Dokos writes: > >> Hi Bastien, >> >> Bastien writes: >> >>> Hi Diego, >>> >>> Diego Zamboni writes: >>> I'm late to the discussion so I apologize in advance, but this fix seems counterintuitive to me. In my mind, for any shell code: - Return value: exit code of the last command - Output: whatever the commands print >>> >>> Yes, that's what is *now* possible if you set >>> ob-shell-return-value-is-exit-status to t. >>> >>> Unless I miss something, it was not possible before today. >>> >>> #+begin_src shell >>> echo Hello! >>> #+end_src >>> >>> would simply return "Hello!" as a return. >>> >>> No exit code was *never* output. >>> So to me, it's intuitive that =:exports value= would return the exit code of the last command, and =:exports output= would produce the output of the commands. I don't understand why a new option is needed. >>> >>> ... because it was not the case before. Or maybe *I* miss something. >>> >>> Can you show me something that was working before and that is not >>> anymore? >>> >>> Thanks, >> >> I welcome the fix but not the option: the option situation in Org mode >> was pretty horrible, then ca 2010, you did a survey and some options >> were eliminated (not sure about the year or whether it *was* you who >> did the survey, but I'm pretty sure there was one): that was the right >> direction to go, but it wasn't enough. Org mode needs to be put into >> an option diet, so adding another one here (and a rather gratuitous >> one in my view) is not the way to go. >> >> `:results value' should *always* produce the value of the last expression, >> which for shell programs is the exit status of the last command. >> >> `:results output' should *always* produce all of the output of the program. >> >> An argument can be made that `:results value' is the default, but it >> is the less useful option for shell programs. So maybe for shell >> blocks, make the default to be `:results output' instead: people get >> what they always got before the fix without lifting a finger, the exit status >> is now available with `:results value', and the option can go away >> quietly and quickly, before it becomes another contributor to the Org >> mode technical debt. -- Paul Scherrer Institut Dr. Derek Feichtinger Phone: +41 56 310 47 33 Group Head HPC and Emerging Technologies Email: derek.feichtin...@psi.ch Building/Room No. WHGA/U126 Forschungsstrasse 111 CH-5232 Villigen PSI
Re: org link to OCaml comment
On 2020-02-19 18:49, Nicolas Goaziou writes: > Alan Schmitt writes: > >> I understand, and I can be careful (and easily fix the link if needed). >> If `org-store-link' could do it for me, that would be perfect. > > I pushed some changes to `org-store-link' in order to fix this. Please > report if there is anything wrong. Thanks a lot! Best, Alan
Re: attachment: link type export to HTML invalid attach dir
Hi Nicolas, Nicolas Goaziou writes: > This second patch removes most of the "attachment" leakage in the code > base (mainly "org-element.el" and "ox-*.el"). The features should be the > same as before. Let me know if there's anything wrong. Thanks a lot -- feel free to apply it when you think it's okay. Also, perhaps can you or Gustav suggest a way to test the new feature so that we can test this new code? > The only thing left is to refactor the ability to display "attachment" > links as inline images. For now, this is hard-coded in "org.el", but > this should not be the case. > > As a third phase, I suggest to add a new parameter in > `org-link-parameters', for example :inlineable. This parameter would be > either a boolean, or a function transforming the path. For example, > "file" links should set it to t and "attachment" links to > `org-attach-expand'. Then `org-display-inline-images' should collect > link types with this flag, apply the transformation, and display images > accordingly. Do you want to do this for 9.4 or can it be done later on? Thanks, -- Bastien
Re: ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
Hi Karl, another suggestion: just send us a minimal extract of your files so that we see how org-depend is called, together with what you do and what goes wrong when you do it. Perhaps this will lead to something. I've never used org-edna, I'm curious to know if there are many users. Thanks, -- Bastien
Re: ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
Hi, * Bastien wrote: > > Karl Voit writes: > >> A couple days ago, the issue re-appeared (with org-depend being >> active again). To me, this is a clear indicator, that the issue is >> content-related and not config/binary-related: > > Can you bisect and deduce what part of your contents is producing > this? This is not trivial in my case since I'd have to merge all my Org mode content into one single large file and make sure that I remove content during bi-secting that has no link destination from the remaining content. Personally, I'm not convinced that this method will lead to a minimum example in any case. I can imagine that "number of Org mode headings/lines" might be involved here which would not trigger the error when bi-secting via removing. Currently, I don't see that this is possible without half a day work or (IMHO more likely) longer which I can't afford right now. :-( > When you have a clue, could you also bisect and see what > change in Org introduced this problem for the problematic contents? This would be trivial when I could locate the issue in a minimal example. > Such issues are difficult to reproduce and track outside your files. Totally agree. I thought somebody else might have faced the same issue. As long as I am the only person affected, I don't assume that it can be solved in a proper way. :-( I ran another test with Emacs 27.0.50 and disabled org-depend. The task finished after 4½ minutes without any error. Therefore, following dependencies has to be the culprit here. Moving from org-depend to org-edna is not trivial for me as well, considering the amount of meta-data to be modified. On the other hand, this would be interesting to see if org-edna can handle this use-case in a better way. In case somebody has experience with migration process and/or dependency lookup performance, I'm very interested. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: attachment: link type export to HTML invalid attach dir
Following up,
Nicolas Goaziou writes:
> This is the first part of the suggested changes. These do not touch
> attachment modifications, but rather improve the tooling in "ol.el".
This second patch removes most of the "attachment" leakage in the code
base (mainly "org-element.el" and "ox-*.el"). The features should be the
same as before. Let me know if there's anything wrong.
The only thing left is to refactor the ability to display "attachment"
links as inline images. For now, this is hard-coded in "org.el", but
this should not be the case.
As a third phase, I suggest to add a new parameter in
`org-link-parameters', for example :inlineable. This parameter would be
either a boolean, or a function transforming the path. For example,
"file" links should set it to t and "attachment" links to
`org-attach-expand'. Then `org-display-inline-images' should collect
link types with this flag, apply the transformation, and display images
accordingly.
Regards,
--
Nicolas Goaziou
>From e5ccffcf617f3d04d97840873c0b16913eb65369 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
Date: Thu, 20 Feb 2020 09:29:21 +0100
Subject: [PATCH] Do not leak "attachment" links
* lisp/ol.el (org-link-open): Remove "attachment" for special cases.
* lisp/org-attach.el (org-attach-expand-links):
(org-attach-follow): New functions.
(org-attach-link-expand): Remove function.
* lisp/org-element.el (org-element-link-parser):
* lisp/ox-ascii.el (org-ascii-link):
* lisp/ox-html.el (org-html-link):
* lisp/ox-latex.el (org-latex--inline-image):
(org-latex-link):
* lisp/ox-man.el (org-man-link):
* lisp/ox-md.el (org-md-link):
* lisp/ox-odt.el (org-odt-inline-image-rules):
(org-odt-link):
* lisp/ox-texinfo.el (org-texinfo-inline-image-rules):
(org-texinfo-link): Remove "attachment" from special cases.
---
lisp/ol.el | 5 +
lisp/org-attach.el | 45 +++--
lisp/org-element.el | 10 +-
lisp/ox-ascii.el| 23 +--
lisp/ox-html.el | 6 +-
lisp/ox-latex.el| 23 ---
lisp/ox-man.el | 17 ++---
lisp/ox-md.el | 10 ++
lisp/ox-odt.el | 11 ++-
lisp/ox-texinfo.el | 10 +-
10 files changed, 66 insertions(+), 94 deletions(-)
diff --git a/lisp/ol.el b/lisp/ol.el
index 76454d2db..e9bed3972 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -75,7 +75,6 @@
(declare-function org-src-source-type "org-src" ())
(declare-function org-time-stamp-format "org" ( long inactive))
(declare-function outline-next-heading "outline" ())
-(declare-function org-attach-link-expand "org-attach" (link buffer-or-name))
;;; Customization
@@ -1027,9 +1026,7 @@ for internal and \"file\" links, or stored as a parameter in
(pcase type
;; Opening a "file" link requires special treatment since we
;; first need to integrate search option, if any.
- ((or "file" "attachment")
- (when (string= type "attachment")
- (setq path (org-attach-link-expand link)))
+ ("file"
(let* ((option (org-element-property :search-option link))
(path (if option (concat path "::" option) path)))
(org-link-open-as-file path
diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index d073291a2..97a7236e4 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -41,6 +41,8 @@
(declare-function dired-dwim-target-directory "dired-aux")
(declare-function org-element-property "org-element" (property element))
+(declare-function org-element-type "org-element" (element))
+(declare-function org-export-link-as-file "org-export" (path description backend info))
(defgroup org-attach nil
"Options concerning attachments in Org mode."
@@ -646,22 +648,36 @@ See `org-attach-open'."
Basically, this adds the path to the attachment directory."
(expand-file-name file (org-attach-dir)))
-(defun org-attach-link-expand (link buffer-or-name)
- "Return the full path to the attachment in the LINK element.
-Takes LINK which is a link element, as defined by
-`org-element-link-parser'. If LINK `:type' is attachment the
-full path to the attachment is expanded and returned. Otherwise,
-return nil. If BUFFER-OR-NAME is specified, LINK is expanded in
-that buffer, otherwise current buffer is assumed."
- (let ((type (org-element-property :type link))
- (file (org-element-property :path link))
- (pos (org-element-property :begin link)))
-(when (string= type "attachment")
- (with-current-buffer (or buffer-or-name (current-buffer))
- (goto-char pos)
- (org-attach-expand file)
+(defun org-attach-expand-links (_)
+ "Expand links in current buffer.
+It is meant to be added to `org-export-before-parsing-hook'."
+ (save-excursion
+(while (re-search-forward "attachment:" nil t)
+ (let ((link (org-element-context)))
+ (when (and (eq 'link (org-element-type link))
+ (string-equal "attachment"
+ (org-element-property :type link)))
+ (let* ((description (and
