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] Jump/related links #11
Comments
I want to include these, but it is a bit problematic since they're two way. Which file should hold the relations? If adding some kind of database, this is a feature that I'd definitely add. |
With flat files - both files would hold the link. If a.org is related to b.org then a.org will have in its brainrelated heading a link to b.org and, b.org in its heading a link to a.org. By the way - this could be useful for child-parent relationships. Currently child is stored, but parents could be too. So if a.org is parent of b.org: a.org has in brainchildrend b.org So links are always two-way. They are symmetric for related links (related-related) and antisymmetric for parent-child links. This approach has 2 advantages:
These are just some thoughts... the implementation might be more complicated? |
Yes, I've thought about storing parent links locally too, it would remedy the speed issues. The problematic thing is when adding/deleting a child link manually; the current file then needs to be added/deleted as a parent in the target as well. Its probably possible to do this in the save hooks, but I haven't tried it yet. |
I have rewritten This new version includes the "jump link" feature (but I call them friends). This will be merged into main in a couple of days, I'm just going to test it a bit more first. |
The 0.4 branch is merged into master, and adds "jump links" as friendships. |
The Brain has one more type of links beyond child, parent - jump links. These link nodes that are related but not in a child/parent relation. E.g.: "hot" and "cold" are related in this way, or "Barack Obama" and "Michelle Obama".
It would be great to have this type too. (I think it could be done simly copying the "child" infrastructure and renaming it to e.g. "related", having :brainrelade: tags and headers. Nicer way would be to generalized the child functions to have a child/related switch)
Thanks!
The text was updated successfully, but these errors were encountered: