-
-
Notifications
You must be signed in to change notification settings - Fork 610
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(show_file_size): optionally show Size Information on right column #2857
Conversation
6fdbb51
to
8d44388
Compare
This looks great; I'm limited by time however I will get to it. |
end | ||
|
||
-- Here we do a partial redraw of only a subsection of extra marks. | ||
-- We could simply call reloaders.reload(), but that would be substantially slower. |
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.
Thank you.
file size information will take. | ||
Type: `integer`, Default: `10` | ||
|
||
*nvim-tree.renderer.size.show_folder_size* |
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.
I'm not sure how much value this is; it's only showing the fs_stat size - the folder's size, rather than the content size.
Could we just leave folders out completely?
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.
As of right now there's no value indeed, but I'd like to support content size information.
What do you think two approaches to getting content size of a folder:
- recursively calculate once the content size for each folder, and then update folder fize information as files are moved or changed
- call external
df -h -s
(there must the something like it for windows) on the folder and render that.
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.
2. call external
df -h -s
(there must the something like it for windows) on the folder and render that.
That would be really transparent and a good default for most users. It could be a user configurable like trash.cmd
so that windows users could do whatever they need to do, and linux/macos users could use an alternate like tree
- recursively calculate once the content size for each folder, and then update folder fize information as files are moved or changed
That would work well as it would sidestep any performance issues:
The watchers get a notification for the directory itself so they could do it in the async job. We'd just need to recalculate folders up the tree afterwards.
R
could calculate everything. It's synchronous, but we know that a full refresh takes time.
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.
Do you want to do folders in a follow up PR? File sizes is pretty much ready to go...
o.noshow_folder_size_glyph = opts.renderer.size.noshow_folder_size_glyph or "" | ||
o.column_width = opts.renderer.size.column_width | ||
o.show_folder_size = opts.renderer.size.show_folder_size | ||
o.units = { "B", "KB", "MB", "GB", "TB", "PB", "EB", "ZB", "YB" } |
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.
Can we please use the IEC KiB MiB etc.? Someone will complain about SI units...
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.
/nit can this be an enum? We could expose it to the user via API luadoc.
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.
Yeah, actually.
An enum might be the cleanest ideia.
-- on a given iteration you have : | ||
-- 1024 YB, then index is equal to #units, normally we would devide again, | ||
-- but we don't have more units, so keep as is. | ||
while size >= 1024 and index < #self.units do |
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.
Could we do something really dumb like:
- convert size to a string
- calculate string length
- div 3 to get the index
@@ -338,6 +338,19 @@ local function setup_autocommands(opts) | |||
}) | |||
end | |||
|
|||
if opts.renderer.size.enable then | |||
create_nvim_tree_autocmd({ "WinResized", "VimResized" }, { | |||
-- NOTE: for some reason WinResized doesn't work with pattern |
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 happens for a few autocommands. You can remove the comment.
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.
Oh, ok, ty for info
@@ -827,6 +859,22 @@ function M.setup(conf) | |||
log.raw("config", "%s\n", vim.inspect(opts)) | |||
end | |||
|
|||
if M.config.renderer.size.column_width < 6 then | |||
notify.warn "`size.right_padding` is a small number, problably won't show any size numbers, try using 10." |
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.
nvim-tree is a sharp tool, users can cut themselves as they wish.
Whenever we try to do something like this users complain vehemently.
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.
Glad to know it
column_width = 10, | ||
show_folder_size = false, | ||
format_unit = "double", | ||
noshow_folder_size_glyph = "•", |
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.
I'm always nervous about too many options however I predict that users will want:
precision = 2
I know that I'll be setting it to 0.
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.
yes, as I'm using I feel the 2 precision is just unnecessary. I'll get on it.
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 fantastic! You are quite the prolific contributor...
A few bugs, some option tweaking and this should be good.
I'll dogfood this foor a week.
Ty, ty. |
Closing as this PR is stale. Please reopen if you wish to continue this work. |
Description
This PR make nvim-tree be able to display file size information as a decoration. It uses newly introduced
right_align
feature to create a column that shows size info. It allows to customization options to display file sizes in a human-readable format (e.g., MB, GB). It also exposes the highlight groupNvimTreeFileSize
.Showcase
Setup:
Improvements that could be made:
EDIT: This improvement were made. We now support conditionally hiding size information based on current width and width cutoff setting as shown below.
2024-08-01.01-16-10.mp4
The hiding is decently fast because it only does a partial redraw of extra marks as opposed to reloading the whole tree everytime the cutoff is triggered.