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

.cs_file in read only directories #298

Open
ldelossa opened this issue May 7, 2021 · 2 comments
Open

.cs_file in read only directories #298

ldelossa opened this issue May 7, 2021 · 2 comments
Labels
enhancement: feature dev new requests, or significant changes to existing ones priority: 3 - wishlist

Comments

@ldelossa
Copy link

ldelossa commented May 7, 2021

Describe the bug
I do not see an option to store cs_file in an arbitrary directory of our liking.

The inability to do this breaks building caches for read only directories.

To Reproduce
Seems like you use Go, so browse into /usr/local/go/src/ and do a files listing.

Most likely, if you're doing this as your normal user, the /usr/local/go dir is read-only and a cs_file cannot be written.

This breaks ctrlspace's ability to list files utilizing a cache.

Expected behavior
A configuration option which allows a prefixed/suffixed cs_file to be created in an arbitrary path of the user's liking. Such as ~/.config/ctrlspace/ for instance.

@jyscao
Copy link
Collaborator

jyscao commented May 10, 2021

That's a reasonable feature request. Though we can't guarantee when we might get around to implementing it.

Are you unable to clone the repo you're working on to a location writable to your user? Another possible workaround is to let g:CtrlSpaceEnableFilesCache = 0, which will forego using a files cache entirely, and use rg, fd or ag to collect your project files each time CtrlSpace enters Files mode. This is only suitable for not so large repos though (<1k files on my system).

@jyscao jyscao added enhancement: feature dev new requests, or significant changes to existing ones priority: 3 - wishlist labels May 10, 2021
@ldelossa
Copy link
Author

My assumption is that large read only directories are rather common, be it a net-location or anything in Go's mod cache. Any work around seems like a compromise in performance or a caveat on usage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement: feature dev new requests, or significant changes to existing ones priority: 3 - wishlist
Projects
None yet
Development

No branches or pull requests

2 participants