Migrated from github#450
I know the below feature proposal is just one implementation to the problem on the header. Should I split this feature request to two, @tienson? One for neighbor node display and one for the generic header/footer injection?
Is your feature request related to a problem? Please describe.
My main goal is to list neighbor pages.
Consider the following page graph:
When viewing page b, I’d like to have a panel stating:
Also links to t1:
Also links to t2:
Describe the solution you’d like
I’d like to have a hook, which injects arbitrary content (including queries) to any page header/footer.
Very interesting idea. Having custom queries for all pages (besides backlink references) like in Journals can be a killer feature. This can extended what can be done.
Of course those queries dont get inserted in the pages (markdown) like backlink references queries.
I’m thinking of queries that show blocks of other pages with a timestamp showed when the page you are viewing have a timestamp or some block with a timestamp and the year is the same.
Or creating more advanced relations between blocks or pages (like complex namespaces, etc…) as backlink references (I mean here extending the actual backlink references internal working).
Can you define “neighbor nodes” and “neighbor pages”? Are these just items that the page links to? Does it include backlinks (links with the current page as target)? Or are these any page/node that links to a page/node the current page links to? If the latter, can’t you get this information by going to the target page and checking the backlinks?
If I understand you, for pages A, B, and C, if A links to C and B links to C, then A and B are neighbor pages.
In this case, if you want to see what links to C, you can go to page C and A and B will both be listed as backlinks. I understand that you want to see B listed on page A as a neighbor, but I wonder about the actual use case. For my notes, with relatively long pages with lots of interlinking, I’m pretty sure such a list of neighbor links would become overwhelming. I’ve nothing against the idea, just wondering if it adds significant functionality. Also, where would you want this list presented on the page?
Again, no objection to the idea, but #tag will still be supported, so it doesn’t simplify Logseq as a program, and users can still use [[tag]], and you can still click on [[tag]] to see page tag and see all links to that page. So it seems to me to be something that can be done with a plug-in at some point.