emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Rick Lupton
Subject: Re: [PATCH] org-id: allow using parent's existing id in links to headlines
Date: Sun, 19 Nov 2023 15:21:09 +0000
User-agent: Cyrus-JMAP/3.9.0-alpha0-1108-g3a29173c6d-fm-20231031.005-g3a29173c

Here's an updated patch, which adds (optional) search strings to ID links, and 
the option to inherit ID targets from parent headline / the top level file 
properties.  I've also updated ORG-NEWS and the manual, and added tests.

I think I've fixed all the issues with my first patch about which headline gets 
used for the description when inheriting IDs, what happens if there is no ID, 
etc.

> Ideally, we should have all the necessary logic to store the link within 
> `org-id-store-link' and then use `org-link-set-parameters' to configure id 
> links.
> ...
> I think that we need to make a change in the rules for :store functions. 
> `interactive?' may be passed as the argument to these functions.

I've also moved the org-id specific logic from `org-store-link` to 
`org-id-store-link`, and added the `interactive?` argument to link store 
functions as discussed.

>> So my question is: should search strings be added to all org-id links?
> Sounds as a reasonable default, but users should have an option to revert to 
> previous behaviour with heading id being stored.

The default value for the new option `org-id-link-use-context` is `t`, but it 
can be set to `nil` (or disabled with a prefix argument to `org-store-link` 
temporarily).  This is a change in default behaviour when storing ID links with 
point at a subheading, named block, or target, or with an active region.

The option `org-id-link-consider-parent-id` I've left with a default value of 
`nil`, since I'm not sure if everyone will want this behaviour.

Thanks
Rick

Attachment: 0001-org-id.el-Extend-links-with-search-strings-inherit-p.patch
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]