[Feature Request] Dynamic block to insert backlink content

[skissue]

Currently, there is a denote-backlinks dynamic block to insert links to backlinked notes, and a denote-files dynamic block to insert the contents of notes matching a regexp. Would it be possible to have a dynamic block to insert the contents of backlinked notes?

[protesilaos]

From: Ad ***@***.***> Date: Wed, 2 Oct 2024 18:00:42 -0700 Would it be possible to have a dynamic block to insert the contents of backlinked notes?

In principle yes. I will check what I can do as soon as possible. Probably next week because I have been too busy lately with construction work. An aside here. My concern with all these dynamic blocks is that we need to define a whole new function and register it with Org to get the intended behaviour. It seems inefficient, especially when we want to have these kind of combined results that you describe. Maybe there is a way for us to have something more generic here that lets the user compose a query with the desired output style. The building blocks are there but we need to do the research to find out what is missing.

…

-- Protesilaos Stavrou https://protesilaos.com

[skissue]

An aside here. My concern with all these dynamic blocks is that we need to define a whole new function and register it with Org to get the intended behaviour. It seems inefficient, especially when we want to have these kind of combined results that you describe. Maybe there is a way for us to have something more generic here that lets the user compose a query with the desired output style. The building blocks are there but we need to do the research to find out what is missing.

Perhaps it would be worthwhile to combine all the dynamic blocks into a single type with arguments for choosing a query and output filter. An interface like this:

#+BEGIN: denote :query "_regexp" :output links [other arguments]
#+END:

#+BEGIN: denote :query backlinks :output content [other arguments]
#+END:

This could also allow users to easily add their own selection/output methods that could then be hooked in, e.g. via a customizable alist mapping symbols to functions.

[protesilaos]

From: Ad ***@***.***> Date: Fri, 4 Oct 2024 17:16:11 -0700 > An aside here. My concern with all these dynamic blocks is that we > need to define a whole new function and register it with Org to get > the intended behaviour. It seems inefficient, especially when we want > to have these kind of combined results that you describe. Maybe there > is a way for us to have something more generic here that lets the > user compose a query with the desired output style. The building > blocks are there but we need to do the research to find out what is > missing. Perhaps it would be worthwhile to combine all the dynamic blocks into a single type with arguments for choosing a query and output filter. An interface like this: ```org #+BEGIN: denote :query "_regexp" :output links [other arguments] #+END: #+BEGIN: denote :query backlinks :output content [other arguments] #+END: ``` This could also allow users to easily add their own selection/output methods that could then be hooked in, e.g. via a customizable alist mapping symbols to functions.

This makes sense. It will be a major rework though. The important part is to maintain backward-compatibility, as there will be lots of those blocks in users' files and we do not want to break anything (I do not want to make users rewrite potentially hundreds of blocks).

…

-- Protesilaos Stavrou https://protesilaos.com

[skissue]

This makes sense. It will be a major rework though. The important part is to maintain backward-compatibility, as there will be lots of those blocks in users' files and we do not want to break anything (I do not want to make users rewrite potentially hundreds of blocks).

I agree that backward compatibility is of the utmost priority. However, since there's currently no denote block type, there should be no problem with adding one. The old dynamic block functions can then be refactored to use the APIs from the generic block type, specifying the relevant parameters; e.g. denote-files can be a thin shim that passes its parameters into the relevant denote block parameters.

[protesilaos]

From: Ad ***@***.***> Date: Thu, 10 Oct 2024 08:39:59 -0700 > This makes sense. It will be a major rework though. The important > part is to maintain backward-compatibility, as there will be lots of > those blocks in users' files and we do not want to break anything (I > do not want to make users rewrite potentially hundreds of blocks). I agree that backward compatibility is of the utmost priority. However, since there's currently no `denote` block type, there should be no problem with adding one.

Smart! I agree.

The old dynamic block functions can then be refactored to use the APIs from the generic block type, specifying the relevant parameters; e.g. `denote-files` can be a thin shim that passes its parameters into the relevant `denote` block parameters.

Indeed. We will just keep them around, but otherwise encourage users to use the new interface. I will work on it as soon as possible.

…

-- Protesilaos Stavrou https://protesilaos.com