Skip to content
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

Closed
wants to merge 6 commits into from

Conversation

evertonse
Copy link
Collaborator

@evertonse evertonse commented Jul 30, 2024

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 group NvimTreeFileSize.

Showcase

image

Setup:

require'nvim-tree'.setup {
  renderer = {
    size = {
      enable = true,
      column_width = 12, -- max chars allowed to fill the column
      show_folder_size = false,
      format_unit = "double", -- or "single" or a custom function
    }
  }
}

Improvements that could be made:

  • Conditionally show file size information based on the current nvim-tree width in both floating and normal views.

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.

@evertonse evertonse marked this pull request as draft July 30, 2024 07:41
@evertonse evertonse force-pushed the feat/show_file_size branch from 6fdbb51 to 8d44388 Compare July 30, 2024 07:49
@evertonse evertonse changed the title feat(show_file_size): feat(show_file_size): Optionally show a right column with size information Aug 1, 2024
@evertonse evertonse changed the title feat(show_file_size): Optionally show a right column with size information feat(show_file_size): optionally show Size Information on right column Aug 1, 2024
@evertonse evertonse marked this pull request as ready for review August 1, 2024 04:54
@alex-courtis
Copy link
Member

This looks great; I'm limited by time however I will get to it.

@alex-courtis
Copy link
Member

Looks like we might need special handling for dotted files:

20240804_151418

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you.

@alex-courtis
Copy link
Member

alex-courtis commented Aug 4, 2024

Looks like some inconsistency around right_align icons. Every icon right:

Bookmarks go far far right for dotfiles unless there's another icon.
They lose the final character of the name, in this case bookmarking .clang-format will remove the t.

20240804_153638

file size information will take.
Type: `integer`, Default: `10`

*nvim-tree.renderer.size.show_folder_size*
Copy link
Member

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?

Copy link
Collaborator Author

@evertonse evertonse Aug 4, 2024

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:

  1. recursively calculate once the content size for each folder, and then update folder fize information as files are moved or changed
  2. call external df -h -s (there must the something like it for windows) on the folder and render that.

Copy link
Member

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

  1. 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.

Copy link
Member

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" }
Copy link
Member

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...

Copy link
Member

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.

Copy link
Collaborator Author

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
Copy link
Member

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
Copy link
Member

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.

Copy link
Collaborator Author

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."
Copy link
Member

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.

Copy link
Collaborator Author

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 = "•",
Copy link
Member

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.

Copy link
Collaborator Author

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.

Copy link
Member

@alex-courtis alex-courtis left a 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.

@evertonse
Copy link
Collaborator Author

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.
I'll find some time this week to get to those bugs.

@alex-courtis
Copy link
Member

Closing as this PR is stale. Please reopen if you wish to continue this work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants