Stefan writes:
> since this patch was applied, there are now two functions in
> `org-store-link-functions` that feel responsible for id links from some
> buffers: the new `org-id-store-link-maybe` and `org-contacts-link-store`.
>
> This results in a prompt asking which one to use, which
Hi,
since this patch was applied, there are now two functions in
`org-store-link-functions` that feel responsible for id links from some
buffers: the new `org-id-store-link-maybe` and `org-contacts-link-store`.
This results in a prompt asking which one to use, which happens many times,
e.g.,
Thanks for your help with it!
On Sat, 24 Feb 2024, at 1:02 PM, Ihor Radchenko wrote:
> Bastien Guerry writes:
>
>>> "Rick Lupton" writes:
>>>
On Fri, 9 Feb 2024, at 12:09 PM, Ihor Radchenko wrote:
> May you please update on your FSF copyright assignment status?
I believe the
Bastien Guerry writes:
>> "Rick Lupton" writes:
>>
>>> On Fri, 9 Feb 2024, at 12:09 PM, Ihor Radchenko wrote:
May you please update on your FSF copyright assignment status?
>>>
>>> I believe the agreement is all signed and completed.
>>
>> Bastien, may your please check FSF records?
>
>
Hi,
Ihor Radchenko writes:
> "Rick Lupton" writes:
>
>> On Fri, 9 Feb 2024, at 12:09 PM, Ihor Radchenko wrote:
>>> May you please update on your FSF copyright assignment status?
>>
>> I believe the agreement is all signed and completed.
>
> Bastien, may your please check FSF records?
Done,
"Rick Lupton" writes:
> On Fri, 9 Feb 2024, at 12:09 PM, Ihor Radchenko wrote:
>> May you please update on your FSF copyright assignment status?
>
> I believe the agreement is all signed and completed.
Bastien, may your please check FSF records?
--
Ihor Radchenko // yantar92,
Org mode
On Fri, 9 Feb 2024, at 12:09 PM, Ihor Radchenko wrote:
> May you please update on your FSF copyright assignment status?
I believe the agreement is all signed and completed.
Thanks
Rick
"Rick Lupton" writes:
> 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
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
"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.
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
Samuel Wales writes:
>> May you please elaborate what you want to add to the manual and where?
>
> had been merely thinking mentioning non-brittleness for newcomers.
> in handling links.
Isn't it already mentioned?
... In addition or alternatively, depending on the value of
"Rick Lupton" writes:
> I see. Updated to get the search string first, before the possible
> properties draw appears.
>
> To make this work I changed `org-link-precise-link-target': instead of
> accepting the RELATIVE-TO argument and rejecting unsuitable targets
> internally, it now sets a
On Thu, 1 Feb 2024, at 12:13 PM, Ihor Radchenko wrote:
> The patch does not apply onto the latest main. May you please update it?
I have rebased onto the latest main. It changes quickly!
(there were no conflicts during the rebase, which I'd have thought would mean
the patches shouldn't be a
The patch does not apply onto the latest main. May you please update it?
On Mon, 29 Jan 2024, at 1:00 PM, Ihor Radchenko wrote:
>>> 3. Consider
>>>(setq org-id-link-consider-parent-id t)
>>>(setq org-id-link-to-org-use-id t)
>>>
>>>Then, create a new empty Org file
>>>M-x org-store-link with create a top-level properties drawer with ID
>>>and store
On 1/29/24, Ihor Radchenko wrote:
> You mentioned this feature request in the past. It is not forgotten.
thank you.
> May you please elaborate what you want to add to the manual and where?
had been merely thinking mentioning non-brittleness for newcomers.
in handling links.
but MAYBE also
Samuel Wales writes:
> my experiene is that context, search, and file links typically break
> for me, as i change headers, refile, fix typos, change paths, etc. so
> i stick with just org-id and, for export, custom id where possible.
That's why we have `org-id-link-to-org-use-id'.
> however,
"Rick Lupton" writes:
> Thanks for trying it out. Updated patches attached, comments below.
Thanks!
>> 3. Consider
>>(setq org-id-link-consider-parent-id t)
>>(setq org-id-link-to-org-use-id t)
>>
>>Then, create a new empty Org file
>>M-x org-store-link with create a top-level
sounds like a lot of contribution. i do not want to impede anything
anybody else wants, but want to point out my user experience over
years in case useful to anybody.
my experiene is that context, search, and file links typically break
for me, as i change headers, refile, fix typos, change
Hi,
Thanks for trying it out. Updated patches attached, comments below.
On Mon, 18 Dec 2023, at 12:27 PM, Ihor Radchenko wrote:
> I played around with the patch a bit and found a couple of rough edges:
>
> 1. When I try to open a link to non-existing search target, like
>, I get a query to
"Rick Lupton" writes:
> Thanks for the comments. On this point, I'd like to modify
> `org-insert-heading' to allow for choosing the level of the newly inserted
> heading, but first wanted to check if you have a preference for how to change
> it.
>
>
> I think it would be simplest to change
On Mon, 18 Dec 2023, at 12:27 PM, Ihor Radchenko wrote:
> I played around with the patch a bit and found a couple of rough edges:
>
> 1. When I try to open a link to non-existing search target, like
>, I get a query to create a new
>heading. If I reply "yes", a new heading is created.
"Rick Lupton" writes:
> Please find attached updated patch which I think addresses all the points
> discussed. Let me know if you see any further changes needed.
Thanks!
I played around with the patch a bit and found a couple of rough edges:
1. When I try to open a link to non-existing
Please find attached updated patch which I think addresses all the points
discussed. Let me know if you see any further changes needed.
Thanks,
Rick
0001-org-id.el-Extend-links-with-search-strings-inherit-v2.patch
Description: Binary data
25 matches
Mail list logo
