-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Fix crash when cwd is deleted #7185
Conversation
Thanks for reviewing ! |
07ad8e3
to
ba6ddc4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking good, just needs the clippy lints fixed
bb63440
to
e027009
Compare
should be fine now 🤞 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for being a bit late here. I put off reviewing this because I thin this is actually a bit more subtle to solve. IMO it's really unfortunate that get_cwd can fail (if the directory doesn't exist anymore) ideally I would still like to obtain the path and then fail when attempting any IO (which can always fail so no special handeling required).
This PR often uses unwrap_or_default
or other suboptimal fallback strategies. I would really like to avoid this as that can lead to other issues.
I think a better approach would be to track CWD in helix internally. Just store the path in a static that is intalized on startup (and if we fail to acquire the cwd on startup we can just exit with an error). The only way CWD can change at runtime is by using the command so we only need to update the static in that command.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like we will need to do some path expansion. mkdir tmp
and then either cargo r tmp
or cargo r
and then :cd tmp
: The directory will change correctly but current_working_dir
will return tmp
and not the full path. This messes up consumers like file_picker
that are expecting an expanded path.
I'm not totally sure where this expansion should belong. We could move
Lines 88 to 97 in c33795e
pub fn get_canonicalized_path(path: &Path) -> std::io::Result<PathBuf> { | |
let path = expand_tilde(path); | |
let path = if path.is_relative() { | |
std::env::current_dir().map(|current_dir| current_dir.join(path))? | |
} else { | |
path | |
}; | |
Ok(get_normalized_path(path.as_path())) | |
} |
set_current_working_dir
. That would shift around some dependencies and code between helix-core and helix-loader but might be the cleaner option. Or we could require that each caller of set_current_working_dir
passes in an absolute path (maybe a debug_assert could work here). What do you think?
Good catch! .we can actually use |
63fed09
to
def2505
Compare
updated ! thanks for spotting :) |
The call to std::env::current_dir might fail if the cwd has been deleted. As a way to prevent this from happening, we keep track internally of the current working directory and display an error message when any I/O is attempted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the two changes here we will probably want some feedback:
if !cwd.exists() {
editor.set_error("Current working directory does not exist");
return;
}
since the file_picker_in_current_directory won't show any files and global_search won't be able to find any matches if the cwd doesn't exist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good 👍
I like the "deleted" message in the show_current_directory
too, that's a nice touch
Should solve #2527
I didn't figure out how to set an error on the editor from some places.
Where is was crashing before, it now relies on the scratch buffer instead.
In some other places (not related to buffer, like the
open
command or the global search ), I was able to generate a message or rely on the default value of the PathBuffer.Let me know any improvements/suggestions you can see, I'll be more than happy to correct them :)