[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
0001-org-id.el-Extend-links-with-search-strings-inherit-p.patch
Description: Binary data