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] Jump/related links #11

Closed
rsuhada opened this issue Apr 5, 2017 · 5 comments
Closed

[Feature] Jump/related links #11

rsuhada opened this issue Apr 5, 2017 · 5 comments

Comments

@rsuhada
Copy link
Contributor

rsuhada commented Apr 5, 2017

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!

@Kungsgeten
Copy link
Owner

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.

@rsuhada
Copy link
Contributor Author

rsuhada commented Apr 5, 2017

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
b.org has in brainparents a.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:

  1. since parent state is persisted, you don't need to search for it - just read it off the file (faster, scales better)
  2. if you visit the given org file directly in org mode (not in brain-visualize) you still can see it's parents. Currently only children are visible.

These are just some thoughts... the implementation might be more complicated?

@Kungsgeten
Copy link
Owner

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.

@Kungsgeten
Copy link
Owner

I have rewritten org-brain from scratch, please see: https://github.com/Kungsgeten/org-brain/tree/org-brain-id

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.

@Kungsgeten
Copy link
Owner

The 0.4 branch is merged into master, and adds "jump links" as friendships.

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

No branches or pull requests

2 participants