Skip to content
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

[Feature proposal] add the scope limit to denote-missing-links #499

Open
jarofromel opened this issue Dec 15, 2024 · 4 comments
Open

[Feature proposal] add the scope limit to denote-missing-links #499

jarofromel opened this issue Dec 15, 2024 · 4 comments

Comments

@jarofromel
Copy link

Hello,
I create the metanote (index) which contains the links to my denote files. Each heading in the metanote represents one tag and there are links to files with this tag. I use denote-org-extras-dblock-insert-backlinks to check that I had indexed all the tagged files. But in the case of files with two more tags the link can be already included in the metanote. See example below:

* tag DBMS
[[link to file1_dbms_emacs]]

* tag EMACS
#+BEGIN: denote-missing-links :regexp "_emacs"
nothing is found because there is already one link to the file1_dbms_emacs
#+END

The scope limiting parameter in the dynamic block would solve this situation (:scope heading/file). Thanks for potentially considering this.
Maybe there is simpler solution, but I didn't find it yet.

@protesilaos
Copy link
Owner

I see. Please help me understand this better. What kind of values do you think the scope should accept? Maybe file and heading? Is there another scenario?

@jarofromel
Copy link
Author

From the similar functionalities:
org clock table dblock - :scope header arg
org column view dblock - :id header arg
org-ql dblock - :from header arg

I think current buffer (or file) and current subtree would be good enough for most usecases.
Other "nice to haves" (inspired by the links above) are (sorted by usefulness as I see it):

  • region, treeN (surrounding trees), filename (other file than the current one), function (returning filenames), heading (returning heading)

@protesilaos
Copy link
Owner

This is a good idea. Though it will need to eventually be generalised for all the dynamic blocks we have. As such, I think we must first consolidate everything into a single denote block and then add the new feature.

@jarofromel
Copy link
Author

Sure. I am not yet on the level to enhance denote codebase but I am happy to test and try.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants