Why the dependency on build dir????
unixbhaskar opened this issue · 7 comments
How to get rid of this annoying thing??
bhaskar@Gentoo_04:39:21_Mon Jun 29:~> vgrep --interactive
error loading cache: please cd into /home/bhaskar/git-linux/vgrep to use old cache
bhaskar@Gentoo_04:39:50_Mon Jun 29:~> vgrep -d
DEBU[0000] log level set to debug
DEBU[0000] passed args: []
DEBU[0000] loadCache(): start
DEBU[0000] loadCache(): end
error loading cache: please cd into /home/bhaskar/git-linux/vgrep to use old cache
bhaskar@Gentoo_04:40:50_Mon Jun 29:~> cd -
/home/bhaskar/git-linux/vgrep
✔ ~/git-linux/vgrep [master|✚ 1]
04:41 $ make clean
rm -rf ./build
✔ ~/git-linux/vgrep [master|✚ 1]
04:41 $ cd ~
bhaskar@Gentoo_04:41:07_Mon Jun 29:~> vgrep --interactive
error loading cache: please cd into /home/bhaskar/git-linux/vgrep to use old cache
Thanks for the report. Can you please be more precise? I don't see a relationship between ./build and the error message.
Currently, vgrep stores it's paths relative to where it's being called from. That's why it's enforcing the cache to be loaded from the same directory.
Sure, but I am little confuse about this statement, "vgrep stores it's paths relative to where it's being called from. That's why it's enforcing the cache to be loaded from the same directory." not able wrap it around my head.
All , I was trying to say, I can build that in the buildir . The ,I should be able to call that binary(which I have specifically placed under my home/bin dir or it can be the default location i.e /usr/local/bin) . But when I try to call , it shows me this. How to cleanly use that??
Am I clear now?? Kindly let me know. WHY it is show "loading error cache..." why calling from other places??? Isn't it supposed to be called from anywhere on the system??? When the designated directory is included in PATH.
I must be seeing it differently than you. But again, I do not under stand this statement "vgrep stores it's paths relative to where it's being called from. That's why it's enforcing the cache to be loaded from the same directory." ...??????
In more simple term....
$ (this is my cloned and build dir of vgrep) and I made change the default install location to specific directory.
$ (Now I am at some other directory) and trying to call vgrep
.........
hence the error.
EVEN MOre so ...what the business of "cache" thing????? Purdon my naivety???? Why it is caching at all???
I'll try to answer the questions one by one.
When we're searching for something, e.g. $ vgrep foo, then vgrep stores the results in $HOME/.cache/vgrep-go. The reason for that is that we can later operate on these results and open the file locations in an editor via $ vgrep --show. Caching and loading the results is much faster than performing a search.
Now to the error message that you're seeing:
error loading cache: please cd into /home/bhaskar/git-linux/vgrep to use old cache
When we search $ vgrep foo the results we get from git grep or grep are relative to the current working directory and the paths are stored as is. As the paths are relative, we need to call vgrep --show/-s from the same directory where we searched the last time.
Bottom line: at the moment, previous results can only be loaded from within the same directory they have been searched at.
I think we can improve on that but for now, can you please do a $ vgrep foo, $ vgrep in the same directory and check if that's working?
"vgrep stores it's paths relative to where it's being called from. That's why it's enforcing the cache to be loaded from the same directory."
sure
Here is a screenshot of what you asked: https://imgur.com/ENnZuKs
"Bottom line: at the moment, previous results can only be loaded from within the same directory they have been searched at."
This is pretty much handicapped me to use it system-wide. It's not a complaint but my observation. As you said, it can be improved.
"When we're searching for something, e.g. $ vgrep foo, then vgrep stores the results in $HOME/.cache/vgrep-go. The reason for that is that we can later operate on these results and open the file locations in an editor via $ vgrep --show. Caching and loading the results is much faster than performing a search."
...>>>> I do agree. the cached previous result, retrieving much faster than doing a search anew.
When we search
$ vgrep foothe results we get fromgit greporgrepare relative to the current working directory and the paths are stored as is. As the paths are relative, we need to callvgrep --show/-sfrom the same directory where we searched the last time.
Again my naiveness ...see this link for screenshot too ... https://imgur.com/IJ8NVkf
The commands and expected suggestion not aligning ...kindly look closely ...end-users can easily get confused ...can you please rephrase those utilities?? Lot of "unhelpful" messages getting printed ...can you please get rid of those in the future and put some real helpful messages. I hope you get what I am driving at. It might turn out to be a great tool for "day to day use by everyone, not just two or three" ...I am hoping for it , if you can make it...
Thanks for the feedback!
When we search
$ vgrep foothe results we get fromgit greporgrepare relative to the current working directory and the paths are stored as is. As the paths are relative, we need to callvgrep --show/-sfrom the same directory where we searched the last time.Again my naiveness ...see this link for screenshot too ... https://imgur.com/IJ8NVkf
The commands and expected suggestion not aligning ...kindly look closely ...end-users can easily get confused ...can you please rephrase those utilities??
The syntax is explained in the README -> https://github.com/vrothberg/vgrep#opening-matches
Lot of "unhelpful" messages getting printed ...can you please get rid of those in the future and put some real helpful messages. I hope you get what I am driving at. It might turn out to be a great tool for "day to day use by everyone, not just two or three" ...I am hoping for it , if you can make it...
I wouldn't know how to improve the error messages but I gladly take pull requests! It would be great to have a man page at some point but it's a hobby project and I have only very limited time to work on it.