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

Don't keep redundant symlinked paths #48

Closed
reagle opened this issue Mar 21, 2019 · 5 comments
Closed

Don't keep redundant symlinked paths #48

reagle opened this issue Mar 21, 2019 · 5 comments

Comments

@reagle
Copy link
Contributor

reagle commented Mar 21, 2019

I often have redundant entries for the real and symlinked paths to a file. I recently added one of the paths to path_exclude_patterns but then sometimes miss entries. This could easily be resolved by way of only storing paths normalized by pathlib.Path.absolute().

@FichteFoll
Copy link
Owner

Counter argument: What if you wanted to edit/find the file under its symlinked name instead of the resolved file path?

@reagle
Copy link
Contributor Author

reagle commented Mar 22, 2019

I sympathize with that as I use symlinks to shorten long paths, especially to encrypted/mounted volumes. I'd be happy if you displayed the shortest version encountered in the palette.

You could easily implement by resolving a path to its canonical/real form and keeping a lookup dictionary of {real_path: shortest_encountered_path}.

@FichteFoll
Copy link
Owner

FichteFoll commented Mar 23, 2019

I believe you are simplifying this to your use case. There are situations where your desired functionality isn't desired, but I can also see your use case.

I could definitely see a point in making this an option, but I have to admit I won't find time to look into implementing this myself soon. Pull requests are welcome, though.

@reagle
Copy link
Contributor Author

reagle commented Mar 28, 2019

Thanks. #45 doesn't look like it would be too hard, but you said you were planning a re-write?

@FichteFoll
Copy link
Owner

FichteFoll commented Mar 28, 2019

Yeah, the package is currently in full maintenance mode. I didn't even write the initial code myself and don't agree with many of the coding choices, but a rewrite takes quite a bit of time that I don't have to spare at the moment.

However, I am still willing to review pull requests or implement bug fixes.

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

No branches or pull requests

2 participants