I have been using the simpler version using advice (without my patch).
On reflection this seems ok to me -- I don't think there's really any need for
my proposed patch, unless it turns out in future that there are multiple
packages like org-roam that need to supply org-id-finding abilities in a
Thanks for taking the time to comment thoroughly on this which seems generally
like it would be a good improvement.
On Tue, 9 Apr 2024, at 9:52 AM, Ihor Radchenko wrote:
> 2. Allow attaching auxiliary attributes to the on object level, as an
>equivalent of affiliated keywords on element
Thanks, I hadn't understood the significance of named functions vs variables
for advice. But now I realise this is not solving the same problem as the
original patch.
The point is that I was thinking org-roam should advise/modify/hook the
specific function `org-id-find' [to find ids in its
On Wed, 13 Mar 2024, at 12:30 PM, Ihor Radchenko wrote:
> I think that we can do it simpler. [...]
> The idea is to use Emacs' advice machinery to allow third-party code
> alter the functions stored in link parameters.
I was avoiding this because I thought it was only recommended (in the elisp
Hi all,
Since updating the org-id code [1] to use the standard org-link registered
functions instead of hard-coding org-id opening, I have a problem using
org-roam.
org-roam overwrites the :follow function for "id" links from the build-in
`org-id-open' to its own `org-roam-id-open'
You might be interested in https://www.orgroam.com/ which is a broadly similar
idea to org-brain but uses a SQLite database to track id locations and links.
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 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
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
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
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
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
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
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
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.
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
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
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
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 t
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
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
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`
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
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
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
Hi Ihor and all,
I wonder if you have seen Pollen’s approach to this?
https://docs.racket-lang.org/pollen/pollen-command-syntax.html
There are two separate ideas used there which seemed related to this
discussion. I’m not sure if they are useful in the org context.
1. The use of a special
I also found this recently. The reason is that BibTeX-dialect is set by
org-cite-basic--parse-bibliography in oc-basic.el based on the file extension.
Renaming your bibliography file to end in “.bibtex” instead of “.bib” should
make it be parsed using the bibtex rather than biblatex dialect.
Thomas S. Dye tsd at tsdye.com writes:
Rick Lupton r.lupton at gmail.com writes:
As a separate question, is it possible to get :results file as the
default from the original block so it doesn't have to be repeated in each
#+CALL ?
This should work:
* Appropriate Heading Level
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
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org-mode mailing list.
29 matches
Mail list logo