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

Treat paths as relative to the file they're in, not vim's current dir #459

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

charlie-wt
Copy link

Currently, if you have a ~/my_notes/ directory, containing an index.md with a link [my recipes](recipes.md), you'll only be able to follow the link if vim is itself inside the my_notes/ directory. This assumption is restrictive, and doesn't work at all for more nested hierarchies like wikis.

Currently, if you have a `~/my_notes/` directory, containing an
`index.md` with a link `[my recipes](recipes.md)`, you'll only be able
to follow the link if vim is itself inside the `my_notes/` directory.
This assumption is restrictive, and doesn't work at all for more nested
hierarchies like wikis.
Copy link
Member

@alerque alerque left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible that another mode is needed for "relative to project root", whatever that is? It seems like for some situations the VIM current dir could be used as a stand in for the project root and this will break those types of links. But yes I can see how for some local systems this will be an improvement, we just need to figure out when it should be triggered and if/when the old behavior is actually better.

@charlie-wt
Copy link
Author

ah yeah that's true, i guess it depends on whether it's more common for people to make links relative to the files they're in, versus being semi-'absolute' by being relative to the project root. personally, i do the former, and for wikis like to open vim in the wiki root so that i can easily fuzzy-find things. this change would break back compat with people who were doing the latter, though.

there's always the perennial option of adding a config for this... otherwise, the only way of being smart about it i can immediately think of is looking for a relative-to-the-file match first and falling back to relative-to-vim. that feels like it could quite easily end up not doing what people expect, though.

@alerque
Copy link
Member

alerque commented Dec 30, 2023

Personally all of my projects use the pseudo-absolute method of links being relative to the project root because they are meant to be compiled (static site generators, book projects, etc.) and used as a whole, not piecemeal.

I understand there are other workflows, but regardless of which arrangement might be more common since this plugin has defaulted to this way for a long time the only way this is going to work without breaking everybody's existing setups is to gate it behind an off-by-default option.

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

Successfully merging this pull request may close these issues.

None yet

2 participants