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
feat: refresh all items in view / selected item #219
Conversation
- it doesn't deal with sub-trees - for that it would need awareness of the method that integrates tree events. - selection handling isn't implemented, so the selection just disappears. - if the root to be refreshed still exists, it should probably keep it selected instead of removing it. - it seems useful to have some control over the scope of the refresh, and these are sketched with the `Refresh` enum.
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.
Thanks a lot for your help, it's greatly appreciated!
I only took a very quick look and wanted to see what's implemented, but couldn't see the keys to press in the help pane yet - I wanted to find out if R
is refresh all, or just the selection, I wasn't sure.
Further, I'd really hope the selection could be restored after the refresh finished.
It also seems to replace the current search with another one if pressing R
again or r
while a search is running, even the initial search, which can lead the search stopping on the way. This might be a hidden feature though, I don't know, it felt a bit wonky until I understood what's happening.
In any case, please let me know what's still on your list or if you'd like to continue working on the PR, otherwise I might try to do my usual hands-on review once I find the time.
Thanks for taking a look.
Ah, I have forgotten to add the keys to the help page. I will add that in a second. [done]
I didn't look into restoring selection too much. What I have seen it looked more complicated than I have thought initially. Mainly because selection is based on the
I have played with it a bit, and I couldn't break it, but it may be good idea to block starting another refresh if there is one already running. [done]
I don't think there is anything left for this PR other than the things you have mentioned. Here is a list of some other things that are worth improving separately:
self.directory_info_per_depth_level
.push(self.current_directory_at_depth);
self.current_directory_at_depth = EntryInfo::default();
for _ in 0..self.previous_depth {
let dir_info = pop_or_panic(&mut self.directory_info_per_depth_level);
self.current_directory_at_depth.size += dir_info.size;
self.current_directory_at_depth.add_count(&dir_info);
set_entry_info_or_panic(
&mut traversal.tree,
self.parent_node_idx,
self.current_directory_at_depth,
);
self.parent_node_idx =
parent_or_panic(&mut traversal.tree, self.parent_node_idx);
}
// TODO: this looks like a hack to fix the problem with the loop above
// that doesn't seem to completely drain elements from `directory_info_per_depth_level`
let root_size = traversal.recompute_node_size(self.root_idx);
set_entry_info_or_panic(
&mut traversal.tree,
self.root_idx,
EntryInfo {
size: root_size,
entries_count: (self.stats.entries_traversed > 0)
.then_some(self.stats.entries_traversed),
},
); |
* Added keys to the Help page. * Starting a new traversal is blocked if another traversal is already running. * Glob search is blocked if traversal is already running.
@Byron I have done a quick solution for preserving the selection based on the This PR is ready for review. |
@Byron Just checking that this has not been buried / lost among other notifications :) |
It's more effort, which should be reflrected in the amount of work done as well, which I think is more intuitive.
- show messages that indicate why sometimes key-presses are ignored - maintain previous selection in a clearer fashion - maintain seelction from glob-mode as well - switch title to `entry` as it's not only 'file's there, also directories. - also show how many entries there are visible
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.
Thanks a lot for your continued contributions! It seems that all major feature requests have now been addressed thanks to you!
Once things settle a bit, one might consider to pin them down by adding journey tests, particularly for the more intricate behaviour like selection handling upon refresh - I myself managed to break it one too many times during refactor 😅.
One note shall be added here: I removed files
as term, but also didn't bring back item
. Instead I went with entry
which I hope is some sort of middle ground. The reason for this is that an entry is a file or directory.
Once CI is green I will create a new release.
On this note, I think it's fair to expect me to have missed something if you wait for a week or so, as me missing anything is quite unlikely due to using my inbox as task-list. |
@Byron I didn't want to ping you unnecessarily, because I am sure you are busy with other things and you will get to it once you are free, however I also got used to you responding to my PRs within hours :) Going forward I will give you more time :)
Yes, agree. I will try to focus on adding some more tests, but after that you probably not going to receive too many PRs from me, unless someone comes with some super exciting feature that is worth implementing :) It was fun working on this project, and learning how to do TUI in Rust :) |
Implements feature requested in #96.
This PR includes: