Re: [BUG] org-num-skip-unnumbered is not respected if a org-mode file enables org-num-mode on startup [9.6.18 ( @ /home/drcxd/.emacs.d/elpa/org-9.6.18/)]

[Chang Xiaoduan]

Ihor Radchenko  writes:

>
> This is known.
> #+STARTUP options are handled before buffer-local variables take effect.
> See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57003
> Handled.
>

I have read the thread but I can not figure a solution. I tried to
search "early local" you proposed in the org-mode manual or Emacs manual
but find nothing related. So currently if I use STARTUP options to
enable org-num-mode on visiting the file, there is no way to make
org-num-mode apply file local variables such as `org-num-max-level'? Is
that right?

>
> Yup.
> Fixed on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=bfc0cb372

Thanks a lot.

Re: Translation of the Org mode manual (was: Translation of manuals (was: SES manual French translation))

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This is not true. We can generate a precise TeXinfo markup from Org
  > files even now using export snippets: @@texinfo:@@

I know that it is possible to convert Org format to Texinfo.  I am
raising a different issue.  I think we are miscommunicating.

The question is not whether Org can be translated to Texingo.  The
question is whether Org format can represent all the distinctions that
Texinfo represents.  Or, equivalently, is it possible to translate
Texinfo text to Org format and then back to Texinfo format without
losing any information?

Last I looked, that was not possible, because of the issue I
explained in my previous message.

If things have improved and Org format is now capable of doing this, I
will consider that good news.

  > Another question is that having native Org mode constructs for
  > manual-specific markup would make things less verbose and ad-hoc.

To handle GNU manuals using Org format would not require a feature
like that.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Link type for pdf-tools annotations

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías  writes:
>
>> Many times I need to "save" an annotation point in the pdf-tools
>> annotations buffer. So I defined a new link type and the function to
>> store it. The link is stored with the structure:
>>
>> [[pdf-annot:/path/to/file.pdf::annotation-date][file-name.pdf (annot. on p. 
>> page-number)]]
>>
>> The link opens the PDF and jumps to the specific annotation.
>
> You may also utilize `org-create-file-search-functions' and
> `org-execute-file-search-functions' to make an ordinary file: links
> works for the same purpose.

Thanks for the pointers. Note that in this use case I don't need to
search in the PDF file itself but in the pdf-annot-list-mode buffer that
is created via pdf-annot-list-annotations. This buffer is synchronized
with the PDF to which it is linked. What this link type does is visit
the pdf file (with pdf-tools), create the list of annotations and jump
to the specific annotation, by date.
pdf-annot-list-display-annotation-from-id highlights the specific list
annotation in the linked PDF (if necessary, moves to the corresponding
page), and opens the content of the annotation in another window
(interactively the function is executed by pressing SPC on the
annotation list at point). Storing the annotation date seemed like the
safest option to me, since the annotation id can change when adding new
annotations, each time the list is created. The typical scenario: when I
am consulting a PDF annotated by someone and I want to store the
location of some specific annotations. As there can be many annotations
per page, adding a simple bookmark to the page would not be enough
either.

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

Re: Link type for pdf-tools annotations

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Many times I need to "save" an annotation point in the pdf-tools
> annotations buffer. So I defined a new link type and the function to
> store it. The link is stored with the structure:
>
> [[pdf-annot:/path/to/file.pdf::annotation-date][file-name.pdf (annot. on p. 
> page-number)]]
>
> The link opens the PDF and jumps to the specific annotation.

You may also utilize `org-create-file-search-functions' and
`org-execute-file-search-functions' to make an ordinary file: links
works for the same purpose.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH v2] org-id: allow using parent's existing id in links to headlines

[Rick Lupton]

On Thu, 8 Feb 2024, at 1:02 PM, Ihor Radchenko wrote:
> I have some thoughts about rewording your changes to the manual and
> ORG-NEWS. See the attached patch on top of yours.

Thanks, makes sense -- wasn't sure whether to keep this as a separate patch or 
not, I have squashed into the attached updated version.

> [minor points on commit messages]

Fixed these.

> The new optional argument to a public function should be announced in 
> ORG-NEWS.

Added.

>> + (new-heading-level (if new-heading-container
>> +(+ 1 (org-element-property :level 
>> new-heading-container))
>
> What if new-heading-container is not a heading?
>
>> +  1)))
>> +(goto-char new-heading-position)
>
> This is err when container ends after narrowed region boundary.

Added checks for these.

>> +(defun org-link-precise-link-target ()
>> ...
>> +  (cond
>> +   (name
>> +(list name
>> +  name
>> +  (org-element-begin element)))
>
> It would make sense to use #+caption as default description when available.

Maybe... But I had a little look and it seems complicated, since caption is a 
parsed property, it's not clear to me how to get a plain string in a simple 
way. And there could be a long and a short caption, over multiple lines. If the 
caption is long, it wouldn't make a good link description anyway.

The current behaviour is the same as it was before, so maybe we can leave this 
as a future enhancement if wanted?


0001-lisp-org.el-org-insert-heading-Allow-specifying-head.patch
Description: Binary data


0002-org-id.el-Add-search-strings-inherit-parent-IDs.patch
Description: Binary data

Re: Question regarding org-capture-bookmark and org-bookmark-names-plist

[Tim Wichmann]

Dear Ihor,

Ihor Radchenko  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.

Re: Async Python src block behavior with :dir header property

[Bruno Barbier]

Ihor Radchenko  writes:

> Jack Kamm  writes:
>
>> On executing any python session block I am getting the following error
>> which I think is caused by the above:
>>
>>   Debugger entered--Lisp error: (void-variable buffer-name)
>
> That's a mystery.

It looks like 'when-let*' doesn't accept symbols without values; it
needs real bindings.  The form `let*' assigns nil when there are no
values, but, with `when-let*', assigning nil would make the whole
`when-let' fails.

Here is the expansion when using a symbol without a value, which
explains both the void-variable error and the compiler message:

   #+begin_src elisp :results scalar
 (macroexpand-all '(when-let* (new-var) 7))
   #+end_src

   #+RESULTS:
   : (let* ((new-var (and t new-var))) (if new-var 7))



Bruno

Re: Async Python src block behavior with :dir header property

[Ihor Radchenko]

Jack Kamm  writes:

> On executing any python session block I am getting the following error
> which I think is caused by the above:
>
>   Debugger entered--Lisp error: (void-variable buffer-name)

That's a mystery.

> Also, make shows a byte-compiler warning about this:
>
>   Compiling 
> /home/jack/src/org-mode/2024-01-async-file-results-dir/lisp/ob-core.el...
>   
>   In org-babel-session-buffer:
>   ob-core.el:785:15: Warning: reference to free variable ‘buffer-name’

But this is a real problem.
See the attached updated version of the patch set.

>From 1185e7a3569048b465b697fe173ce50a3ab7f0cc Mon Sep 17 00:00:00 2001
Message-ID: <1185e7a3569048b465b697fe173ce50a3ab7f0cc.1707406936.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Sat, 3 Feb 2024 16:47:57 +0100
Subject: [PATCH v2 1/3] org-babel-execute-src-block: Force :dir according to
 live session

* lisp/ob-core.el (org-babel-execute-src-block): Force eval directory
to follow live session buffer, if any.  This is consistent with what
we promise in the manual section "16.4 Environment of a Code
Block">Choosing a working directory.

Link: https://orgmode.org/list/87mssi8ht2@gmail.com
---
 lisp/ob-core.el | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 1de3af6ad..fd8d06c5d 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -840,14 +840,17 @@ (defun org-babel-execute-src-block ( arg info params executor-type)
 		 (dir (cdr (assq :dir params)))
 		 (mkdirp (cdr (assq :mkdirp params)))
 		 (default-directory
-		   (cond
-		((not dir) default-directory)
-		((member mkdirp '("no" "nil" nil))
-		 (file-name-as-directory (expand-file-name dir)))
-		(t
-		 (let ((d (file-name-as-directory (expand-file-name dir
-		   (make-directory d 'parents)
-		   d
+		  (cond
+		   ((not dir) default-directory)
+   ((when-let ((session (cdr (assq :session params
+  (when (org-babel-comint-buffer-livep session)
+(buffer-local-value 'default-directory (get-buffer session)
+		   ((member mkdirp '("no" "nil" nil))
+		(file-name-as-directory (expand-file-name dir)))
+		   (t
+		(let ((d (file-name-as-directory (expand-file-name dir
+		  (make-directory d 'parents)
+		  d
 		 (cmd (intern (concat "org-babel-execute:" lang)))
 		 result exec-start-time)
 	(unless (fboundp cmd)
-- 
2.43.0

>From 8799d747ab2983f43dab117713342dbc92c6fc16 Mon Sep 17 00:00:00 2001
Message-ID: <8799d747ab2983f43dab117713342dbc92c6fc16.1707406936.git.yanta...@posteo.net>
In-Reply-To: <1185e7a3569048b465b697fe173ce50a3ab7f0cc.1707406936.git.yanta...@posteo.net>
References: <1185e7a3569048b465b697fe173ce50a3ab7f0cc.1707406936.git.yanta...@posteo.net>
From: Jack Kamm 
Date: Wed, 31 Jan 2024 20:06:00 -0800
Subject: [PATCH v2 2/3] ob-comint: Make file results from async sessions
 respect :dir header

* lisp/ob-comint.el (org-babel-comint-async-filter): Set
default-directory before calling `org-babel-insert-result'

https://list.orgmode.org/875xz9o4nj.fsf@localhost/T/#t
---
 lisp/ob-comint.el | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lisp/ob-comint.el b/lisp/ob-comint.el
index 7d258ea0e..349524701 100644
--- a/lisp/ob-comint.el
+++ b/lisp/ob-comint.el
@@ -224,6 +224,8 @@ (defun org-babel-comint-async-filter (string)
 	 (file-callback org-babel-comint-async-file-callback)
 	 (combined-string (concat org-babel-comint-async-dangling string))
 	 (new-dangling combined-string)
+ ;; Assumes comint filter called with session buffer current
+ (session-dir default-directory)
 	 ;; list of UUID's matched by `org-babel-comint-async-indicator'
 	 uuid-list)
 (with-temp-buffer
@@ -248,7 +250,8 @@ (defun org-babel-comint-async-filter (string)
 (let* ((info (org-babel-get-src-block-info))
(params (nth 2 info))
(result-params
-(cdr (assq :result-params params
+(cdr (assq :result-params params)))
+   (default-directory session-dir))
   (org-babel-insert-result
(funcall file-callback
 (nth
@@ -291,7 +294,8 @@ (defun org-babel-comint-async-filter (string)
(let* ((info (org-babel-get-src-block-info))
   (params (nth 2 info))
   (result-params
-   (cdr (assq :result-params params
+   (cdr (assq :result-params params)))
+  (default-directory session-dir))
  

Re: Org mode version 9.7-pre (9.7-pre-n/a-g093879

[Ihor Radchenko]

Jason May  writes:

> This request was prompted by an issue encounted in org-journal, and it
> probably exists in org-roam and other similar packages.
>
> Ignoring blank lines sounds like a reasonable approach.

It is reasonable, but I am not convinced that it is important enough to
make changes to Org mode syntax.

Allowing blank lines may help with certain types of accidental edits - a
small fraction of possible accidental edits. The benefit is very small.
Too small, IMHO.

> For more significant syntax violations such as your example, perhaps
> org-entry-get and other functions should raise errors instead of
> silently returning nil?

That would require org-entry-get to try searching things that /look
like/ malformed property drawer. This will be (1) slower; (2) defeat the
purpose of changes introduced in Org 8.3
https://orgmode.org/worg/org-release-notes.html#orgaf78411

I am not in favor of such change.

> I'm going to investigate how it might be possible to initiate an org-
> lint if an exception situation was to arise in org-journal.

Org syntax is not restrictive. We deliberately allow people to write
arbitrary text that do not follow strict rules and Org still recognizes
such text as generic text with no special meaning. So, Org mode syntax
has no notion of exceptions.

There are of course common mistakes when writing Org markup. That's why
we have org-lint. However, org-lint is always suggestive - it is an
equivalent of compiler warnings.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] org-num-skip-unnumbered is not respected if a org-mode file enables org-num-mode on startup [9.6.18 ( @ /home/drcxd/.emacs.d/elpa/org-9.6.18/)]

[Ihor Radchenko]

Chang Xiaoduan  writes:

> I have been experimenting with org-num-mode recently. I find that if an
> org-mode file enables org-num-mode on startup by adding:
>
> ```emacs-lisp
> #+STARTUP: num
> ```
>
> and if there is a file local prop line:
>
> ```emacs-lisp
> # -*- org-num-skip-unnumbered: t; -*-
> ```

> then org-num-mode does not respect the file local variable, i.e., some
> headings with the `UNNUMBERED` property set to `t` still get their
> numbering. This also happens for `org-num-max-level` if it is set on the
> file local prop line. If I toggle org-num-mode after visiting the
> file, then org-num-mode respect those file local variables.

This is known.
#+STARTUP options are handled before buffer-local variables take effect.
See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57003
Handled.

> What's more, I have tried to remove the `STARTUP` keyword, so I can
> enable org-num-mode after visiting the file. However, without enabling
> org-num-mode on visiting the file, Emacs reports those file local
> variables as unsafe, though their values are safe, according to the
> documentation. I guess it is determined as unsafe because org-num-mode
> is not loaded.

Yup.
Fixed on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=bfc0cb372

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Org parse error [9.6.18 ( @ /Users/wangjian/.emacs.d/elpa/org-9.6.18/)]

[Ihor Radchenko]

Loki wang  writes:

> Emacs  : GNU Emacs 29.1 (build 1, aarch64-apple-darwin23.2.0, Carbon Version 
> 170 AppKit 2487.3)
>  of 2023-12-20
> Package: Org mode version 9.6.18 ( @ 
> /Users/wangjian/.emacs.d/elpa/org-9.6.18/)

Thanks for reporting!
May you also share the warning text? I am particularly looking for
"Backtrace:" part.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Unsolicited download of remote resources

[Ihor Radchenko]

Max Nikulin  writes:

>> [...]> The prompt is displayed twice because fetching is attempted twice 
>> - when
>> reading startup options and when initializing macros. This is
>> sub-optimal, but expected.
>
> Are names of macros necessary for some purpose before export is started?

With the current implementation of `org-get-title', yes.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Org may fetch remote content without asking user consent

[Ihor Radchenko]

Max Nikulin  writes:

> On 08/02/2024 00:10, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> 
>>> It is a bit more tricky. Current file may be remote as well. Browsers
>>> have concept of same origin for applying security and privacy measures.
>>> Org needs something similar.
>> 
>> May you please elaborate?
>
> Consider a file opened as /ssh:host:org/test.org that has
>
> #+setupfile: /ssh:host:org/include.org
>
> Formally it is a remote file, actually it resides on the same host as 
> the current document. Perhaps user consent is redundant.

`org--safe-remote-resource-p' checks the containing Org file as well, in
addition to #+included URL.

> ...
> or the user has /ssh:host:org/ in the list of safe URIs. So there is no 
> need to treat such coincidence in a special way.

I think that it is indeed good enough.

> I am not confident in proper policy though. When some URI matches a 
> pattern in the safe list, likely it is suitable for files created by the 
> user and it is not really safe to allow it for a mail message attachment.

May you elaborate?

> Default protection should not be excessively strict, otherwise users 
> will disable it completely.

Agree.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: help with gnus-icalendar.el and orgmode agenda

[Ihor Radchenko]

Ihor Radchenko  writes:

> <2024-02-22 18:30-20:00> is a valid timestamp. Agenda not handling it is
> an oversight that should be fixed.

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=62956196d

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] lisp/ol.el: Improve docstring

[Ihor Radchenko]

"Rick Lupton"  writes:

> On Sat, 3 Feb 2024, at 1:10 PM, Ihor Radchenko wrote:
>> In my testing, I used #+name: as link target.
>> However, what I missed is that #+name targets are matched even when
>> `org-link-search-must-match-exact-headline' is set to 'query-to-create.
>> The docstring is not accurate there and must be updated.
>
> How about this?

Thanks!
Applied, onto main, with minor amendment to the commit message.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f016545aa

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[BUG] org-num-skip-unnumbered is not respected if a org-mode file enables org-num-mode on startup [9.6.18 ( @ /home/drcxd/.emacs.d/elpa/org-9.6.18/)]

[Chang Xiaoduan]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Hello,

I have been experimenting with org-num-mode recently. I find that if an
org-mode file enables org-num-mode on startup by adding:

```emacs-lisp
#+STARTUP: num
```

and if there is a file local prop line:

```emacs-lisp
# -*- org-num-skip-unnumbered: t; -*-
```

then org-num-mode does not respect the file local variable, i.e., some
headings with the `UNNUMBERED` property set to `t` still get their
numbering. This also happens for `org-num-max-level` if it is set on the
file local prop line. If I toggle org-num-mode after visiting the
file, then org-num-mode respect those file local variables.

What's more, I have tried to remove the `STARTUP` keyword, so I can
enable org-num-mode after visiting the file. However, without enabling
org-num-mode on visiting the file, Emacs reports those file local
variables as unsafe, though their values are safe, according to the
documentation. I guess it is determined as unsafe because org-num-mode
is not loaded.

This can be reproduced by launching Emacs using `emacs -Q` and visiting
the following org-mode file:

```
# -*- org-num-skip-unnumbered: t; -*-

#+STARTUP: num

* Unnumbered Heading
:PROPERTIES:
:UNNUMBERED: t
:END:

* Numbered Heading
```

I expect that if I enable org-num-mode using the `STARTUP` keyword, it
will respect file local properties specified on the file local prop
line. Alternatively, Emacs should not report those file local variables
as unsafe if the org-num-mode is not enabled on startup.

Thank you

Xiaoduan

Emacs  : GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, 
cairo version 1.16.0)
 of 2023-08-30, modified by Debian
Package: Org mode version 9.6.18 ( @ /home/drcxd/.emacs.d/elpa/org-9.6.18/)

[FR] Org mode sr.ht project page: add familiar links for newcomers

[Ihor Radchenko]

Hi,

Sourcehut is known for unusual interface that looks foreign for users
coming from GitHub background.

Some SourceHut projects employ an approach to use Github-compatible
terminology and link to the corresponding Sourcehut pages:

[Issues] [Pull requests] [Discussions] [Wiki]

I suggest doing the same, with the following mapping:

[[orgmode.org/][Home page]]
[[https://tracker.orgmode.org/][Issues]]
[[mailto:emacs-orgmode@gnu.org][New issue]]
[[https://tracker.orgmode.org/patches][Pull requests]]
[[https://list.orgmode.org/][Discussions]]
[[https://orgmode.org/worg/][Wiki]]

It would also be nice to have "New issue" button in
https://tracker.orgmode.org/

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Question regarding org-capture-bookmark and org-bookmark-names-plist

[Ihor Radchenko]

Tim Wichmann  writes:

> during last OrgMeetup, I proposed a new user option
> `org-refile-bookmark', similar to the already existing option
> `org-capture-bookmark'.  Setting this new option to nil, `org-refile’
> would not create a bookmark when refiling.  (Use case: I am using
> alphapapa's org-bookmark-heading package and want to prevent that each
> captured/refiled entry gets an id.)
>
> I was just about to send the corresponding feature request when I
> stumbled across the documentation of `org-bookmark-names-plist'.  It
> states: „When a key does not show up in the property list, the
> corresponding bookmark is not set.“
>
> So, there is no need for a new user option: I simply have to remove the
> :last-refile key from the plist, and no bookmark will be created on
> refiling.

You are right.

> My question: Is this the intended way to suppress bookmark creation?

I think so.

> ... If so: Why is there the extra user option `org-capture-bookmark'?
> Isn't it superfluous, as the same behavior can be achieved by removing
> the :last-capture keyword from the plist?

We first introduced `org-capture-bookmark' and only then added
`org-bookmark-names-plist'. Maybe we should obsolete
`org-capture-bookmark' to avoid confusion.

> ...(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?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH v2] org-id: allow using parent's existing id in links to headlines

[Ihor Radchenko]

"Rick Lupton"  writes:

>> It looks like we cannot simply rely on narrowing to determine the
>> created heading level.
>
> I think you're right.  I have extended `org-link-search' to accept an 
> optional argument describing the org element where newly created headings 
> should go as subheadings.
>
> My thought was that this was not significantly more complicated than just 
> passing the numeric level for new headings, but actually more flexible (e.g. 
> you could if you wanted (with additional future elisp) create missing 
> headings as part of a "To be filed" subtree within the file, rather than 
> always at the end).
>
> Does that look ok?

Yes.

> [is it useful to keep attaching the unchanged first patch so they are 
> available as a set?]

Yes, it is useful. Makes it easier for my to batch-apply the patchset
using https://git.kyleam.com/piem/about/

I have some thoughts about rewording your changes to the manual and
ORG-NEWS. See the attached patch on top of yours.

> Subject: [PATCH 1/2] lisp/org.el (org-insert-heading): allow specifying
>  heading level

*Allow

> * lisp/org.el (org-insert-heading): Change optional argument TOP to
> LEVEL, accepting a number to force a specific heading level.
> * testing/lisp/test-org.el (test-org/insert-heading): Add tests
> * etc/ORG-NEWS: Document changes

Please end sentences with period.

> From d5759dd95bec88be38ddbde07fa4437c0528469a Mon Sep 17 00:00:00 2001
> From: Rick Lupton 
> Date: Sun, 19 Nov 2023 14:52:05 +
> Subject: [PATCH 2/2] org-id.el: Add search strings, inherit parent IDs
>
> ...
> (org-link-try-link-store-functions): Extract logic to call external
> link store functions. Pass them a new `interactive?' argument.
> ...
> (org-id-store-link): Consider IDs of parent headings as link targets
> when current heading has no ID and `org-id-link-consider-parent-id' is
> set. Add a search string to the link when enabled.

Please, use two spaces between sentences.

> * lisp/org-lint.el: add checker for "::" in ID properties.

... and start sentences from capital letter: *Add

> -(defun org-link-search (s  avoid-pos stealth)
> +(defun org-link-search (s  avoid-pos stealth new-heading-container)

The new optional argument to a public function should be announced in ORG-NEWS.

> + (new-heading-level (if new-heading-container
> +(+ 1 (org-element-property :level 
> new-heading-container))

What if new-heading-container is not a heading?

> +  1)))
> +(goto-char new-heading-position)

This is err when container ends after narrowed region boundary.

> +(defun org-link-precise-link-target ()
> ...
> +  (cond
> +   (name
> +(list name
> +  name
> +  (org-element-begin element)))

It would make sense to use #+caption as default description when available.

>From 0f9a4503d95f7682229ae1c1ad8a4e2d069fc644 Mon Sep 17 00:00:00 2001
Message-ID: <0f9a4503d95f7682229ae1c1ad8a4e2d069fc644.1707396844.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Thu, 8 Feb 2024 13:53:44 +0100
Subject: [PATCH] Amendments to org-manual.org and ORG-NEWS

---
 doc/org-manual.org | 18 ++
 etc/ORG-NEWS   | 27 ++-
 2 files changed, 24 insertions(+), 21 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 49fce9113..e933a2d63 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -3489,14 +3489,16 @@ ** Handling Links
 
   #+vindex: org-id-link-consider-parent-id
   #+vindex: org-id-link-use-context
-  When ~org-id-link-consider-parent-id~ is ~t~ (and
-  ~org-link-context-for-files~ and ~org-id-link-use-context~ are both
-  enabled), parent =ID= properties are considered.  This allows
-  linking to specific targets, named blocks, or headlines (which may
-  not have a globally unique =ID= themselves) within the context of a
-  parent headline or file which does.
-
-  For example, given this org file with those variables set:
+  #+vindex: org-link-context-for-files
+  When ~org-id-link-consider-parent-id~ is ~t~[fn:: Also,
+  ~org-link-context-for-files~ and ~org-id-link-use-context~ should be
+  both enabled (which they are, by default).], parent =ID= properties
+  are considered.  This allows linking to specific targets, named
+  blocks, or headlines (which may not have a globally unique =ID=
+  themselves) within the context of a parent headline or file which
+  does.
+
+  For example, given this org file:
 
   #+begin_src org
   ,* Parent
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 84bbc5243..e29d2895f 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -477,22 +477,23 @@ The change is breaking when ~org-use-property-inheritance~ is set to ~t~.
 
 The =TEST= parameter is better served by Emacs debugging tools.
 
-*** ~org-id-store-link~ now adds search strings for precise link targets
+*** =id:= links support search options; ~org-id-store-link~ adds 

Re: [BUG] Unsolicited download of remote resources

[Max Nikulin]

On 03/02/2024 03:03, Ihor Radchenko wrote:

Max Nikulin writes:


#+setupfile: http://localhost:8000/setup-1234567890.org

I am trying to decline attempts to download the remote resource by
hitting "n" (skip), but Org still tries to fetch that file and does it
twice. I see in the *Messages*
[...]> The prompt is displayed twice because fetching is attempted twice 
- when

reading startup options and when initializing macros. This is
sub-optimal, but expected.


Are names of macros necessary for some purpose before export is started?

Re: [BUG] Org may fetch remote content without asking user consent

[Max Nikulin]

On 08/02/2024 00:10, Ihor Radchenko wrote:

Max Nikulin writes:


It is a bit more tricky. Current file may be remote as well. Browsers
have concept of same origin for applying security and privacy measures.
Org needs something similar.


May you please elaborate?


Consider a file opened as /ssh:host:org/test.org that has

#+setupfile: /ssh:host:org/include.org

Formally it is a remote file, actually it resides on the same host as 
the current document. Perhaps user consent is redundant.


On the other hand, the file likely either contains

#+setupfile: include.org

or the user has /ssh:host:org/ in the list of safe URIs. So there is no 
need to treat such coincidence in a special way.


I am not confident in proper policy though. When some URI matches a 
pattern in the safe list, likely it is suitable for files created by the 
user and it is not really safe to allow it for a mail message attachment.


Default protection should not be excessively strict, otherwise users 
will disable it completely.

Re: [PATCH v2] org-id: allow using parent's existing id in links to headlines

[Rick Lupton]

On Sat, 3 Feb 2024, at 1:10 PM, Ihor Radchenko wrote:
> I'd prefer to avoid using global variables here.
> `org-entry-property-inherited-from' dates to pre-lexical binding times
> and is a potential source of subtle bugs if several `org-entry-get'
> calls happen unexpectedly to the code, changing
> `org-entry-property-inherited-from' multiple times.
>
> Instead, I suggest changing the return value of
> `org-link-precise-link-target' to a list that includes marker in
> addition to search string and description.

Makes sense -- I changed it to work that way and it is neater.

I returned simply the buffer position rather than a marker, since it is always 
in the current buffer, and avoids needing to worry about cleaning up the marker 
when finished or if not of interest.

> It looks like we cannot simply rely on narrowing to determine the
> created heading level.

I think you're right.  I have extended `org-link-search' to accept an optional 
argument describing the org element where newly created headings should go as 
subheadings.

My thought was that this was not significantly more complicated than just 
passing the numeric level for new headings, but actually more flexible (e.g. 
you could if you wanted (with additional future elisp) create missing headings 
as part of a "To be filed" subtree within the file, rather than always at the 
end).

Does that look ok?

[is it useful to keep attaching the unchanged first patch so they are available 
as a set?]

Thanks
Rick

0001-lisp-org.el-org-insert-heading-allow-specifying-head.patch
Description: Binary data


0002-org-id.el-Add-search-strings-inherit-parent-IDs.patch
Description: Binary data

[PATCH] lisp/ol.el: Improve docstring

[Rick Lupton]

On Sat, 3 Feb 2024, at 1:10 PM, Ihor Radchenko wrote:
> In my testing, I used #+name: as link target.
> However, what I missed is that #+name targets are matched even when
> `org-link-search-must-match-exact-headline' is set to 'query-to-create.
> The docstring is not accurate there and must be updated.

How about this?

0001-lisp-ol.el-Improve-docstring.patch
Description: Binary data