[PATCH] lisp/org-capture.el: Add hook & hook options to org-capture
* lisp/org-capture.el: (org-capture-templates): Document the new template options. (org-capture-before-view-hook): Add new hook for parity with the template options. (org-capture): Implement the new template options. (org-capture-finalize): Implement the new template options. (org-capture-kill): Remove unneeded line. * doc/org-manual.org (Template elements): Document the new template options This change comes from my personal config, where I use e.g. the option `:before-finalize-hook' to capture an task automatically, whenever I capture using a certain template. --- doc/org-manual.org | 21 etc/ORG-NEWS| 26 ++ lisp/org-capture.el | 123 +++- 3 files changed, 124 insertions(+), 46 deletions(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index 2c54fde87..5efc2d797 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -7817,6 +7817,27 @@ Now lets look at the elements of a template definition. Each entry in - ~:refile-targets :: Temporarily set ~org-refile-targets~ to the value of this property. + - ~:before-view-hook~ :: + +Hook that is run right after the capture buffer is made current. +The buffer is still narrowed. + + - ~:prepare-finalize-hook~ :: + +Hook that is run before the finalization starts. +The capture buffer is current and still narrowed. + + - ~:before-finalize-hook~ :: + +Hook that is run right before a capture process is finalized. +The capture buffer is still current when this hook runs and it is +widened to the entire buffer. + + - ~:after-finalize-hook~ :: + +Hook that is run right after a capture process is finalized. +Suitable for window cleanup. + Template expansion :PROPERTIES: :DESCRIPTION: Filling in information about time and context. diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 5a94e737e..25441027f 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -63,6 +63,32 @@ list of various table options (between brackets in LaTeX export), since certain tabular environments, such as longtblr of the tabularray LaTeX package, provides this structure. +*** New hook =org-capture-before-view-hook= for =org-capture= before view + +Hook that is run right after the capture buffer is made current. +The buffer is still narrowed. + +*** New option =:before-view-hook= for =org-capture= + +Hook that is run right after the capture buffer is made current. +The buffer is still narrowed. + +*** New option =:prepare-finalize-hook= for =org-capture= + +Hook that is run before the finalization starts. +The capture buffer is current and still narrowed. + +*** New option =:before-finalize-hook= for =org-capture= + +Hook that is run right before a capture process is finalized. +The capture buffer is still current when this hook runs and it is +widened to the entire buffer. + +*** New option =:after-finalize-hook= for =org-capture= + +Hook that is run right after a capture process is finalized. +Suitable for window cleanup. + ** New functions and changes in function arguments *** New function ~org-element-cache-map~ for quick mapping across Org elements diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 5195b785e..27dd72ef8 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -235,64 +235,77 @@ template The template for creating the capture item. The rest of the entry is a property list of additional options. Recognized properties are: - :prependNormally newly captured information will be appended at - the target location (last child, last table line, - last list item...). Setting this property will - change that. + :prepend Normally newly captured information will be appended at +the target location (last child, last table line, +last list item...). Setting this property will +change that. - :immediate-finish When set, do not offer to edit the information, just - file it away immediately. This makes sense if the - template only needs information that can be added - automatically. + :immediate-finish When set, do not offer to edit the information, just +file it away immediately. This makes sense if the +template only needs information that can be added +automatically. - :jump-to-captured When set, jump to the captured entry when finished. + :jump-to-captured When set, jump to the captured entry when finished. - :refile-targets When exiting capture mode via `org-capture-refile', the - variable `org-refile-targets' will be temporarily bound - to the value of this property. + :refile-targetsWhen exiting capture mode via `org-capture-refile', the +variable
Re: [PATCH] Add support for $…$ latex fragments followed by a dash
Rudolf Adamkovič writes: > João Pedro de Amorim Paula writes: > >> On 01 February 2022 22:00, Rudolf Adamkovič wrote: >> >>> Me, I cannot use any of these "pretty" features because, simply put, >>> they break plain text. For example, they cause misaligned tables and >>> make the text overflow the fill column, which I keep at 72 columns. >> >> […] there are fonts that enforce Unicode (all characters, from what I >> understand, Unicode included) characters to be exactly 1 unit width, >> i.e. Unicode characters are the same widths as other characters. At >> least I can guarantee that any of the Term (all characters are the >> same length, but has ligatures) or Fixed (same as Term but no >> ligatures) for Iosekva [1] have this given property. >> >> [1] https://typeof.net/Iosevka/ > > Thank you for sharing! I use the amazing "Hack" typeface [1]. Then, I > fail to understand how the font changes the fact that Org breaks "the > promise of plain text" in this regard. > > For example, Org can hide its emphasis markers. Later, one opens the > file in another editor and sees the truth. The lines go over the fill > column, the tables have misaligned columns, and so on. > The promise of plain text has no inherent promise regarding alignment, line wrapping etc. The promise of plain text is simply that - a promise that org files will be just plain text rather than some application specific format like many other systems (MS Word, LibreOffice, etc). Provided you can still edit the file with a plain text editor, org has not broken its promise. Ironically, it is this plain text basis of org files which makes on-going support of $..$ (and any extension) so problematic. Without this restriction, org files could have a format where elements were 'tagged' to remove ambiguity and simplify the parsing process. However, this would of course mean that either you had to edit the file within org mode or you would have to be intimately familiar with the internal structure of org mode files and use an editor which made editing/updating the internal structure possible. To be very clear, I am NOT advocating that org should adopt some form of internal tagging or structure. I'm only attempting to highlight that having a system which aims to maintain the data source in plain text comes at a cost. In LaTex et. al. $..$ works well because $ is a special character. If you want a literal $, you have to escape it. In org, $ is not a special character. This means we need complex regular expressions in order to identify when $ is being used for LaTex specific markup and when it is being used in other contexts (e.g. literal $ sign, variable name). These regular expressions are difficult to get right, error prone and above all, incur a significant performance hit. Extending the syntax further to support $..$- simply makes the situation worse by adding further complexity. So far, all the arguments against removal of support for $..$ are based on inconvenience and reduced readability associated with the alternatives. Both legitimate concerns. For many, the proposed change may seem to be just inconvenient change for no real purpose because they don't deal with the complexities inherent in making $..$ work and for others, change is something they would always prefer to avoid. In this instance, I feel we really need to listen to those who put in such a dedicated effort in maintaining org mode and accept their position that sustaining $..$ syntax going forward is problematic and focus on what can be done to mitigate the impact from this change, make the alternative syntax more convenient and address the readability issues.
Re: [PATCH] org-list-send-item: allow dest to be a buffer position
Ihor Radchenko writes: >> Passing an integer representing a buffer position to org-list-send-item >> was failing because of the string-match-p, so here's something that lets >> integers skip that part. I have copyright assignment papers on file. > LGTM! Would you mind supplying a test for this function? Sure! Here's the new patch that includes the change and tests for the different kinds of input accepted by org-list-send-item. Sacha lisp/org-list.el: org-list-send-item: allow dest to be a buffer position * lisp/org-list.el (org-list-send-item): Check if dest is a string before matching it, to allow dest to be a buffer position. * testing/lisp/test-org-list.el (test-org-list/send-item): Add tests --- lisp/org-list.el | 2 +- testing/lisp/test-org-list.el | 64 +++ 2 files changed, 65 insertions(+), 1 deletion(-) diff --git a/lisp/org-list.el b/lisp/org-list.el index 3533c8319..f1ab2ca76 100644 --- a/lisp/org-list.el +++ b/lisp/org-list.el @@ -1442,7 +1442,7 @@ (defun org-list-send-item (item dest struct) (save-excursion (goto-char (org-list-get-last-item item struct prevs)) (point-at-eol))) -((string-match-p "\\`[0-9]+\\'" dest) +((and (stringp dest) (string-match-p "\\`[0-9]+\\'" dest)) (let* ((all (org-list-get-all-items item struct prevs)) (len (length all)) (index (mod (string-to-number dest) len))) diff --git a/testing/lisp/test-org-list.el b/testing/lisp/test-org-list.el index 3689a172f..e21409ca5 100644 --- a/testing/lisp/test-org-list.el +++ b/testing/lisp/test-org-list.el @@ -900,6 +900,70 @@ (ert-deftest test-org-list/insert-item () (org-insert-item) (buffer-string) +(ert-deftest test-org-list/send-item () + "Test `org-list-send-item' specifications." + ;; Move to beginning + (should + (equal "- item3\n- item1\n- item2\n" + (org-test-with-temp-text + "- item1\n- item2\n- item3\n" +(org-list-send-item (caar (last (org-list-struct))) +'begin (org-list-struct)) +(buffer-string + ;; Move to beginning with child item + (should + (equal "- item3\n - item4\n- item1\n- item2\n" + (org-test-with-temp-text + "- item1\n- item2\n- item3\n - item4\n" +(org-list-send-item (car (nth 2 (org-list-struct))) +'begin (org-list-struct)) +(buffer-string + ;; Move to end + (should + (equal "- item2\n- item3\n - item4\n- item1\n - item1child\n" + (org-test-with-temp-text + "- item1\n - item1child\n- item2\n- item3\n - item4\n" +(org-list-send-item (car (nth 0 (org-list-struct))) +'end (org-list-struct)) +(buffer-string + ;; Move to item number by string should move the item before the specified one + (should + (equal "- item2\n- item1\n - item1child\n- item3\n- item4\n- item5\n" + (org-test-with-temp-text + "- item1\n - item1child\n- item2\n- item3\n- item4\n- item5\n" +(org-list-send-item (car (nth 0 (org-list-struct))) +"3" (org-list-struct)) +(buffer-string + ;; Move to item number by position should move the item before the specified one + (should + (equal "- item2\n- item1\n - item1child\n- item3\n- item4\n- item5\n" + (org-test-with-temp-text + "- item1\n - item1child\n- item2\n- item3\n- item4\n- item5\n" +(re-search-forward "item3") +(org-list-send-item (car (nth 0 (org-list-struct))) +(point-at-bol) (org-list-struct)) +(buffer-string + ;; Delete + (should + (equal "- item1\n - item1child\n- item2\n- item4\n- item5\n" + (org-test-with-temp-text + "- item1\n - item1child\n- item2\n- item3\n- item4\n- item5\n" +(re-search-forward "item3") +(org-list-send-item (point-at-bol) +'delete (org-list-struct)) +(buffer-string + ;; Kill + (let ((kill-ring nil)) +(org-test-with-temp-text +"- item1\n - item1child\n- item2\n- item3\n - item3child\n- item4\n- item5\n" + (re-search-forward "item3") + (org-list-send-item (point-at-bol) + 'kill (org-list-struct)) + (should (equal "- item1\n - item1child\n- item2\n- item4\n- item5\n" + (buffer-string))) + (should (equal "item3\n - item3child" + (current-kill 0 t)) + (ert-deftest test-org-list/repair () "Test `org-list-repair' specifications." ;; Repair indentation. -- 2.25.1
Re: Minor patch for org-attach.el
> I pushed this to the development branch 'main' of Org. Perfect, thanks, Stefan
Re: Minor patch for org-attach.el
Stefan Monnier writes: > Here's a patch which cleans up some magic numbers in > `org-attach.el` and gets rif of the use of the second arg of `commandp`, > by making `org-attach-commands` accept any commands (including keyboard > macros). > > > Stefan > > > diff --git a/lisp/org/org-attach.el b/lisp/org/org-attach.el > index 36c21b7021..bba7fd7690 100644 > --- a/lisp/org/org-attach.el > +++ b/lisp/org/org-attach.el > @@ -314,14 +314,14 @@ org-attach >(concat (mapcar #'caar org-attach-commands) > (message msg) > (while (and (setq c (read-char-exclusive)) > - (memq c '(14 16 22 134217846))) > + (memq c '(?\C-n ?\C-p ?\C-v ?\M-v))) > (org-scroll c t))) > (and (get-buffer "*Org Attach*") (kill-buffer "*Org Attach*" >(let ((command (cl-some (lambda (entry) > (and (memq c (nth 0 entry)) (nth 1 entry))) > org-attach-commands))) > - (if (commandp command t) > - (call-interactively command) > + (if (commandp command) > + (command-execute command) > (error "No such attachment command: %c" c)) > > (defun org-attach-dir ( create-if-not-exists-p no-fs-check) Thanks Stefan! I pushed this to the development branch 'main' of Org. Bye, -- Marco
Minor patch for org-attach.el
Here's a patch which cleans up some magic numbers in `org-attach.el` and gets rif of the use of the second arg of `commandp`, by making `org-attach-commands` accept any commands (including keyboard macros). Stefan diff --git a/lisp/org/org-attach.el b/lisp/org/org-attach.el index 36c21b7021..bba7fd7690 100644 --- a/lisp/org/org-attach.el +++ b/lisp/org/org-attach.el @@ -314,14 +314,14 @@ org-attach (concat (mapcar #'caar org-attach-commands) (message msg) (while (and (setq c (read-char-exclusive)) - (memq c '(14 16 22 134217846))) + (memq c '(?\C-n ?\C-p ?\C-v ?\M-v))) (org-scroll c t))) (and (get-buffer "*Org Attach*") (kill-buffer "*Org Attach*" (let ((command (cl-some (lambda (entry) (and (memq c (nth 0 entry)) (nth 1 entry))) org-attach-commands))) - (if (commandp command t) - (call-interactively command) + (if (commandp command) + (command-execute command) (error "No such attachment command: %c" c)) (defun org-attach-dir ( create-if-not-exists-p no-fs-check)
Re: [PATCH] Add support for $…$ latex fragments followed by a dash
João Pedro de Amorim Paula writes: > On 01 February 2022 22:00, Rudolf Adamkovič wrote: > >> Me, I cannot use any of these "pretty" features because, simply put, >> they break plain text. For example, they cause misaligned tables and >> make the text overflow the fill column, which I keep at 72 columns. > > […] there are fonts that enforce Unicode (all characters, from what I > understand, Unicode included) characters to be exactly 1 unit width, > i.e. Unicode characters are the same widths as other characters. At > least I can guarantee that any of the Term (all characters are the > same length, but has ligatures) or Fixed (same as Term but no > ligatures) for Iosekva [1] have this given property. > > [1] https://typeof.net/Iosevka/ Thank you for sharing! I use the amazing "Hack" typeface [1]. Then, I fail to understand how the font changes the fact that Org breaks "the promise of plain text" in this regard. For example, Org can hide its emphasis markers. Later, one opens the file in another editor and sees the truth. The lines go over the fill column, the tables have misaligned columns, and so on. Rudy [1] https://sourcefoundry.org/hack/ -- "Strange as it may sound, the power of mathematics rests on its evasion of all unnecessary thought and on its wonderful saving of mental operations." -- Ernst Mach, 1838-1916 Rudolf Adamkovič [he/him] Studenohorská 25 84103 Bratislava Slovakia
Re: Lazy load of org-protocol
On 2/6/2022 8:42 AM, Max Nikulin wrote: On 06/02/2022 01:27, Jim Porter wrote: As a result, I think a good first step might be to add support for "--funcall" to emacsclient, just like the regular emacs binary. (The "-f" shorthand won't work though, since emacsclient already uses that for "--server-file"). This would simplify the `message-mailto' case above and would also allow org-protocol to do something similar: emacsclient --funcall org-protocol-capture %u No, --funcall is just a sugar for --eval '(func)' that does not contain arbitrary input, but func has no access to other arguments and it is the real problem. Oh right, of course. The emacsclient case with `(message-mailto \"%u\")' threw me off, but `message-mailto' works differently depending on whether you pass it an arg or not. I think, the solution is to add -arg command to emacs server protocol that pushes its argument to a list and extend -exec command that would make such list available as argv or as `command-line-args-left' for evaluated expression. Of course, emacsclient option parser should be modified as well to support --arg option emacsclient --eval '(func)' --arg 1 2 3 emacsclient --eval '(func)' --arg -- 1 2 3 and maybe even for multiple eval+arg pairs emacsclient --eval '(f1)' --arg 'a1' --eval '(f2)' --arg 'a2' 'a3' I think something like this could work, so long as the arguments can be forwarded correctly in the alternate editor case. If I understand how emacsclient handles --eval, I think that might work, but it would still require writing Lisp functions that know how to handle argv or `command-line-args-left'. I'm also not totally sure how safe/sensible that is when the arguments aren't from the invocation of emacs itself, but from emacsclient (and thus, the args could be updated multiple times throughout a session). It probably wouldn't actually break anything, but it does seem a bit surprising to me... Maybe another option would be to add an --apply argument that really *does* consume the other command-line args and turns them into a properly-quoted function call. Roughly speaking, it would turn this: emacs --apply func foo bar baz into this: (apply #'func '(foo bar baz)) This would work effectively like how I momentarily thought --funcall works. Then you could say: emacsclient --apply org-protocol-capture %u # or ... emacs --apply org-protocol-capture %u This would also mean that the `message-mailto' function from Gnus doesn't need to care about `command-line-args-left' anymore, which would simplify it somewhat. And this could be useful in general for programmatically interacting with Emacs, since users would be able to pass arbitrary strings to Emacs Lisp functions without having to worry (as much) about sanitizing the strings first. The proper place to discuss idea is emacs-devel list, but I am afraid that without a patch it will be just buried. I don't know if an actual patch would be a strict prerequisite for posting to emacs-devel, but it's probably wise to have a clear, detailed proposal first. I think it's easier to get everyone on board with an idea if it's easy for them to see how all the details work up-front. - Jim
Re: Request For Approval To Contribute To Org Mode
On Sun, Feb 6, 2022 at 1:28 PM Samuel Banya wrote: > > Hey there, > > I can't find my previous email thread, but I asked if anyone could approve my > Sourcehub registration to be able to make commits to Org Mode's repo going > forward. > > I wasn't sure if Bastien was around to do this though, so I wanted to check > in about this. > AFAIK only Basiten can approve this, added to this thread.
Request For Approval To Contribute To Org Mode
Hey there, I can't find my previous email thread, but I asked if anyone could approve my Sourcehub registration to be able to make commits to Org Mode's repo going forward. I wasn't sure if Bastien was around to do this though, so I wanted to check in about this. Thanks, Samuel Banya
Re: Shell SRC blocks under Windows
Matt writes: > On Sat, 05 Feb 2022 17:22:29 -0500 Matt wrote > > > > But I'm not sure if I'm halfway there with "sh"? I need to run the > > > following MSYS2 command AND switch between two arguments (for building > > > Emacs). > > > > > > \MSYS2\msys2_shell.cmd -mingw64 > > > > > > and > > > > > > \MSYS2\msys2_shell.cmd -msys. > > > > > > How could I achieve this within a src block? > > > > I'm not sure I follow you here. Can you please describe what > > you're trying to do and the system you're using (e.g. Windows, > > GNU/Linux, Haiku) as well the shell used to run the Emacs instance > > you're doing this in? > > > Excuse me. Obviously you're using Windows. :) Yes I have to, but please don't mind, thank you for your interest. :-)
Re: Lazy load of org-protocol
On 06/02/2022 01:27, Jim Porter wrote:
On 2/5/2022 3:54 AM, Max Nikulin wrote:
etc/emacsclient-mail.desktop in the Emacs repo does this.) The command
to use for a new Emacs instance is simple:
emacs -f message-mailto %u
However, doing this for emacsclient is harder:
emacsclient --alternate-editor= --create-frame --eval
"(message-mailto \\"%u\\")"
There's no problem with "--alternate-editor=" and "--create-frame", but
the fact that emacsclient requires evaling the function call that way
is: if %u holds a string with quotation marks, this will break, and
worse, could even result in arbitrary code being executed. (In practice,
this is probably rare, since URLs are generally URL-encoded, and so
don't have literal quotes in them.)
Thank you for suggesting another use case.
Quoting issues was the reason why I started to search a better way.
There should be an easy and safe means to pass argument from command
line to evaluated expressions similar to shell
sh -c 'echo "$1"' example 'Hello, World!'
Some people could not even choose proper quotes for shell command:
https://www.reddit.com/r/emacs/comments/hhbcg7/emacsclient_eval_with_command_line_arguments/
https://stackoverflow.com/questions/8848819/emacs-eval-ediff-1-2-how-to-put-this-line-in-to-shell-script
First recipe and the accepted answer in second source solves the obvious
problem but they miss escaping for elisp expression. Another answer on
stackoverflow is more accurate, it suggests
quoted1=${1//\\/}; quoted1=${quoted1//\"/\\\"}
I suppose, these links is a good illustration that substitution of
arbitrary argument into lisp expression is harder than it should be to
help users to avoid security issues.
As a result, I think a good first step might be to add support for
"--funcall" to emacsclient, just like the regular emacs binary. (The
"-f" shorthand won't work though, since emacsclient already uses that
for "--server-file"). This would simplify the `message-mailto' case
above and would also allow org-protocol to do something similar:
emacsclient --funcall org-protocol-capture %u
No, --funcall is just a sugar for --eval '(func)' that does not contain
arbitrary input, but func has no access to other arguments and it is the
real problem.
I think, the solution is to add -arg command to emacs server protocol
that pushes its argument to a list and extend -exec command that would
make such list available as argv or as `command-line-args-left' for
evaluated expression. Of course, emacsclient option parser should be
modified as well to support --arg option
emacsclient --eval '(func)' --arg 1 2 3
emacsclient --eval '(func)' --arg -- 1 2 3
and maybe even for multiple eval+arg pairs
emacsclient --eval '(f1)' --arg 'a1' --eval '(f2)' --arg 'a2' 'a3'
The proper place to discuss idea is emacs-devel list, but I am afraid
that without a patch it will be just buried.
emacsclient --eval "(org-protocol-capture \\"%u\\")"
Due to quoting issues a small wrapper may be safer (modulo -a, -c)
emacsclient --eval "(require 'org-protocol)"
emacsclient -- "$@"
Re: Shell SRC blocks under Windows
On Sat, 05 Feb 2022 17:22:29 -0500 Matt wrote > > But I'm not sure if I'm halfway there with "sh"? I need to run the > > following MSYS2 command AND switch between two arguments (for building > > Emacs). > > > > \MSYS2\msys2_shell.cmd -mingw64 > > > > and > > > > \MSYS2\msys2_shell.cmd -msys. > > > > How could I achieve this within a src block? > > I'm not sure I follow you here. Can you please describe what you're trying > to do and the system you're using (e.g. Windows, GNU/Linux, Haiku) as well > the shell used to run the Emacs instance you're doing this in? > Excuse me. Obviously you're using Windows. :)
[PATCH] lisp/org-capture.el: Add hook & hook options to org-capture
* lisp/org-capture.el: (org-capture-templates): Document the new template options. (org-capture-before-view-hook): Add new hook for parity with the template options. (org-capture): Implement the new template options. (org-capture-finalize): Implement the new template options. (org-capture-kill): Remove unneeded line. * doc/org-manual.org (Template elements): Document the new template options This change comes from my personal config, where I use e.g. the option `:before-finalize-hook' to capture an task automatically, whenever I capture using a certain template. --- doc/org-manual.org | 21 etc/ORG-NEWS| 26 ++ lisp/org-capture.el | 123 +++- 3 files changed, 124 insertions(+), 46 deletions(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index 2c54fde87..5efc2d797 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -7817,6 +7817,27 @@ Now lets look at the elements of a template definition. Each entry in - ~:refile-targets :: Temporarily set ~org-refile-targets~ to the value of this property. + - ~:before-view-hook~ :: + +Hook that is run right after the capture buffer is made current. +The buffer is still narrowed. + + - ~:prepare-finalize-hook~ :: + +Hook that is run before the finalization starts. +The capture buffer is current and still narrowed. + + - ~:before-finalize-hook~ :: + +Hook that is run right before a capture process is finalized. +The capture buffer is still current when this hook runs and it is +widened to the entire buffer. + + - ~:after-finalize-hook~ :: + +Hook that is run right after a capture process is finalized. +Suitable for window cleanup. + Template expansion :PROPERTIES: :DESCRIPTION: Filling in information about time and context. diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 5a94e737e..25441027f 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -63,6 +63,32 @@ list of various table options (between brackets in LaTeX export), since certain tabular environments, such as longtblr of the tabularray LaTeX package, provides this structure. +*** New hook =org-capture-before-view-hook= for =org-capture= before view + +Hook that is run right after the capture buffer is made current. +The buffer is still narrowed. + +*** New option =:before-view-hook= for =org-capture= + +Hook that is run right after the capture buffer is made current. +The buffer is still narrowed. + +*** New option =:prepare-finalize-hook= for =org-capture= + +Hook that is run before the finalization starts. +The capture buffer is current and still narrowed. + +*** New option =:before-finalize-hook= for =org-capture= + +Hook that is run right before a capture process is finalized. +The capture buffer is still current when this hook runs and it is +widened to the entire buffer. + +*** New option =:after-finalize-hook= for =org-capture= + +Hook that is run right after a capture process is finalized. +Suitable for window cleanup. + ** New functions and changes in function arguments *** New function ~org-element-cache-map~ for quick mapping across Org elements diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 5195b785e..27dd72ef8 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -235,64 +235,77 @@ template The template for creating the capture item. The rest of the entry is a property list of additional options. Recognized properties are: - :prependNormally newly captured information will be appended at - the target location (last child, last table line, - last list item...). Setting this property will - change that. + :prepend Normally newly captured information will be appended at +the target location (last child, last table line, +last list item...). Setting this property will +change that. - :immediate-finish When set, do not offer to edit the information, just - file it away immediately. This makes sense if the - template only needs information that can be added - automatically. + :immediate-finish When set, do not offer to edit the information, just +file it away immediately. This makes sense if the +template only needs information that can be added +automatically. - :jump-to-captured When set, jump to the captured entry when finished. + :jump-to-captured When set, jump to the captured entry when finished. - :refile-targets When exiting capture mode via `org-capture-refile', the - variable `org-refile-targets' will be temporarily bound - to the value of this property. + :refile-targetsWhen exiting capture mode via `org-capture-refile', the +variable
Suggestion about org-num
I am not sure if this is the proper place to make this suggestion, and I know you are working hard, but there is a thing about /org-num-mode/ that I miss since day 1. To be a better asset in reading or studying directly from org-mode, I think it could be a good addition the numbered headlines to be positively determined. Now they can just be excluded (UNNUMBERED or skipped), one by one. For example, it would be helpful to use a PROPERTY like "*NUMBERED*" that would make /org-num-mode/ to affect just to the desired headlines and sub-headlines (inheritance is a good thing). Or if there is a *narrowed headline* to get numbered just what is on the screen. Problem: Now when I read some of my notes, I get things like this: /22.81.12.1./ Where just the /12.1/ would be useful to the reading (chapter 12, point 1), since the 22.81 is from unrelated notes to the studying. This happens too with book notes: the numbering of the headlines could even be the same than the numbering of the chapters of the book. Best regards, Ypo
Re: [PATCH] update ob-scheme to latest changes in geiser package
The patch appears to solve the real issue others already experience. See https://list.orgmode.org/20220205221049.ymkzevpc2ivlxwbc@bob-mtu/T/#t Dear Felipe, Could you kindly update the patch as requested by Max? Best, Ihor
Re: [PATCH] org-list-send-item: allow dest to be a buffer position
Sacha Chua writes: > Passing an integer representing a buffer position to org-list-send-item > was failing because of the string-match-p, so here's something that lets > integers skip that part. I have copyright assignment papers on file. LGTM! Would you mind supplying a test for this function? Best, Ihor
Re: [PATCH] org-agenda: Skip formatting if format string is ""
Samim Pezeshki writes:
> This commit prevents having extra spaces when the TODO format string is an
> empty string (""). It was not working properly, with this patch now it
> works correctly.
Thanks for the patch!
> (concat
> (substring x 0 (match-end 1))
> ...
> + (unless (string= org-agenda-todo-keyword-format "")
> + (format org-agenda-todo-keyword-format
> + (match-string 2 x))
> + ;; Remove `display' property as the icon could leak
> + ;; on the white space.
> + (org-add-props " " (org-plist-delete (text-properties-at 0 x)
> + 'display)))
> (substring x (match-end 3)))
>x)))
Your patch will unconditionally hide todo keywords in agenda even when
org-agenda-todo-keyword-format is not empty. This will happen because
(unless ...) form will only return the last " ", but never the keyword.
You should better wrap the (org-add-props ...) with another unless
condition.
Best,
Ihor
