-
-
Notifications
You must be signed in to change notification settings - Fork 167
Extend API to get links to headline and org file #768
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 3 commits
f255ac5
5a88955
1344eb1
23f0c98
cb621f0
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -174,16 +174,32 @@ end | |
| ---@param headline OrgHeadline | ||
| ---@param path? string | ||
| function Hyperlinks.get_link_to_headline(headline, path) | ||
| path = path or utils.current_file_path() | ||
| local title = headline:get_title() | ||
| local id | ||
|
|
||
| if config.org_id_link_to_org_use_id then | ||
| id = headline:id_get_or_create() | ||
| local id = headline:id_get_or_create() | ||
| if id then | ||
| return ('id:%s::*%s'):format(id, title) | ||
| end | ||
| end | ||
|
|
||
| if config.org_id_link_to_org_use_id and id then | ||
| return ('id:%s::*%s'):format(id, title) | ||
| path = path or utils.current_file_path() | ||
| return ('file:%s::*%s'):format(path, title) | ||
| end | ||
|
|
||
| ---@param file OrgFile | ||
| ---@param path? string | ||
| function Hyperlinks.get_link_to_file(file, path) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is a file path with the title valid format for a file link? From the examples here https://orgmode.org/guide/Hyperlinks.html I don't see any of those. I think for link to file it is enough to either be an id, or just
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is not, and it's also not treated such. I am piggy-backing here on the "title" format to sneak a description into Right now I am quite happy, how Telescope-orgmode works although the API is not perfect yet.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, we can leave it for the time being, but later once we do some refactoring, I'd prefer to remove it. |
||
| local title = file:get_title() | ||
|
|
||
| if config.org_id_link_to_org_use_id then | ||
| local id = file:id_get_or_create() | ||
| if id then | ||
| return ('id:%s::*%s'):format(id, title) | ||
| end | ||
| end | ||
|
|
||
| path = path or file.filename | ||
| return ('file:%s::*%s'):format(path, title) | ||
| end | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need to do this if there is no buffer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jep, actually this is the crucial part (and took me some time to figure out, reading through the agenda code).
The file we want to target a link to, is very likely not open. If we use
org_id_link_to_org_use_id = true, there might not be an ID yet. But creating this id needs an edit of the file, which is done by theid_get_or_createmethods under the hood. And this needs to open the file automatically in the background and close it again, if it is not already open.Let me clarify the motivation behind this API extension:
When I use telescope-orgmode to create links, I can access the whole index of files build up by orgmode on startup. This allows for very convenient creation of links and cross-references using fuzzy finding. It is not very convenient, if I would have to open the files first, before being able to set the link.
The manual workflow for ID links works actually that way, I have to open the target file, press
org-store-link(which also creates the id), navigate to my file, where the link originates and pressorg-insert-link. My telescope plugin makes this workflow much smoother, because I can just filter for the target headline without open the file, press enter and, boom, I have the link and the ID.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, sounds good.
Is it worth moving these methods to
OrgApiFileandOrgApiHeadlineinstead of passing them down from the top level?Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think, we should keep it as it is for know. I expect to discover more requirements while I am implementing more features and playing around with what we have. If it doesn't bother you, I would adapt when needed and we have better knowledge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just figured out I didn't phrase my question correctly.
What I wanted to ask is:
Would it work for you to move these to api/file and api/headline? All of the file or headline specific api methods live in those file, so I'd prefer to keep it consistent.
If it doesn't work for you, can you clarify why?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All three methods are used for link creation and are meant to be used together. I might need to understand better, what your primary criterion is for where to put a method and also what the main purpose of the top-level API is.
I don't actually have a big problem of making these methods member functions of
OrgApiFileandOrgApiHeadline.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If a function is accepting an instance of something, I always prefer to have that function on the instance itself. Of course that's not always possible, but when it is, I prefer to take that path.
For example, if we would follow this way for example for
get_property, we would have something like this:But this is much cleaner IMO:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, was already convienced, when I realized, that the argument of the original functions is actually the self argument in
orgmode.api.headlineandorgmode.api.file. . 😄Now that I refactored the code I am even more convienced, because it cleaned also things up on the client side.
What do you think, are we ready to merge?