Show path in file picker and explorer #12806
Conversation
|
@David-Else is this what you were talking about when you said where the path of the pickers should be? The path is directly above the items, replacing the usual picker column headers. I actually really like this idea! |
helix-term/src/ui/mod.rs
Outdated
| @@ -235,7 +235,7 @@ pub fn file_picker(root: PathBuf, config: &helix_view::editor::Config) -> FilePi | |||
| log::debug!("file_picker init {:?}", Instant::now().duration_since(now)); | |||
|
|
|||
| let columns = [PickerColumn::new( | |||
| "path", | |||
| root.to_string_lossy(), | |||
There was a problem hiding this comment.
Instead of showing the absolute path, I think it'd be cleaner to show the relative path. Using helix_stdx::path::get_relative_path
There was a problem hiding this comment.
Sounds good to me. The only issue is when a picker is opened at the working directory, we show a blank header. Any suggestions on what to do here?
As far as I can tell, everywhere else we call get_relative_path, it's for a file and not a directory, so it doesn't have this problem.
There was a problem hiding this comment.
If picker's current directory is the same as helix's current directory, then showing the full path in that case is probably fine
There was a problem hiding this comment.
That becomes a bit jarring when using the file exploring and changing directories. I think it's better to have a consistent experience and just use the full path always if we're going to use it sometimes, but can change it if folks feel strongly.
There was a problem hiding this comment.
That becomes a bit jarring when using the file exploring and changing directories. I think it's better to have a consistent experience and just use the full path always if we're going to use it sometimes, but can change it if folks feel strongly.
Agreed
Yes. this is where I thought it should be. Seeing it on the screen, I am still not sure it is correct. but best yet. I agree it should show the relative path, regarding showing a blank line when opened in the root dir, why not show |
Showing |
paholg
force-pushed
the
file-picker-path
branch
from
499d629 to
45b6d29
Compare
|
I have updated it to show the relative path or |
helix-term/src/ui/mod.rs
Outdated
| pub fn get_relative_dir(path: &Path) -> Cow<'static, str> { | ||
| let path = helix_stdx::path::get_relative_path(path); | ||
| if path.components().next().is_none() { | ||
| "./".into() | ||
| } else { | ||
| let mut str = path.to_string_lossy().into_owned(); | ||
| if path.is_dir() { | ||
| str.push('/'); | ||
| } | ||
|
|
||
| str.into() | ||
| } | ||
| } |
There was a problem hiding this comment.
isn't this always called with a directory as entry (&root) ? Could we dispense the FS check (slow) then ?
The file picker and explorer can each be opened in several ways, each causing it to have a different root path. What's more, the file explorer can change its path while you have it open. This can make it very difficult to keep track of the root directory for these pickers, so we add it as a header. If desired, we could alternatively make this a configuration option, but I see little downside to always including it.
paholg
force-pushed
the
file-picker-path
branch
from
45b6d29 to
381e2e5
Compare
The file picker and explorer can each be opened in several ways, each causing it to have a different root path. What's more, the file explorer can change its path while you have it open.
This can make it very difficult to keep track of the root directory for these pickers, so we add it as a header.
If desired, we could alternatively make this a configuration option, but I see little downside to always including it.
Example: