"Rick Lupton" writes:
> Thanks for the example and explanation. Yes that does make sense, mostly. I
> assume this would look like this in org-store-link:
>
> (let ((org-link-context-for-files (org-xor org-link-context-for-files (equal
> arg '(4
> (...call store link functions...))
Yes.
On Fri, 15 Dec 2023, at 12:55 PM, Ihor Radchenko wrote:
> No, it is generally not safe. For a different reason.
>
> Let me illustrate with an example:
>
> ...
>
> Conclusion: It is unsafe to use `current-prefix-arg' value. We need to
> pass this information some other way.
>
> The way I proposed is
"Rick Lupton" writes:
>>> +(defcustom org-id-link-use-context t
>> ...
>> It does not look like integer value is respected in the patch.
>
> You're right. Do you have a preference between
>
> (a) sticking to this docstring, which creates the possibility of using
> different numbers of lines for
Dear Ihor,
Thanks for taking a look at the patch and for your feedback.
Re various docstrings, documenting new optional argument -- I will try to
address these.
Other comments/questions below.
On Sun, 10 Dec 2023, at 1:35 PM, Ihor Radchenko wrote:
> "This change..." part sounds like a commit m
"Rick Lupton" writes:
> 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 wi
Hi,
I can’t see this patch listed at https://tracker.orgmode.org/ so just wanted to
check it hasn’t got lost?
Thanks
Rick
On Sun, 19 Nov 2023, at 3:21 PM, Rick Lupton wrote:
> Here's an updated patch, which adds (optional) search strings to ID
> links, and the option to inherit ID targets from
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 hea
"Rick Lupton" writes:
> On Tue, 25 Jul 2023, at 8:43 AM, Ihor Radchenko wrote:
>> 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 agree this would be neater, but looking at how t
On Tue, 25 Jul 2023, at 8:43 AM, Ihor Radchenko wrote:
> 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 agree this would be neater, but looking at how this would work, I have a
questi
"Rick Lupton" writes:
> My previous patch changes the behaviour when `org-id-link-to-org-use-id` has
> a new value (`inherit`) in two ways:
>
> (a) org-ids from parent headings are considered when choosing the ID to link
> to, and
> (b) search strings are added to the link
>
> But these are ac
I realised there is another question here about how search strings are used in
org-id links.
Consider this example file:
* Heading
:PROPERTIES:
:ID: 06E767E6-6145-45EB-B736-D350449126EC
:END:
#+name: named-thing
#+begin_example
Hi!
#+end_example
By default (`org-id-link-to-org-use-id`
"Rick Lupton" writes:
>> What about inherited CUSTOM_ID?
>
> I’m not sure what you mean.
>
> Are you thinking of CUSTOM_ID links, and whether they would behave
> consistently with a search string to this proposal? Like:
> [[custom-id:my-id::*H2][H2]]
>
> Or using custom id as a search string?
I can see this being useful in general, but not avoiding the need for my patch.
Org links using search strings already strike a good compromise between working
with arbitrary plain text, and allowing links to specific locations. When a
search string is enough to find the thing you want to link t
Hi Ihor,
Thanks for the comments, I will take a look. A question below.
On Wed, 26 Jul 2023, at 9:10 AM, Ihor Radchenko wrote:
>
> I am looking at it from an opposite direction: we already have file:
> links with ::search term, but file is not a very reliable link anchor.
> File ID will persist
Samuel Wales writes:
> ... but what if those smaller things
> could have ids without drawers? id markers. then changes in
> surrounding text would not break anything.
I recall similar idea raised in
https://list.orgmode.org/orgmode/cajniy+ovd0ncwzztpit5t7wvsblbgllxzmpub5tgq3gshsg...@mail.gmai
i can see the appeal given the granularity of id [headings, files]. yu
want to point to smaller things. but what if those smaller things
could have ids without drawers? id markers. then changes in
surrounding text would not break anything.
On 7/26/23, Ihor Radchenko wrote:
> Max Nikulin writ
Max Nikulin writes:
> I am not excited by the idea of extending id links for heading
> hierarchy. From my point of view it is more natural to add the ID
> property to the heading that should be link target.
>
> Sometimes I do not mind to disambiguate heading search link by
> specifying title o
On 25/07/2023 14:43, Ihor Radchenko wrote:
"Rick Lupton" writes:
>> Now, with `org-id-link-to-org-use-id' set to `inherit`, "H2" is not
modified, and the resulting link is `[[id:abc::*H2][H2]]`, which will
still take you to the same place as long as the sub-heading is unique
within the parent h
"Rick Lupton" writes:
> Here is a small new feature for org-id that I have been using and finding
> useful. The patch adds the option to look for ancestors of the current
> headline that have an ID defined and use that together with a link search
> string to link to specific headlines, without
Hi,
Here is a small new feature for org-id that I have been using and finding
useful. The patch adds the option to look for ancestors of the current headline
that have an ID defined and use that together with a link search string to link
to specific headlines, without needing every single headl
20 matches
Mail list logo
