[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question regarding org-capture-bookmark and org-bookmark-names-plist
From: |
Tim Wichmann |
Subject: |
Re: Question regarding org-capture-bookmark and org-bookmark-names-plist |
Date: |
Thu, 08 Feb 2024 21:58:45 +0100 |
User-agent: |
mu4e 1.10.0; emacs 29.1 |
Dear Ihor,
Ihor Radchenko <yantar92@posteo.net> writes:
>> My question: Is this the intended way to suppress bookmark creation?
>
> I think so.
Great!
> We first introduced `org-capture-bookmark' and only then added
> `org-bookmark-names-plist'. Maybe we should obsolete
> `org-capture-bookmark' to avoid confusion.
Thanks for the clarification. Obsoleting `org-capture-bookmark' sounds
good, as the variable does not add new functionality which can not be
achieved with `org-bookmark-names-plist' already.
>> ...(Note, moreover, that currently
>> the :last-capture-marker bookmark is created even in case
>> `org-capture-bookmark' is set to nil, see `org-refile'.)
>
> May you elaborate? Are you sure that it is still the case on the latest main?
I double checked in newest version of defun `org-refile' in main branch:
The bookmark for :last-capture-marker is set independently of the value
of `org-capture-bookmark'. The corresponding code looks like this:
---[snip: org-refile.el, line 608 ff.]---
(when (bound-and-true-p org-capture-is-refiling)
(let ((bookmark-name (plist-get org-bookmark-names-plist
:last-capture-marker)))
(when bookmark-name
(condition-case err
(bookmark-set bookmark-name)
---[end snip]---
I would have expected that this bookmark is not set in case
`org-capture-bookmark' is set to nil, something like this:
---[snip]---
(when (bound-and-true-p org-capture-is-refiling)
(when org-capture-bookmark
(let ((bookmark-name (plist-get org-bookmark-names-plist
[...]
---[end snip]---
But, when obsoleting `org-capture-bookmark', this problem is solved
anyhow: Bookmark creation can be fully controlled using the plist
variable (and only there).
So, I vote for obsoleting `org-capture-bookmark'.
Thanks again for your help!
Best regards,
Tim.