bug logging the TODO tracking state with brackets in the header
Hi, I reached a strange bug, I hope you can reproduce it too I want to track changes on TODO and I have in the beginning of my buffer: #+TODO: TODO(t!) PLANNED(p!) DOING(d!) VERIFY(v) EXPLAIN(e) | DONE(d!) which means that TODO, PLANEED, DOING and DONE will have a report of change in the same header [0] If I have the number of TODOs like [6/45] (6 DONE, 45 in TODO) is not working (see [1] for my example) If I quit that expression, it works, that could be the case when I do a subheader from a header without that brackets [2] I hope this example is illustrative [1]. The header that says "this fails" if I change the state, it reports tracking state in the parent header with wrong information "state TODO from TODO". It fails because the parent has the bracket thing. If the parent of the parent has bracket thing it reports to "the parent of the parent", so it is weird :/ The header that says "this works" changes from states correctly because parent does not have the brackets I hope you can reproduce the bug on your own I'm using orgmode version 9.3 let me if I can help with the bug reporting Cheers, pinmacs [0] https://www.gnu.org/software/emacs/manual/html_node/org/Tracking-TODO-state-changes.html [1] *** TODO <2019-12-07 Sat> [6/45] :today: - State "TODO" from "TODO" [2019-12-07 Sat 22:58] - State "TODO" from "TODO" [2019-12-07 Sat 22:58] - State "TODO" from "TODO" [2019-12-07 Sat 22:57] - State "TODO" from "TODO" [2019-12-07 Sat 22:57] - State "TODO" from "TODO" [2019-12-07 Sat 22:57] - State "TODO" from "TODO" [2019-12-07 Sat 22:57] DONE this fails * DONE this works OK - State "DONE" from "EXPLAIN" [2019-12-07 Sat 22:58] - State "DOING" from "PLANNED" [2019-12-07 Sat 22:58] - State "PLANNED" from "TODO" [2019-12-07 Sat 22:58] - State "TODO" from [2019-12-07 Sat 22:58] [2] as you can see in the following 2 links: - https://orgmode.org/manual/Breaking-down-tasks.html#Breaking-down-tasks - https://orgmode.org/manual/Checkboxes.html#Checkboxes
Re: bug logging the TODO tracking state with brackets in the header
Hi list, I discovered that this issue is not reproduceable (noticiable) from an emacs vanilla version (without custom configuration) after digging in my config file that endend up with a happy orgmode file with thanks to babel and tangle [1] I found the problem. These are the lines that produce the mentioned bug (I tested just that lines alone in the custom configuration and still is reproduceable): #+BEGIN_SRC emacs-lisp ;; If you would like a TODO entry to automatically change to DONE when ;; all children are done, you can use the following setup: ;; source : http://orgmode.org/manual/Breaking-down-tasks.html#Breaking-down-tasks (defun org-summary-todo (n-done n-not-done) "Switch entry to DONE when all subentries are done, to TODO otherwise." (let (org-log-done org-log-states) ; turn off logging (org-todo (if (= n-not-done 0) "DONE" "TODO" (add-hook 'org-after-todo-statistics-hook 'org-summary-todo) #+END_SRC fetching the link from official orgmode documentation looks like my code is up to date. But this code does the mentioned bug-error. I'm happy to comment that lines, to loose that mini-feature and gain the two others (numbering TODOs and tracking the state changes) Any ideas why it fails with that lines? Cheers, pinmacs [1] inspired by: http://www.coli.uni-saarland.de/~slemaguer/emacs/main.html https://github.com/seblemaguer/dotfiles/blob/master/emacs.d/main.org https://raw.githubusercontent.com/seblemaguer/dotfiles/master/emacs.d/main.org On 12/7/19 11:11 PM, pinmacs wrote: > Hi, > > I reached a strange bug, I hope you can reproduce it too > > I want to track changes on TODO and I have in the beginning of my buffer: > > #+TODO: TODO(t!) PLANNED(p!) DOING(d!) VERIFY(v) EXPLAIN(e) | DONE(d!) > > which means that TODO, PLANEED, DOING and DONE will have a report of > change in the same header [0] > > If I have the number of TODOs like [6/45] (6 DONE, 45 in TODO) is not > working (see [1] for my example) > > If I quit that expression, it works, that could be the case when I do a > subheader from a header without that brackets [2] > > I hope this example is illustrative [1]. > > The header that says "this fails" if I change the state, it reports > tracking state in the parent header with wrong information "state TODO > from TODO". It fails because the parent has the bracket thing. If the > parent of the parent has bracket thing it reports to "the parent of the > parent", so it is weird :/ > > The header that says "this works" changes from states correctly because > parent does not have the brackets > > I hope you can reproduce the bug on your own > > I'm using orgmode version 9.3 > > let me if I can help with the bug reporting > > Cheers, > pinmacs > > [0] > https://www.gnu.org/software/emacs/manual/html_node/org/Tracking-TODO-state-changes.html > > [1] > > *** TODO <2019-12-07 Sat> [6/45] > :today: > - State "TODO" from "TODO" [2019-12-07 Sat 22:58] > - State "TODO" from "TODO" [2019-12-07 Sat 22:58] > - State "TODO" from "TODO" [2019-12-07 Sat 22:57] > - State "TODO" from "TODO" [2019-12-07 Sat 22:57] > - State "TODO" from "TODO" [2019-12-07 Sat 22:57] > - State "TODO" from "TODO" [2019-12-07 Sat 22:57] > DONE this fails > * DONE this works OK > - State "DONE" from "EXPLAIN" [2019-12-07 Sat 22:58] > - State "DOING" from "PLANNED" [2019-12-07 Sat 22:58] > - State "PLANNED" from "TODO" [2019-12-07 Sat 22:58] > - State "TODO" from [2019-12-07 Sat 22:58] > > [2] > > as you can see in the following 2 links: > > - https://orgmode.org/manual/Breaking-down-tasks.html#Breaking-down-tasks > - https://orgmode.org/manual/Checkboxes.html#Checkboxes > >
link broken on babel header-args
on: https://orgmode.org/worg/org-contrib/babel/header-args.html points to: https://orgmode.org/manual/Specific-header-arguments.html which is 404 I think the correct link is: https://orgmode.org/manual/Using-Header-Arguments.html#Using-Header-Arguments OpenPGP_0x9D64597C3A982DCA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
BUG: after an org-capture to an inbox entry, statistics-cookies are not updated on certain circumstances
Hi,
I am living with this bug since a long time, I thought I was asking
maybe something very special.
But then I find on a org-capture that goes to an inbox entry:
1. if prepend is nil, does not work on the first time (?)
2. works when number of entries is greater than 1
3. never works when prepend is t
Find attached org-capture-cookies-bug.org which I think it makes it very
easy to reproduce. Tested with ~emacs -Q~ with orgmode 9.7.10 and
emacs-30 branch with commit 44c2614
Cheers,
pinmacs
[1] I mean, like running this function: (org-update-statistics-cookies nil)
#+TODO: TODO | DONE
* inbox ~:prepend nil~ works except first element (?) [3/3] [100%]
:PROPERTIES:
:CUSTOM_ID: inbox_prepend_nil
:END:
** DONE Test title
** DONE Test title
** DONE Test title
* inbox ~:prepend t~ never works (?) [0/0] [0%]
:PROPERTIES:
:CUSTOM_ID: inbox_prepend_t
:END:
** DONE Test title
** DONE Test title
** DONE Test title
* run this
with ~:prepend nil~, cookies are updated, *except for some reason, the first item*
#+name: prepend_t
#+begin_src emacs-lisp :results none
(defun my/goto ()
(org-link-open-from-string "[[#inbox_prepend_nil]]"))
(setq org-capture-templates
'(
("t" "test" entry (function my/goto) "** DONE Test title" :immediate-finish t :prepend nil)
))
;; run org-capture noninteractive
(org-capture nil "t")
#+end_src
with ~:prepend t~, cookies are *not* updated
#+name: prepend_nil
#+begin_src emacs-lisp :results none
(defun my/goto ()
(org-link-open-from-string "[[#inbox_prepend_t]]"))
(setq org-capture-templates
'(
("t" "test" entry (function my/goto) "** DONE Test title" :immediate-finish t :prepend t)
))
;; run org-capture noninteractive
(org-capture nil "t")
#+end_src
OpenPGP_0x9D64597C3A982DCA.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
BUG (regression): clocktable with ~:link t~ looks visually inconsistent
Hi, On a clocktable with hierarchy (see attached file clocktable-link-bug.org), when ~:link t~ is used, it does not look visually good; that was not an issue with the previous versions of orgmode Find attached screenshot 2024-09-01_23-05_clocktable-detail.png, that shows the inconsistency in my ~emacs -Q~ with orgmode 9.7.10 and emacs-30 branch with commit 44c2614 Cheers, pinmacs * [2024-08-31 Sat] :PROPERTIES: :CREATED: [2024-09-01 Sun 23:00] :CUSTOM_ID: clocktable-link-bug_2 :END: ** DONE task1 :LOGBOOK: CLOCK: [2024-08-31 Sat 22:45]--[2024-08-31 Sat 22:56] => 0:11 :END: * [2024-09-01 Sun] :PROPERTIES: :CREATED: [2024-09-01 Sun 23:00] :CUSTOM_ID: clocktable-link-bug_1 :END: ** DONE task2 :LOGBOOK: CLOCK: [2024-09-01 Sun 22:30]--[2024-09-01 Sun 22:56] => 0:26 :END: clocktable with ~:link nil~ shows it fine #+NAME: my_clocktable_without_link #+BEGIN: clocktable :maxlevel 4 :scope file :link nil #+CAPTION: Clock summary at [2024-09-01 Sun 23:03] | Headline | Time | | |--+--+--| | Total time | 0:37 | | |--+--+--| | [2024-08-31 Sat] | 0:11 | | | \_ task1| | 0:11 | | [2024-09-01 Sun] | 0:26 | | | \_ task2| | 0:26 | #+END clocktable with ~:link nil~ shows it bad #+NAME: my_clocktable #+BEGIN: clocktable :maxlevel 4 :scope file :link t #+CAPTION: Clock summary at [2024-09-01 Sun 23:03] | Headline | Time | | |---+--+--| | Total time| 0:37 | | |---+--+--| | [[file:/home/music/clocktable-link-bug.org::*\[2024-08-31 Sat\]][[2024-08-31 Sat]]] | 0:11 | | | \_ [[file:/home/music/clocktable-link-bug.org::*task1][task1]] | | 0:11 | | [[file:/home/music/clocktable-link-bug.org::*\[2024-09-01 Sun\]][[2024-09-01 Sun]]] | 0:26 | | | \_ [[file:/home/music/clocktable-link-bug.org::*task2][task2]] | | 0:26 | #+END OpenPGP_0x9D64597C3A982DCA.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
org-contrib: I suggest a new bugfix release
Hi, Now that I refreshed orgmode and emacs, I was confused why propview was not working as expected, then I realized that the official version is still 0.4.2 [1], I am confused that the date or the number does not match with the 0.5 release [2] Anyway, I think these two commits are really important to improve propview parsing inactive timestamps (instead of being considered a lisp array, which does not make sense in an orgmode context); and on case of properties started with parenthesis, it warns that it is not desirable, and what property made the propview execution fail [3] Thanks for your attention, pinmacs [1] https://elpa.nongnu.org/nongnu/org-contrib.html [2] https://git.sr.ht/~bzg/org-contrib/refs [3] https://git.sr.ht/~bzg/org-contrib/commit/e44255be733fc2adc66c5e742ce7b96e85c86d3f https://git.sr.ht/~bzg/org-contrib/commit/d4056ce5d5611e1c971c151f182a2d407226fdb1 OpenPGP_0x9D64597C3A982DCA.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
ox-latex: help: LATEX_HEADER from different subtrees collision
Hi,
** The context
I found a way to export subtrees to PDF and I liked that idea a lot, I
use it, for example, to generate with an org-capture an invoice, and
export to PDF, etc.
The invoice is part of my journal.
My journal is structured for the whole year (year, week, day). That
file has a lot of lines: 3247 the active 2024, and 179487 the archived
2024; the archived part is out of the org-agenda).
Then I wanted to add a weekly report, which extracts some properties
of some entries, generates some tables, and I wanted to be exported
them to PDF in the same way.
** The problem
I discovered that the LATEX_HEADER of a different subtree produce
collisions, when I discovered this I felt weird, because
~org-latex-export-to-pdf~ docstring says that it respects the
narrowing or the region [1], but I can reproduce how this is not
true. Or let me know what I am doing wrong, if LATEX_HEADER is buffer
scope (which would make sense), then, what is the equivalent in case
you want to specify a LATEX_HEADER in subtree scope
Find attached a file (ox-latex-problem.org) that produce [2] a clash
of latex headers [3], particularly, with geometry (landscape vs
portrait). That if you comment one or the other, it applies to the
whole buffer. Can you modify that file to make it work? Or is it a bug
on ox-latex?
Thanks for your attention,
pinmacs
[1]
If narrowing is active in the current buffer, only export its
narrowed part.
If a region is active, export that region.
[2] ~emacs -Q~ with orgmode 9.7.10 part of emacs-30 branch with commit
44c2614
[3] ! LaTeX Error: Option clash for package geometry.
* ox-latex-problem
** [2024-09-02 Mon]
*** report #1 (landscape)
:PROPERTIES:
:EXPORT_LANGUAGE: en
:EXPORT_TITLE:
:EXPORT_SUBTITLE:
:EXPORT_AUTHOR:
:EXPORT_DATE:
:EXPORT_OPTIONS: toc:nil timestamp:nil num:nil
:EXPORT_TOC: headlines 2
:EXPORT_FILE_NAME: /tmp/report2.pdf
:CLICK_TO_SEE_REPORT: file:/tmp/report2.pdf
:END:
#+name: sourceblock_created_2024-09-02_23-36-05
#+begin_src emacs-lisp :exports none :results none
(defun my/export-pdf ()
"renders the PDF"
(org-narrow-to-subtree)
(org-show-subtree)
(org-latex-export-to-pdf nil t t nil)
(widen)
)
(my/export-pdf)
#+end_src
# if you uncomment this, both reports are in landscape
#+LATEX_HEADER: \usepackage[a4paper, landscape, margin=0.5cm]{geometry}
My report #2
* Introduction
Introduction text
* The report #2
Report #2 text
* Conclusions
Conclusions text
** [2024-09-01 Sun]
*** report #2 (portrait)
:PROPERTIES:
:EXPORT_LANGUAGE: ca
:EXPORT_TITLE:
:EXPORT_SUBTITLE:
:EXPORT_AUTHOR:
:EXPORT_DATE:
:EXPORT_OPTIONS: toc:nil timestamp:nil num:nil
:EXPORT_TOC: headlines 2
:EXPORT_FILE_NAME: /tmp/report1.pdf
:CLICK_TO_SEE_REPORT: file:/tmp/report1.pdf
:END:
#+name: sourceblock_created_2024-09-02_23-36-07
#+begin_src emacs-lisp :exports none :results none
(defun my/export-pdf ()
"renders the PDF"
(org-narrow-to-subtree)
(org-show-subtree)
(org-latex-export-to-pdf nil t t nil)
(widen)
)
(my/export-pdf)
#+end_src
# if you uncomment this, both reports are in portrait
#+LATEX_HEADER: \usepackage[a4paper, margin=3cm]{geometry}
My report #1
* Introduction
Introduction text
* The report #1
Report #1 text
* Conclusions
Conclusions text
OpenPGP_0x9D64597C3A982DCA.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
ox-latex default template changed sentence spacing from 9.6 to 9.7 ?
Hi,
Yesterday I re-exported an old pdf file with the new orgmode 9.7, I
discovered a difference in the styling or the template compared to
what it was in orgmode 9.6
Luckily, after adding this line to the export [1] it matched 100%
(tested with diffpdf).
I could be wrong and maybe the change was on my side, but I doubt
because I use debian stable, and I did not change almost anything on
the base system, the only thing I did is to upgrade from emacs 29 to
emacs 30 one week ago.
If this styling change is confirmed [2], I think it should appear in the
NEWS.
I also would like to know if orgmode plans to change the style again
(and if the style changes, if it is going to be noticed in the
NEWS). Right now I am not familiar with a more deep workflow of the
latex export, but maybe ox-latex could work with a latex template, and
then I would realize how to use it so I am covered to reproduce the
same PDFs independently of the orgmode version.
Cheers,
pinmacs
[1] ~#+LATEX_HEADER: \linespread{1}~
which is about sentence spacing
https://en.wikipedia.org/wiki/Sentence_spacing
[2] If you need on my side more details to facilitate reproducibility let
me know and I will try to be more concrete.
OpenPGP_0x9D64597C3A982DCA.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: ox-latex default template changed sentence spacing from 9.6 to 9.7 ?
Hi Pedro,
You were right!
In my success of starting to have more diverse number of latex exports
in my yearly journal, it was being polluted because the global
~#+LATEX_HEADER~ stuff [1]
it went unnoticed because it was in lowcase and I was only searching for
the uppercase, these were the affecting lines:
#+latex_header: \usepackage{setspace}
#+latex_header: \onehalfspacing
Cheers,
pinmacs
[1] see here for more details:
https://list.orgmode.org/orgmode/224ef5a7-33fc-4467-b146-0899aa61b...@cas.cat/T/#t
On 2024-09-04 07:43, Pedro Andres Aranda Gutierrez wrote:
Hi,
I have a Linux with a recent emacs 30.0.90, org-mode 9.7.10 and a
freeBsd with an emacs 29.4, org-mode 9.6.15 and I see neither emitting
the linespread command.
Tested with #LATEX_COMPILER: lualatex and without it.
It must be something you have in your headers...
Best, /PA
--
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet
Re: ox-latex: help: LATEX_HEADER from different subtrees collision
Hey!
And this is trivial, but it took me a while to figure it out
Of course, if you want to use more than one EXPORT_LATEX_HEADER for that
subtree export, you need to use multi-value property [0]:
:PROPERTIES:
:EXPORT_LATEX_HEADER: \usepackage{bookmark}
:EXPORT_LATEX_HEADER+: \usepackage{nopageno}
:EXPORT_LATEX_HEADER+: \usepackage{siunitx}
:EXPORT_LATEX_HEADER+: \usepackage{colortbl}
:EXPORT_LATEX_HEADER+: \usepackage{xcolor}
:EXPORT_LATEX_HEADER+: \usepackage[a4paper, margin=3cm]{geometry}
:EXPORT_LATEX_HEADER+: \usepackage[none]{hyphenat}
:END:
Debugging [1] I also found that once there is one property
EXPORT_LATEX_HEADER, subsequent `#+LATEX_HEADER` are ignored, that's smart!
Cheers,
pinmacs
[0]
If you want to add to the value of an existing property, append a ‘+’
to the property name. The following results in the property ‘var’ having
the value ‘foo=1 bar=2’.
#+PROPERTY: var foo=1
#+PROPERTY: var+ bar=2
src https://orgmode.org/manual/Property-Syntax.html
[1] near the .pdf you have the .tex to debug, and you can export again
outside emacs with ~pdflatex~
Re: BUG: after an org-capture to an inbox entry, statistics-cookies are not updated on certain circumstances
On 2024-09-08 20:10, Ihor Radchenko wrote: pinm...@cas.cat writes: I am living with this bug since a long time, I thought I was asking maybe something very special. But then I find on a org-capture that goes to an inbox entry: 1. if prepend is nil, does not work on the first time (?) 2. works when number of entries is greater than 1 3. never works when prepend is t Find attached org-capture-cookies-bug.org which I think it makes it very easy to reproduce. Tested with ~emacs -Q~ with orgmode 9.7.10 and emacs-30 branch with commit 44c2614 I tried to follow the .org file, but everything seems to work fine on my side. Maybe I do not understand what exactly you expected and what exactly did not work (what "does not work" even mean?). May you please provide more detailed instructions on what one needs to do to see the bug, including which commands to run, and then explain what you actually see and what you expected? Fine tested again with =emacs -q= with GNU Emacs 30.0.90 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars) of 2024-08-30 * How to reproduce: 1. if prepend is nil, does not work on the first time (?) Remove all childs of the prepend nil inbox (the first), and refresh with C-c C-c so it works like this inbox ~:prepend nil~ works except first element (?) [0/0] [100%] run one time =prepend_t= src block title now is: inbox ~:prepend nil~ works except first element (?) [0/0] [0%] expected value is the same you would achieve going to end of line of inbox title and pressing C-c C-c: inbox ~:prepend nil~ works except first element (?) [1/1] [100%] * How to reproduce: 2. works when number of entries is greater than 1 Following the state after "1. if prepend is nil, does not work on the first time (?)", run one time run one time =prepend_t= src block title now is: inbox ~:prepend nil~ works except first element (?) [2/2] [100%] and that is the expected value, works as expected * How to reproduce: 3. never works when prepend is t Remove all childs of the prepend t inbox (the second), and refresh with C-c C-c so it works like this inbox ~:prepend t~ never works (?) [0/0] [100%] run one time =prepend_nil= src block title now is: inbox ~:prepend t~ never works (?) [0/0] [0%] expected value is the same you would achieve going to end of line of inbox title and pressing C-c C-c: inbox ~:prepend t~ never works (?) [1/1] [100%] That's it, le'ts see now if it is clear the bug I am pointing to Cheers, pinmacs
Re: BUG (regression): clocktable with ~:link t~ looks visually inconsistent
On 2024-09-09 18:19, Ihor Radchenko wrote: pinmacs writes: I changed it to Fira Code Retina with this command =(set-frame-font "Fira Code Retina" nil t)= ( see file 2024-09-09_18-11_fira-code.png ) As you see in the attached screen captures, I have the same problem with both fonts, what font do you use? Did you re-align the tables? I ran again =emacs -q= with GNU Emacs 30.0.90 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars) of 2024-08-30 did TAB and S-TAB on the affected table but looks the same as in the previous screenshots I manually aligned it OK (just adding a space after the linked title) and pressed TAB and S-TAB, then it reproduced the same inconsistency
Re: BUG: after an org-capture to an inbox entry, statistics-cookies are not updated on certain circumstances
On 2024-09-15 07:12, Ihor Radchenko wrote: pinmacs writes: Thanks! That helped. I was able to reproduce using stable version of Org mode. However, the bug is not present on the development version (main branch). So, the bug should no longer be present in the next Org mode release. Canceled. Hi Igor, Thanks for taking care of these issues! Here and there [1] I would like to close this thread saying that on a particular stable version this is fixed, let me know when this change is incorporated in whatever version and I will test it and then I will consider this closed from my side Cheers, pinmacs [1] https://list.orgmode.org/orgmode/bdab5b42-a661-463c-b30d-9a6161b5c...@cas.cat/T/
[FR] yank media: allow customization of absolute path a filter for type candidates
Hi, So I was using org-download, and I would like to replace it entirely with yank-media and what I am missisng is: 1. do a variable for selecting absolute path: to be able to have a file link that works with absolute path; and the reason is that being relative, this, does not combine good when you move your latex export somewhere else (in my case, I usually move it to /tmp/, and from there I decide when I want to save something persistently), hence it fails, and I got tired on fixing the links, in fact, the absolute path sometimes is smaller than the relative one =file:/tmp/clipboard-20240916T013308.png]]= vs =[[file:../../../tmp/clipboard-20240916T011913.png]]= 2. do a variable that allow a list that would filter and reduce the type candidates of yank-media. In org-download, everything was png so I was not having the "Several types available, choose one" with 7 options. But then is like, oh, maybe I would like to be able to switch between png (synthetic image), jpg (natural image)... anyway, I hope you see customizing this is interesting for the users. What I did to solve the absolute path meanwhile the discussion and development happens is defining on my own the entire function =org--image-yank-media-handler= just changing this: #+begin_src diff -(setq link (org-link-make-string (concat "file:" (file-relative-name absname +(setq link (org-link-make-string (concat "file:" absname))) #+end_src source (sorry, this link is slow to open): https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/org.el?id=cdcde091b9bdc14fc2254b0e594d8e0da6c4e6c6#n20895 and here is the equivalent to the org-download #+begin_src emacs-lisp (defun my/yank-media () "org-download replacement" (interactive) (let ((org-yank-image-save-method "/tmp/") (org-yank-dnd-method 'file-link)) (yank-media)) ;; facilitate image size on preview (save-excursion (previous-line) (insert "\n#+attr_org: :width 350px"))) ;; thanks for all the fish, org-download ;; (global-set-key (kbd "C-M-y") 'org-download-clipboard) (global-set-key (kbd "C-M-y") 'my/yank-media) #+end_src Thanks for your attention, pinmacs
please, report on current status of orgmode timestamps with timezone
Hi, From #11 OrgMeetup content [1] I see that a date with timestamp and timezone is used: <2024-09-11 Wed 19:00-21:00 @+03,Europe/Istanbul> With orgmode version 9.7.10: 1. If I try to to =C-c C-c= minibuffer says: "Not at a timestamp"; well, at least, does not try to remove the timezone part 2. Cannot change anything on it with =S-= nor =S-= 3. If I click the timestamp, minibuffer says: "This should not happen" 4. In the org agenda, the event appears in date 2024-09-11 and in my local time 19:00-21:00, so, no timezone calculation is done I saw that there were some discussions about this, but nothing consolidated in the documentation, maybe, at some point, it should be here [2] Is this something is going to arrive on 9.8 ? Is this something that only works in development version? Cheers, pinmacs [1] https://list.orgmode.org/87o750dja7.fsf@localhost/T/#u [2] https://orgmode.org/manual/Timestamps.html
clocktable: is there any ongoing effort on sum by tags funcionality ?
Hi, I saw a lot of patches and isolated efforts to have the feature of summing time by tag on a clocktable (instead of a file) Is there any ongoing effort or motivation to include it in emacs orgmode? Cheers, Pinmacs
feature request: date/time prompt of "hours/minutes ago"
Hi, Syntax available for date/time prompt is very nice. I would like to be able to use expressions for my timestamps such as -1h (1 hour ago) or -30m (30 minutes ago) or -1h30m (1 hour and a half ago) or +1h (in 1 hour) Cheers, pinmacs [1] https://orgmode.org/manual/The-date_002ftime-prompt.html fallback link (this morning orgmode webpagewas not working) https://www.gnu.org/software/emacs/manual/html_node/org/The-date_002ftime-prompt.html
Re: please, report on current status of orgmode timestamps with timezone
On 2024-09-22 19:13, Ihor Radchenko wrote: pinmacs writes: From #11 OrgMeetup content [1] I see that a date with timestamp and timezone is used: <2024-09-11 Wed 19:00-21:00 @+03,Europe/Istanbul> ... Is this something is going to arrive on 9.8 ? Is this something that only works in development version? This is an idea we have discussed as a feature request and decided that we should eventually implement time zone support. We even decided on the approximate timestamp markup. However, there is no actual code in Org mode that implements timestamps with time zones. Patches welcome! See https://list.orgmode.org/87tu063ox2.fsf@localhost/ and the parent thread for details. I am repeatedly seeing this in different places: patches welcome for the new timezone orgmode timestamps. But it points to a thread with 366+ messages. I propose to, first off, reduce complexity of the task: Someone should summarize that lengthy conversation with the proposed specification. From there, we can move it to a worg page, then, we have a easily to share link to say, this is what we want, patches welcome.
Re: please, report on current status of orgmode timestamps with timezone
On 2024-12-08 14:03, Ihor Radchenko wrote: pinmacs writes: See https://list.orgmode.org/87tu063ox2.fsf@localhost/ and the parent thread for details. I am repeatedly seeing this in different places: patches welcome for the new timezone orgmode timestamps. But it points to a thread with 366+ messages. I propose to, first off, reduce complexity of the task: Someone should summarize that lengthy conversation with the proposed specification. Is the specification provided in https://list.orgmode.org/87tu063ox2.fsf@localhost/ (that exact message) not clear? Ah ok, finally! I did not know that on that email contained the specification. Thank you for clarifying me that. From there, we can move it to a worg page, then, we have a easily to share link to say, this is what we want, patches welcome. What do you think we should put on that page? First of all, it is optional, so take this as "feedback" from user perspective. Motivation: I disagree that an email from a mailing list should be the reference for all orgmode users on the current state of something that matters (maybe not for everything). When I search on that topic, I got lost, and that's why I asked on the mailing list. From a user-wide perspective, it is better if it's a web page (which could source to the original email). What information would be on that page? Right now, just the same information that in that email content from "The proposed new timestamp syntax" to its end. With a brief introduction saying that this has a status of a proposal and patches welcome (when this is already done, it could be a page where people can share recipes on timezones). This looks better and clearer https://orgmode.org/worg/timestamp-timezone Than https://list.orgmode.org/87tu063ox2.fsf@localhost/ Of course, on my personal basis, I no longer need that because I already know it, but other people might have that question; or maybe not because of the additional noise I produced! And now let me continue with your amazing presentation on emacsconf2024 about the org update situation. And congratulations on stepping up officially as the new org mantainer Thanks and health, pinmacs
C-c C-x M-y for (funcall 'org-paste-subtree '(16))
Days ago I discovered that exists org-paste-subtree, but the functionality that I like is when you pass it C-u two times I discovered that this shortcut is available, and sometimes I want to paste subtrees in the same level as the previous (C-c C-x C-y), and sometimes I want to inject them as subtree I feel this shortcut is nice for that, and I want to share if you consider to add it to default orgmode, that keybinding is available (add-hook 'org-mode-hook (lambda () (local-set-key (kbd "C-c C-x M-y") (lambda () (interactive) (funcall 'org-paste-subtree '(16))
Re: insert a header and automatically a timestamp with date/time
On 2025-02-02 21:02, Uwe Brauer via General discussions about Org-mode. wrote: A last question though. Now if I want my headings look like * <2025-02-02 08:58> Second entry * <2025-02-02 08:53> First * <2025-02-02 08:56> third Is there any way to sort these heading with respect to the timestamps from oldes to newest? I'm glad it works for you :) You need a parent entry (see how I added example). From that parent entry, do M-x org-sort and select alphanumeric (a), and that sorts fine the timestamps; you will see that there are other ways to sort entries, the one I use today is scheduled (s). * example ** <2025-02-02 08:53> First ** <2025-02-02 08:56> third ** <2025-02-02 08:58> Second entry
Re: insert a header and automatically a timestamp with date/time
On 2025-02-02 08:38, Uwe Brauer via General discussions about Org-mode. wrote: Vale, entendido (supongo que eres español, porque usas la palabra movil, ¿correcto?) Yes :D but let's keep the discussion in the mailinglist in English so other people can participate, or benefit from it Thanks, but I cannot find the function my/set-property-with-inactive-timestamp In your code, In fact you don't need ~my/get-inactive-timestamp~ for your pursposes, try with this one: #+begin_src emacs-lisp (defun my/org-add-timestamp-on-heading () (save-excursion (org-back-to-heading) (org-edit-headline (format-time-string "<%F>" (add-hook 'org-insert-heading-hook 'my/org-add-timestamp-on-heading 'append) ;; to remove it ;; (remove-hook 'org-insert-heading-hook 'my/org-add-timestamp-on-heading) #+end_src but here you have for curiosity, there you can see compact strftime format to construct a inactive timestamp [1] #+begin_src emacs-lisp (defun my/get-inactive-timestamp () (format-time-string "[%F %a %R]")) (defun my/set-property-with-inactive-timestamp (property) (interactive) (org-set-property property (my/get-inactive-timestamp))) #+end_src
org agenda bulk todo with note
Given: 1. A tendency of massively marking all items as schedule [1] 2. Some of that items should be done on daily basis (I generate them with a daily template and the power of org-capture) 3. Life happens and some of them are accumulated, for my last case, that was 29 entries pending to be processed Action: I procedure with a batch action for that 29 entries (imagine here a batch script), and now that it is done, then I need to clear it up from my org-agenda org-agenda-bulk-action [2] does not serve me because it marks the TODO thing without a note, and it's not possible to add a note with the prefix. Going to offtopic, I also discovered that does not respect the enforce-todo-dependencies [3], ignores if that entries have child todo items. I tried to create a org-agenda-bulk-custom-functions but I failed because I wanted a chosen state and a shared note for all the bulk items and the way that functions work cannot be done. But the bulk items are in a variable (nice), org-agenda-bulk-marked-entries, and you can traverse it with a generic function, so I did it. It took me, unexpectetly, 1h30m to get it working (and I could not find other stuff around), so I am sharing what I have done so other people can benefit, and by the way, I would like to know what do you think of that approach and if you have ideas to improve it. See it attached in file org-agenda-bulk-todo-with-note.el With that script I added a note of resolution of that items saying that it was resolved through my task with CUSTOM_ID/ID X (like when you close multiple issues in a ticketing software) [4] A healthy 2025 for you guys, pinmacs [1] offtopic, but I am sharing it anyway #+begin_src emacs-lisp (defun my/org-heading-insert-scheduled () (if (or (and (string-match-p my/diary-file (buffer-name)) (= (org-current-level) 4)) (and (string-match-p my/board-file (buffer-name)) (= (org-current-level) 4)) (and (string-match-p "projects.org" (buffer-name)) ;; projects are 4-level (tasks start at 6-level, we don't care on its children) (> (org-current-level) 5)) (and (string-match-p "projects-candidates.org" (buffer-name)) ;; projects are 4-level (tasks start at 3-level, we don't care on its children) (> (org-current-level) 3)) ) (save-excursion ;; src https://emacs.stackexchange.com/questions/72147/org-mode-adding-creation-date-property-upon-heading-creation ;;(org-back-to-heading) (org-schedule nil (format-time-string "[%Y-%m-%d %a]" nil) (add-hook 'org-insert-heading-hook 'my/org-heading-insert-scheduled 'append) #+end_src [2] https://orgmode.org/manual/Agenda-Commands.html [3] (setq org-enforce-todo-dependencies t) https://orgmode.org/manual/TODO-dependencies.html [4] all that state changes are stored, in my case, in (setq org-log-state-notes-into-drawer "TRACE");; this should be run with M-x ;; all selected bulk entries should have same todo keywords (defun my/bulk-todo-with-note () "For each marked entry in the Org agenda, set the TODO state with a shared note, and insert the same user-provided note for all items." (interactive) (unless org-agenda-bulk-marked-entries (user-error "No entries are marked in the agenda")) (let* ((buffer-todo-keywords (with-current-buffer (marker-buffer (car org-agenda-bulk-marked-entries)) org-todo-keywords-1)) (chosen-state ;; not good when specific on a buffer (org-icompleting-read "Choose new TODO state: " buffer-todo-keywords nil t)) (shared-note (read-string "Enter note for all marked items: "))) (dolist (marker org-agenda-bulk-marked-entries) (with-current-buffer (marker-buffer marker) (goto-char marker) (org-todo chosen-state) (org-add-log-setup 'state chosen-state nil nil) ;; Insert the shared note and finalize it. (org-add-log-note) (insert shared-note) (org-store-log-note)
Re: inconsistency for the affiliated keyword of a dynamic block
4 inline replies: On 2025-03-15 19:39, Ihor Radchenko wrote: pinmacs writes: There is a special case that might need a clarification in the orgmode implementation and/or the org-syntax [0] The affiliated keyword, when it's before a dynamic block [1] it does not work. Example: #+NAME: test #+BEGIN: something-that-generates-a-table | State | ID | Task | RESPONSIBLE | |---++-+-| | TODO | T1 | [[file:/tmp/affiliated-keyword-dynamic-block.org::*My task][My task]] | Laura | | TODO | T2 | [[file:/tmp/affiliated-keyword-dynamic-block.org::*Task2][Task2]] | Anna | #+END: What do you mean by "does not work"? It works just fine. You can refer to it - it is a name for the dynamic block itself. 1/4 OK, sorry I am so export-centric now that I missed that you might want to refer to the dynamic block itself, true. It must be #+BEGIN: something-that-generates-a-table #+NAME: test | State | ID | Task | RESPONSIBLE | |---++-+-| | TODO | T1 | [[file:/tmp/affiliated-keyword-dynamic-block.org::*My task][My task]] | Laura | | TODO | T2 | [[file:/tmp/affiliated-keyword-dynamic-block.org::*Task2][Task2]] | Anna | #+END: Maybe we can arrange Org to leave manually added affiliated keywords as is when updating the dblock, similar to what colview does. Another idea is https://list.orgmode.org/orgmode/871qaer7bo.fsf@localhost/ 2/4 Regretably I could not try the patch, is it because I am using 9.7.10 ? [1]. looks like a nice proposal, that's a neat patch. I only see a problem that some of the affiliated keywords might refer to identify a specific element, such as NAME, then, that would cause ID collisions? That's what makes me think it's better to have something general on preserving that kind of keywords for the generated elements; that helps in terms of export #+NAME: my dynamic-block #+begin: clocktable :scope file :maxlevel 2 :org-dblock-prepend (:attr_latex) #+NAME: my dynamic-block #+CAPTION: Clock summary at [2024-01-18 Thu 16:23] | Headline | Time | |+-| | *Total time* | *0h 0min* | #+end: [1] I would like to switch easily between different orgmode versions nightly, etc.; any suggestion? Something like ~(use-package org :ensure nil :vc (:url "https://git.savannah.gnu.org/cgit/emacs/org-mode.git"; :rev :newest))~ and then ~git checkout~ here and there? I think it is reasonable to say that a NAME given before a BEGIN dynamic block element, applies to the thing that the dynamic block generates The ability to clearly identify elements of exported html document is nice to improve the visibility of things, for example here I experienced how a table that represents a kanban might be better visualized using css and js [2] Then, it will be impossible to refer to the dynamic block itself. 3/4 Agree, that's true, thanks for your feedback, now I agree, there are two elements to identify, dynamic block and its result Coming back to the org syntax, I suspect that the table rows are not an exception, #+NAME before table rows is specifically what I am using to identify the table, and what does not work when there is in the middle the dynamic block May you elaborate? 4/4 In html export (maybe other exporters too), the ~#+NAME: mytable~ results in, some html such as ~cellspacing="0" cellpadding="6" rules="groups" frame="hsides">~; that way, you can identify the table with CSS and Javascript There are other ways to achieve the same thing: ~#+ATTR_HTML: :id somefixedid~ exports to ~cellspacing="0" cellpadding="6" rules="groups" frame="hsides">~
Re: inconsistency for the affiliated keyword of a dynamic block
On 2025-03-27 17:13, pinmacs wrote:
Maybe we can use similar idea and allow users to list the affiliated
keywords (or regexps matching the keyword names) to keep. Then, after
updating the dynamic block, if some affiliated keywords have been
removed, they are re-added. WDYT?
3/5 I think that's better, but consider also WDYT about expanding the
column-view keyword-affiliation preservation to all dblocks
Also for completeness/FYI/meanwhile, org-kanban decided to solve it this
way.
But yes, would be nice to solve it for all dblocks finally and stop
solving the same problem case by case
Add headers parameter in front of the generated org-kanban tables
e.g. `:headers ("#+CAPTION: the caption" "#+NAME: a name")` adds a
caption and a name to the kanban table.
https://github.com/emacsmirror/org-kanban/commit/15681651da2e30350541ff0053796eaddceb8c47
Re: inconsistency for the affiliated keyword of a dynamic block
5 inline replies
On 2025-03-16 13:18, Ihor Radchenko wrote:
pinmacs writes:
Maybe we can arrange Org to leave manually added affiliated keywords as
is when updating the dblock, similar to what colview does.
Another idea is https://list.orgmode.org/orgmode/871qaer7bo.fsf@localhost/
2/4
Regretably I could not try the patch, is it because I am using 9.7.10
?
Maybe. The patch is against the development branch (main).
1/5 (I hope "soon" I might be able to configure a switch between stable
and development, thanks for the indication)
[1]. looks like a nice proposal, that's a neat patch. I only see a
problem that some of the affiliated keywords might refer to identify a
specific element, such as NAME, then, that would cause ID collisions?
That's exactly why the patch asks users to list which affiliated
keywords to copy over. It does not help with #+name, of course.
2/5 OK, I realized that I did not get on the first time, yes, #+name is
a corner case; a problematic one (the need of the name to chain dblocks
vs the name for the exports)
I also discovered that there is a bug or inconsistency when using the
column-view dblock with the patch: it generates duplicates on each
processing, see attached file example dblock-example.org, and compare
the processing of my-table-name0 vs my-table-name1. In fact, current
column-view already preserves all affiliated keywords you put on table,
maybe that is something we want for all dblocks, not just for column-view
That's what makes me think it's better to have something general on
preserving that kind of keywords for the generated elements; that helps
in terms of export
#+NAME: my dynamic-block
#+begin: clocktable :scope file :maxlevel 2 :org-dblock-prepend
(:attr_latex)
#+NAME: my dynamic-block
#+CAPTION: Clock summary at [2024-01-18 Thu 16:23]
| Headline | Time |
|+-|
| *Total time* | *0h 0min* |
#+end:
Maybe we can use similar idea and allow users to list the affiliated
keywords (or regexps matching the keyword names) to keep. Then, after
updating the dynamic block, if some affiliated keywords have been
removed, they are re-added. WDYT?
3/5 I think that's better, but consider also WDYT about expanding the
column-view keyword-affiliation preservation to all dblocks
[1] I would like to switch easily between different orgmode versions
nightly, etc.; any suggestion? Something like ~(use-package org :ensure
nil :vc (:url "https://git.savannah.gnu.org/cgit/emacs/org-mode.git";
:rev :newest))~ and then ~git checkout~ here and there?
You can install Org mode from git as described in
https://orgmode.org/manual/Installation.html#Using-Org_0027s-git-repository-1
and switch branches as needed.
:vc should do something similar.
4/5 Yes, I will try that way "soon"...
Coming back to the org syntax, I suspect that the table rows are not an
exception, #+NAME before table rows is specifically what I am using to
identify the table, and what does not work when there is in the middle
the dynamic block
May you elaborate?
4/4
In html export (maybe other exporters too), the ~#+NAME: mytable~
results in, some html such as ~~; that
way, you can identify the table with CSS and Javascript
There are other ways to achieve the same thing: ~#+ATTR_HTML: :id
somefixedid~ exports to ~~
Sure, but it is for the whole table, and you appear to be talking about
table rows.
5/5 It is fine for the whole table, I don't need for the table rows#+TODO: TODO DONE
#+COLUMNS: %TODO(State) %CUSTOM_ID(ID) %ITEM(Task) %RESPONSIBLE
# #+EXPORT_FILE_NAME: /tmp/org-kanban
#+TITLE: org-kanban html example
#+AUTHOR: Name
#+ATTR_HTML: :id abstract
#+begin_abstract
In this example I test different dynamic blocks and its linking
#+end_abstract
#+OPTIONS: prop:t toc:nil tags:not-in-toc d:(not "BACKLINKS" not "TRACE")
#+LANGUAGE: en
#+TOC: headlines 3
run these exports to test:
#+name: sourceblock_created_2025-03-12_14-06-44
#+begin_src emacs-lisp
(org-dblock-update t)
(org-html-export-to-html)
(org-gfm-export-to-markdown)
#+end_src
* Panel
** columnview
column view already preserves, so with the patch duplicates
#+BEGIN: columnview :id global :match "TODO={.+}-TODO=\"QUIT\"-TODO=\"DONE\"" :link t :org-dblock-prepend (:name)
#+name: my-table-name0
#+apsfi: apsji
#+CAPTION: Table with columnview
| State | ID | Task| RESPONSIBLE |
|---++-+-|
| TODO | T1 | [[file:/home/music/org-extra/projects-2025/2025_5_mejorac/2025-03-27_affiliated-keyword/dblock-example.org::*My task][My task]] | Laura |
| TODO | T2 | [[file:/home/music/org-extra/projects-2025/2025_5_mejorac/2025-03-27_affiliated-keyword/dblock-example.org::*Task2][Task2]] | Anna|
#+END:
here you see the duplication one time per processing
#+name: my-table-name1
#+BEGIN: columnview :id global :match "TODO={.+}-TODO=\"QUIT\"-T
inconsistency for the affiliated keyword of a dynamic block
Hi orgmode folks,
There is a special case that might need a clarification in the orgmode
implementation and/or the org-syntax [0]
The affiliated keyword, when it's before a dynamic block [1] it does not
work.
Example:
#+NAME: test
#+BEGIN: something-that-generates-a-table
| State | ID | Task | RESPONSIBLE |
|---++-+-|
| TODO | T1 | [[file:/tmp/affiliated-keyword-dynamic-block.org::*My
task][My task]] | Laura |
| TODO | T2 |
[[file:/tmp/affiliated-keyword-dynamic-block.org::*Task2][Task2]] |
Anna |
#+END:
It must be
#+BEGIN: something-that-generates-a-table
#+NAME: test
| State | ID | Task | RESPONSIBLE |
|---++-+-|
| TODO | T1 | [[file:/tmp/affiliated-keyword-dynamic-block.org::*My
task][My task]] | Laura |
| TODO | T2 |
[[file:/tmp/affiliated-keyword-dynamic-block.org::*Task2][Task2]] |
Anna |
#+END:
But right now, this is not available for org-ql, org-kanban, propview
(the things I am using)
Tested with orgmode version 9.7.10, org-ql 20241107.345 and org-kanban
cb96fa3ae5 source
So It needs to be after the dynamic block declaration; and that forces
all dynamic block to handle that kind of construction.
I think it is reasonable to say that a NAME given before a BEGIN dynamic
block element, applies to the thing that the dynamic block generates
The ability to clearly identify elements of exported html document is
nice to improve the visibility of things, for example here I experienced
how a table that represents a kanban might be better visualized using
css and js [2]
Coming back to the org syntax, I suspect that the table rows are not an
exception, #+NAME before table rows is specifically what I am using to
identify the table, and what does not work when there is in the middle
the dynamic block
#+begin_src diff
-With the exception of comments, clocks, headings, inlinetasks, items,
node properties, planning, property drawers, sections, and table rows,
every other element type can be assigned attributes.
+With the exception of comments, clocks, headings, inlinetasks, items,
node properties, planning, property drawers, and sections, every other
element type can be assigned attributes.
#+end_src
Cheers,
pinmacs
[0] section 4.3.8.2 https://orgmode.org/worg/org-syntax.html#Keywords
[1] https://orgmode.org/manual/Dynamic-Blocks.html
[2] (see screenshot in part 3, source shared too)
https://github.com/gizmomogwai/org-kanban/issues/50#issuecomment-2719546145#+TODO: TODO DONE
#+COLUMNS: %TODO(State) %CUSTOM_ID(ID) %ITEM(Task) %RESPONSIBLE
# #+EXPORT_FILE_NAME: /tmp/org-kanban
#+TITLE: org-kanban html example
#+AUTHOR: Name
#+ATTR_HTML: :id abstract
#+begin_abstract
In this example I test different dynamic blocks and NAME keyword
#+end_abstract
#+OPTIONS: prop:t toc:nil tags:not-in-toc d:(not "BACKLINKS" not "TRACE")
#+LANGUAGE: en
#+TOC: headlines 3
run these exports to test:
#+name: sourceblock_created_2025-03-12_14-06-44
#+begin_src emacs-lisp
(org-dblock-update t)
(org-html-export-to-html)
(org-gfm-export-to-markdown)
#+end_src
* Panel
** columnview
columnview works fine for =NAME= and =CAPTION=
#+BEGIN: columnview :id global :match "TODO={.+}-TODO=\"QUIT\"-TODO=\"DONE\"" :link t
#+NAME: test
#+CAPTION: Table with columnview
| State | ID | Task| RESPONSIBLE |
|---++-+-|
| TODO | T1 | [[file:/tmp/affiliated-keyword-dynamic-block.org::*My task][My task]] | Laura |
| TODO | T2 | [[file:/tmp/affiliated-keyword-dynamic-block.org::*Task2][Task2]] | Anna|
#+END:
** org-ql
org-ql does not work with =NAME= and =CAPTION=
# TODO caption keyword not working neither after begin neither after end
#+CAPTION: Table with org-ql
#+BEGIN: org-ql :query "todo:" :columns ((todo "State") ((property "CUSTOM_ID") "ID") (heading "Task") ((property "RESPONSIBLE") "Responsible"))
| State | ID | Task| Responsible |
|---++-+-|
| TODO | T1 | [[My task][My task]] | Laura |
| TODO | T2 | [[Task2][Task2]] | Anna|
#+END
** propview
org-ql does not work with =NAME= and =CAPTION=
I use this custom function sometimes to evaluate a link using that feature from propview
#+name: sourceblock_created_2025-03-12_14-06-12
#+begin_src emacs-lisp
(defun __item-cid ()
"link for propview when using CUSTOM_ID"
(concat "[[#" CUSTOM_ID "][" ITEM "]]"))
#+end_src
#+RESULTS: sourceblock_created_2025-03-12_14-06-12
# propview allows CAPTION keyword if it is before end, but not after begin
# anyway, the caption does not render fine
#+BEGIN: propview :scope ("./org-kanban.org") :match "TODO={.+}-TODO=\"QUIT\"-TODO=\"DONE\"" :noquote all :cols (TODO CUSTOM_ID (__item-cid) RESPONSIBLE) :coln
[PATCH] org-link: Add async-shell link
Hi, I see no async-shell link and I propose the following one, see patch attached To avoid any problem with copyright, yesterday I sent my copyright assignment FSF [1] Cheers, pinmacs [1] email Subject: Pedro Vilchez Blanco; From: pinmacs; Date: 2025-05-23 19:22:02 (UTC) From 5b365ea9d5a63c7bc9363e45feb269ff71f05e39 Mon Sep 17 00:00:00 2001 From: pinmacs Date: Fri, 23 May 2025 15:53:24 +0200 Subject: [PATCH] org-link: Add async-shell link * lisp/ol.el (org-link) renamed from org-link--open-shell to org-link--execute-shell-command added wrapper function org-link--open-shell added wrapper function org-link--open-async-shell added async-shell link --- etc/ORG-NEWS | 5 + lisp/ol.el | 13 +++-- 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 62502a678..4cfd436d5 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -163,6 +163,11 @@ You can now create links to =shortdoc= documentation groups for Emacs Lisp functions (see =M-x shortdoc-display-group=). Requires Emacs 28 or newer. +*** =ol.el: New =async-shell= link type + +You can now create links to execute programs asynchronously. This +means Emacs will not freeze while waiting for the link to execute. + *** Some navigation commands can now be repeated When ~repeat-mode~ is turned on, the following navigation commands can diff --git a/lisp/ol.el b/lisp/ol.el index 5a87f6e5d..42538dc7e 100644 --- a/lisp/ol.el +++ b/lisp/ol.el @@ -2299,8 +2299,8 @@ string\"." (browse-url (concat scheme ":" url) arg "shell" link type -(defun org-link--open-shell (path _) - "Open a \"shell\" type link. +(defun org-link--execute-shell-command (path async) + "Open a \"shell\" or \"async-shell\" type link. PATH is the command to execute, as a string." (if (or (and (org-string-nw-p org-link-shell-skip-confirm-regexp) (string-match-p org-link-shell-skip-confirm-regexp path)) @@ -2317,7 +2317,16 @@ PATH is the command to execute, as a string." clean-buffer-list-kill-buffer-names (user-error "Abort"))) +(defun org-link--open-shell (path _) + "Follow a \"shell\" link by running PATH synchronously." + (org-link--execute-shell-command path nil)) + +(defun org-link--open-async-shell (path _) + "Follow an \"async-shell\" link by running PATH asynchronously." + (org-link--execute-shell-command path t)) + (org-link-set-parameters "shell" :follow #'org-link--open-shell) +(org-link-set-parameters "async-shell" :follow #'org-link--open-async-shell) ;;; Interactive Functions -- 2.39.5 OpenPGP_0x9D64597C3A982DCA.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH] org-link: Add async-shell link
sorry, I did a small typo in the NEWS file, attached new version On 2025-05-24 18:31, pinm...@cas.cat wrote: Hi, I see no async-shell link and I propose the following one, see patch attached To avoid any problem with copyright, yesterday I sent my copyright assignment FSF [1] Cheers, pinmacs [1] email Subject: Pedro Vilchez Blanco; From: pinmacs; Date: 2025-05-23 19:22:02 (UTC) From 8cfc9cf1bea8a6d03d705ac4b96e8198f5f335e4 Mon Sep 17 00:00:00 2001 From: pinmacs Date: Fri, 23 May 2025 15:53:24 +0200 Subject: [PATCH] org-link: Add async-shell link * lisp/ol.el (org-link) renamed from org-link--open-shell to org-link--execute-shell-command added wrapper function org-link--open-shell added wrapper function org-link--open-async-shell added async-shell link --- etc/ORG-NEWS | 5 + lisp/ol.el | 13 +++-- 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 62502a678..4d0088bfa 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -163,6 +163,11 @@ You can now create links to =shortdoc= documentation groups for Emacs Lisp functions (see =M-x shortdoc-display-group=). Requires Emacs 28 or newer. +*** =ol.el=: New =async-shell= link type + +You can now create links to execute programs asynchronously. This +means Emacs will not freeze while waiting for the link to execute. + *** Some navigation commands can now be repeated When ~repeat-mode~ is turned on, the following navigation commands can diff --git a/lisp/ol.el b/lisp/ol.el index 5a87f6e5d..42538dc7e 100644 --- a/lisp/ol.el +++ b/lisp/ol.el @@ -2299,8 +2299,8 @@ string\"." (browse-url (concat scheme ":" url) arg "shell" link type -(defun org-link--open-shell (path _) - "Open a \"shell\" type link. +(defun org-link--execute-shell-command (path async) + "Open a \"shell\" or \"async-shell\" type link. PATH is the command to execute, as a string." (if (or (and (org-string-nw-p org-link-shell-skip-confirm-regexp) (string-match-p org-link-shell-skip-confirm-regexp path)) @@ -2317,7 +2317,16 @@ PATH is the command to execute, as a string." clean-buffer-list-kill-buffer-names (user-error "Abort"))) +(defun org-link--open-shell (path _) + "Follow a \"shell\" link by running PATH synchronously." + (org-link--execute-shell-command path nil)) + +(defun org-link--open-async-shell (path _) + "Follow an \"async-shell\" link by running PATH asynchronously." + (org-link--execute-shell-command path t)) + (org-link-set-parameters "shell" :follow #'org-link--open-shell) +(org-link-set-parameters "async-shell" :follow #'org-link--open-async-shell) ;;; Interactive Functions -- 2.39.5 OpenPGP_0x9D64597C3A982DCA.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH] org-link: Add async-shell link
On 2025-06-08 14:11, Ihor Radchenko wrote: pinmacs writes: I see no async-shell link and I propose the following one, see patch attached ... +*** =ol.el=: New =async-shell= link type + +You can now create links to execute programs asynchronously. This +means Emacs will not freeze while waiting for the link to execute. Thanks for the patch, but I am not sure why a new link type is necessary. You can simply append & to the "path" and the existing shell: link will be run asynchronously. Example: Oh, that's true, works, thanks! And with that syntax I can place any space that I want, without using the more typical link format [1] [[shell: inkscape &]] but inkscape &> [1] https://orgmode.org/org.html#Hyperlinks
