Closed bestouff closed 6 years ago
What's the point of pointing to a nonexisting location? How should the user know it's the case?
There's not point really, but it can happen (it happened to me). In this case, rusty-tags should probably just print a warning and do its job anyway.
There's not point really, but it can happen (it happened to me). In this case, rusty-tags should probably just print a warning and do its job anyway.
The problem is, the user will only see this warning if he's running it from the command line.
Otherwise he will only take notice if an error is returned, and
programs calling rusty-tags
communicate this error to the user.
If the user has set RUST_SRC_PATH, he also most likely wants tags for the rust standard library, by not making this an error as early as possible it will only take more time for the user.
So, I can see your point but think that overall it's better to return an error.
Let me give you some context: the error happened when I was saving a file under vim; I saw the error on the last line of the terminal (so yes, the error was visible) but because of it is was impossible to save the file. Seeing this problem with data in the buffer and not being able to save is quite un uncomfortable place to be. So OK, it shouldn't happen but when it does, rusty-tags should say so a bit more gracefully, IMO.
So OK, it shouldn't happen but when it does, rusty-tags should say so a bit more gracefully, IMO.
I honestly can't see a more graceful handling without sacrificing something else.
In your case it seems more about using the BufWritePost
instead of the BufWrite
command.
Can you please test if this solves the problem of saving the file, then I will update the README.
Perhaps FileWritePost
is even better.
FileWritePost
seems to work in my case.
The README now contains BufWritePost
.
After setting the
RUST_SRC_PATH
var pointing to a nonexistent location, rusty-tags fails. It should probably just generate tags as far as it can.