[ELPA] New package: disk-usage

[ELPA] New package: disk-usage

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

Hi!

I'm happy to announce disk-usage.el
(https://gitlab.com/ambrevar/emacs-disk-usage), a disk analyzer for Emacs!

It displays a tabulated list of files and folders along their size in a select
directory.

Features:

- It's an Emacs buffer, you can use all Emacs facilities (search, multiple
  buffers, etc.).

- Results are cached and disk-usage.el should generally be very fast.

- Directories can be explored up and down, re-using the cache.  (ncdu can not even go "up" without
  rescanning everything).

- File listings can be displayed recursively (all files in all subfolders).

- Toggle "human size" display.

- Display size statistics by extension.

- Sort by any column (size, filename, extension, percentage, etc.).

- Open current entry in Dired/M-x shell/Eshall/<you-name-it>.

I decided to work on this as an answer to years of frustration with more limited
tools such as ncdu (my last ncurses application).

It already has Evil bindings in Evil collection
(https://github.com/emacs-evil/evil-collection) and a Guix package.

I'd like to add this item to ELPA as an external.  Let me know if there
is anything.

Feedback is more than welcome!

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ELPA] New package: disk-usage

[Clément Pit-Claudel]

On 19/02/2019 03.49, Pierre Neidhardt wrote:
> I'm happy to announce disk-usage.el
> (https://gitlab.com/ambrevar/emacs-disk-usage), a disk analyzer for Emacs!

This looks great!  It works smoothly here.  Thanks for working on this :)

Some questions:
* Out of curiosity, why do you use `find . -type f -exec du -sb {} +` instead of a plain `du -ab`? (Also, wouldn't that save you the extra step of computing disk-usage--total?)
* Could you use the same face for directories as dired uses (rather than the hyperlink face)?  In fact, is there any way that this could be integrated more tightly with dired?  For example, I got bitten by the face that d exits the disk-usage window, instead of marking a file for deletion. 
* Using a visual representation (a sort of progress bar) instead of a percentage could be nice (on graphic terminals only, of course).  You could implement it like this:
  
  (defun disk-usage--make-progress-bar (pct)
    (let ((width 5))
      (concat (propertize " " 'face '(:reverse-video t) 'display `(space :width ,(* width pct)))
              (propertize " " 'display `(space :width ,(* width (- 1 pct)))))))

  (defun disk-usage--refresh (&optional directory)
    …
                      (list file-info (vector (number-to-string (disk-usage--file-info-size file-info))
                                              (disk-usage--make-progress-bar
                                               (/ (float (disk-usage--file-info-size file-info))
                                                  total-size))
    …


Thanks again for the great work!
Clément.

> It displays a tabulated list of files and folders along their size in a select
> directory.
> 
> Features:
> 
> - It's an Emacs buffer, you can use all Emacs facilities (search, multiple
>   buffers, etc.).
> 
> - Results are cached and disk-usage.el should generally be very fast.
> 
> - Directories can be explored up and down, re-using the cache.  (ncdu can not even go "up" without
>   rescanning everything).
> 
> - File listings can be displayed recursively (all files in all subfolders).
> 
> - Toggle "human size" display.
> 
> - Display size statistics by extension.
> 
> - Sort by any column (size, filename, extension, percentage, etc.).
> 
> - Open current entry in Dired/M-x shell/Eshall/<you-name-it>.
> 
> I decided to work on this as an answer to years of frustration with more limited
> tools such as ncdu (my last ncurses application).
> 
> It already has Evil bindings in Evil collection
> (https://github.com/emacs-evil/evil-collection) and a Guix package.
> 
> I'd like to add this item to ELPA as an external.  Let me know if there
> is anything.
> 
> Feedback is more than welcome!
> 
> Cheers!
> 

Re: [ELPA] New package: disk-usage

[Eli Zaretskii]

> From: Pierre Neidhardt <mail@ambrevar.xyz>
> Date: Tue, 19 Feb 2019 09:49:24 +0100
> 
> I'm happy to announce disk-usage.el
> (https://gitlab.com/ambrevar/emacs-disk-usage), a disk analyzer for Emacs!
> 
> It displays a tabulated list of files and folders along their size in a select
> directory.

Thanks.

Is there a reason why you didn't use get-free-disk-space?  AFAICT,
using that would make your package more portable, since 'find' and
'du' are only available by default on Posix hosts.

Re: [ELPA] New package: disk-usage

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

> Is there a reason why you didn't use get-free-disk-space?  AFAICT,
> using that would make your package more portable, since 'find' and
> 'du' are only available by default on Posix hosts.

Hmm... Isn't this the complement of what this package does, that is, computing
the used space?

I don't see how get-free-disk-space could be used here, it does not tell the
space used by files or folders.  Let me know if I misunderstood.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ELPA] New package: disk-usage

[Eli Zaretskii]

> From: Pierre Neidhardt <mail@ambrevar.xyz>
> Cc: emacs-devel@gnu.org
> Date: Tue, 19 Feb 2019 17:26:43 +0100
> 
> > Is there a reason why you didn't use get-free-disk-space?  AFAICT,
> > using that would make your package more portable, since 'find' and
> > 'du' are only available by default on Posix hosts.
> 
> Hmm... Isn't this the complement of what this package does, that is, computing
> the used space?
> 
> I don't see how get-free-disk-space could be used here, it does not tell the
> space used by files or folders.  Let me know if I misunderstood.

Oops, you are right.  ENOCOFFEE, I guess.

Still, using directory-files-and-attributes etc. would be more
portable than doing it with 'find' and 'du'.

Re: [ELPA] New package: disk-usage

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]


> Still, using directory-files-and-attributes etc. would be more
> portable than doing it with 'find' and 'du'.

That's what I do, actually.  I've provided two "listing" functions (customizable):

- disk-usage--directory-size-with-emacs: use `directory-files-and-attributes'
  recursively everywhere.  This is portable but very slow.

- disk-usage--directory-size-with-du: This uses `directory-files-and-attributes'
  on the root folder to get the size of its direct subfiles, then `du -sb' on
  the remaining subfolders.  This is much faster.

Makes sense?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ELPA] New package: disk-usage

[Eli Zaretskii]

> From: Pierre Neidhardt <mail@ambrevar.xyz>
> Cc: emacs-devel@gnu.org
> Date: Tue, 19 Feb 2019 20:29:03 +0100
> 
> > Still, using directory-files-and-attributes etc. would be more
> > portable than doing it with 'find' and 'du'.
> 
> That's what I do, actually.  I've provided two "listing" functions (customizable):
> 
> - disk-usage--directory-size-with-emacs: use `directory-files-and-attributes'
>   recursively everywhere.  This is portable but very slow.
> 
> - disk-usage--directory-size-with-du: This uses `directory-files-and-attributes'
>   on the root folder to get the size of its direct subfiles, then `du -sb' on
>   the remaining subfolders.  This is much faster.
> 
> Makes sense?

AFAICT, which one to use is left to the user, but I think it should be
automatically deduced by the package, in particular depending on
whether 'find' and 'du' are available.

Re: [ELPA] New package: disk-usage

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]


> AFAICT, which one to use is left to the user, but I think it should be
> automatically deduced by the package, in particular depending on
> whether 'find' and 'du' are available.

Makes sense, I'll change that.  Thanks for the tip!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ELPA] New package: disk-usage

[Michael Albinus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Hi!

Hi Pierre,

> I'm happy to announce disk-usage.el
> (https://gitlab.com/ambrevar/emacs-disk-usage), a disk analyzer for Emacs!

Thanks!

Is there a reason you apply `call-process' instead of `process-file'?
With the latter, you could scan also directories on remote machines.

> Feedback is more than welcome!

One suggestion: you know for sure key bindings. Other people won't.
Maybe you could add a menue for your *disk-usage<...>* buffers?

Furthermore, could you pls adapt Emacs coding rules? Respecting 80
columns per line max, providing a docstring for all functions comes to
mind. This would help to read your code.

> Cheers!

Best regards, Michael.

Re: [ELPA] New package: disk-usage

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

> Thanks!

Thanks for the feedback!

> Is there a reason you apply `call-process' instead of `process-file'?
> With the latter, you could scan also directories on remote machines.

Nope, will do, just forgot about it (bad habit).

> One suggestion: you know for sure key bindings. Other people won't.
> Maybe you could add a menue for your *disk-usage<...>* buffers?

Isn't `describe-mode' enough?

> Furthermore, could you pls adapt Emacs coding rules? Respecting 80
> columns per line max, providing a docstring for all functions comes to
> mind. This would help to read your code.

Will do.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ELPA] New package: disk-usage

[Michael Albinus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

Hi Pierre,

>> Is there a reason you apply `call-process' instead of `process-file'?
>> With the latter, you could scan also directories on remote machines.
>
> Nope, will do, just forgot about it (bad habit).

Thanks. And in case you want to support different command arguments per
host, you might think about connection-local variables.

>> One suggestion: you know for sure key bindings. Other people won't.
>> Maybe you could add a menue for your *disk-usage<...>* buffers?
>
> Isn't `describe-mode' enough?

Of course, and I did. But a menue is more convenient. 'C-h m' returns:

--8<---------------cut here---------------start------------->8---
key             binding
---             -------

TAB		forward-button
ESC		Prefix Command
SPC		scroll-up-command
-		negative-argument
0 .. 9		digit-argument
<		beginning-of-buffer
>		end-of-buffer
?		describe-mode
R		disk-usage-toggle-recursive
S		tabulated-list-sort
^		disk-usage-up
d		disk-usage-dired-at-point
e		disk-usage-eshell-at-point
f		disk-usage-toggle-full-path
g		revert-buffer
h		disk-usage-toggle-human-readable
m		disk-usage-mark
n		next-line
p		previous-line
q		quit-window
u		disk-usage-unmark
x		disk-usage-delete-marked-files
DEL		scroll-down-command
S-SPC		scroll-down-command
<S-return>	disk-usage-find-file-at-point
<backspace>	disk-usage-up
<backtab>	backward-button
<follow-link>	mouse-face
<mouse-2>	mouse-select-window
  (that binding is currently shadowed by another mode)
<remap>		Prefix Command

C-M-i		backward-button
--8<---------------cut here---------------end--------------->8---

A longer list than needed; the relevant keys must be found.

Ahh, and applying 'e' (disk-usage-eshell-at-point) returns

--8<---------------cut here---------------start------------->8---
eshell-mode: Wrong type argument: stringp, nil
--8<---------------cut here---------------end--------------->8---

> Cheers!

Best regards, Michael.

describe-mode bindings (was: [ELPA] New package: disk-usage)

[Stefan Monnier]

> Of course, and I did. But a menue is more convenient. 'C-h m' returns:
[...]
> --8<---------------cut here---------------end--------------->8---
> A longer list than needed; the relevant keys must be found.

Maybe `C-h m` should be improved to distinguish the mode's own bindings
from the ones inherited from the parent keymap!?


        Stefan

Re: describe-mode bindings (was: [ELPA] New package: disk-usage)

[Clément Pit-Claudel]

On 19/02/2019 15.58, Stefan Monnier wrote:
>> Of course, and I did. But a menue is more convenient. 'C-h m' returns:
> [...]
>> --8<---------------cut here---------------end--------------->8---
>> A longer list than needed; the relevant keys must be found.
> 
> Maybe `C-h m` should be improved to distinguish the mode's own bindings
> from the ones inherited from the parent keymap!?

An overhaul of C-h m would be nice.  In biblio.el I list the docstrings along with the commands, so h gives this:

    Help with ‘biblio-selection-mode’

    ‘C-p’, ‘<up>’ (biblio--selection-previous)
      Move to previous search result.

    ‘C-n’, ‘<down>’ (biblio--selection-next)
      Move to next search result.

    ‘RET’ (biblio--selection-browse)
      Open the web page of the current entry in a web browser.

    ‘C-RET’, ‘<C-return>’ (biblio--selection-browse-direct)
      Open the full text of the current entry in a web browser.

    ‘c’, ‘M-w’ (biblio--selection-copy)
      Copy BibTeX of current entry at point.

    ‘C’, ‘C-w’ (biblio--selection-copy-quit)
      Copy BibTeX of current entry at point and close results.
    
    … etc.

… while C-h m gives this:

    Bibliographic search results (→ magit: mpd) mode defined in ‘biblio-core.el’:
    Browse bibliographic search results.
    key             binding
    ---             -------

    RET             biblio--selection-browse
    C-n             biblio--selection-next
    C-p             biblio--selection-previous
    C-w             biblio--selection-copy-quit
    C-y             biblio--selection-insert-quit
    ESC             Prefix Command
    ?               biblio--selection-help
    C               biblio--selection-copy-quit
    I               biblio--selection-insert-quit
    b               biblio--selection-change-buffer
    c               biblio--selection-copy
    h               biblio--selection-help
    i               biblio--selection-insert
    q               quit-window
    x               biblio--selection-extended-action
    C-RET           biblio--selection-browse-direct
    <C-return>      biblio--selection-browse-direct
      (that binding is currently shadowed by another mode)
    <down>          biblio--selection-next
    <up>            biblio--selection-previous

    M-w             biblio--selection-copy

Re: [ELPA] New package: disk-usage

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]


> Thanks. And in case you want to support different command arguments per
> host, you might think about connection-local variables.

Why not, but I cannot test at the moment, I would need an example here.

> A longer list than needed; the relevant keys must be found.

True, but isn't it an issue with all of Emacs?  Wouldn't we need a common
interface here?

> Ahh, and applying 'e' (disk-usage-eshell-at-point) returns

Thanks for that one!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ELPA] New package: disk-usage

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 143 bytes --]

ELPA question with externals: do I need to push to ELPA manually or is it done automatically?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ELPA] New package: disk-usage

[Stefan Monnier]

> ELPA question with externals: do I need to push to ELPA manually or is
> it done automatically?

It's not done automatically (the manual push is a way to state that you
believe that code is covered by the copyright paperwork of the
respective contributors).

If you don't have write access yet, you can ask for it (request
membership in the `emacs` group from your Savannah account) or you can
ask me to pull from some Git branch,


        Stefan

Re: [ELPA] New package: disk-usage

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 205 bytes --]

I've released 1.2.0.
I'm not sure I have write access to ELPA so that I can udpate the disk-usage
package.  Is there something I should do in particular?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ELPA] New package: disk-usage

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

Also see this link:
https://old.reddit.com/r/emacs/comments/as8cri/diskusageel_a_disk_usage_analyzer_for_emacs/egxk1z0/

Purcell argues that Stefan should not have used `eval-when-compile' for
`cl-lib`:

--8<---------------cut here---------------start------------->8---
(eval-when-compile (require 'cl-lib))
--8<---------------cut here---------------end--------------->8---

because `cl-first' is used in some places.

I'd tend to agree with Purcell.  Thoughts?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ELPA] New package: disk-usage

[Stefan Monnier]

> Purcell argues that Stefan should not have used `eval-when-compile' for
> `cl-lib`:
>
> --8<---------------cut here---------------start------------->8---
> (eval-when-compile (require 'cl-lib))
> --8<---------------cut here---------------end--------------->8---
>
> because `cl-first' is used in some places.
>
> I'd tend to agree with Purcell.  Thoughts?

If you use #'cl-first then you definitely need to remove the
eval-when-compile, indeed.

But if you have direct calls to cl-first, then they will be compiled
into byte-code which do not refer to `cl-first` any more (IOW the
cl-first definition has been inlined by the compiler).
Hence your code should still work with eval-when-compile.
[ Yes: the exact conditions under which a library can be `require`d
  inside `eval-when-compile` can be pretty subtle.  ]

I used eval-when-compile because it seemed to work, but feel free to
change it, whether for technical reasons or just out of
personal preference.


        Stefan

Re: [ELPA] New package: disk-usage

[Michael Albinus]

[-- Attachment #1: Type: text/plain, Size: 291 bytes --]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

Hi Pierre,

> I've released 1.2.0.

Thanks. I needed to apply the following patch to make it work on remote
systems. In my local environment, I could test it on "/sudo::"; it makes
a difference because "/root" is readable only for user "root".


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 2758 bytes --]

*** /home/albinus/.emacs.d/elpa/disk-usage-1.2.0/disk-usage.el.~1~	2019-02-26 11:50:08.976859553 +0100
--- /home/albinus/.emacs.d/elpa/disk-usage-1.2.0/disk-usage.el	2019-02-26 12:21:11.661869542 +0100
***************
*** 290,298 ****
    "This is the equivalent of running the shell command
  $ find . -type f -exec du -sb {} +"
    (setq directory (or directory default-directory))
!   (let ((pair-strings (split-string (with-temp-buffer
                             (process-file disk-usage--find-command nil '(t nil) nil
!                                          directory
                                           "-type" "f"
                                           "-exec"
                                           disk-usage--du-command
--- 290,299 ----
    "This is the equivalent of running the shell command
  $ find . -type f -exec du -sb {} +"
    (setq directory (or directory default-directory))
!   (let* ((default-directory directory)
! 	 (pair-strings (split-string (with-temp-buffer
                             (process-file disk-usage--find-command nil '(t nil) nil
!                                          (file-local-name directory)
                                           "-type" "f"
                                           "-exec"
                                           disk-usage--du-command
***************
*** 301,307 ****
                                      "\n" 'omit-nulls)))
      (cl-loop for pair-string in pair-strings
               for pair = (split-string pair-string "\t")
!              for name = (cadr pair)
               for attributes = (file-attributes name)
               when (cl-loop for filter in disk-usage-filters
                             always (funcall filter name attributes))
--- 302,308 ----
                                      "\n" 'omit-nulls)))
      (cl-loop for pair-string in pair-strings
               for pair = (split-string pair-string "\t")
!              for name = (concat (file-remote-p directory) (cadr pair))
               for attributes = (file-attributes name)
               when (cl-loop for filter in disk-usage-filters
                             always (funcall filter name attributes))
***************
*** 351,357 ****
         (with-output-to-string
           (process-file disk-usage--du-command
                         nil '(t nil) nil
!                        disk-usage--du-args path))
         (buffer-string))))))
  
  (defun disk-usage--sort-by-size (a b)
--- 352,358 ----
         (with-output-to-string
           (process-file disk-usage--du-command
                         nil '(t nil) nil
!                        disk-usage--du-args (file-local-name path)))
         (buffer-string))))))
  
  (defun disk-usage--sort-by-size (a b)

[-- Attachment #3: Type: text/plain, Size: 794 bytes --]


There are further things to be improved:

* In `disk-usage--list-recursively', you make a loop over

             for attributes = (file-attributes name)

  This is slow, at least on remote systems, because you apply
  `file-attributes' on every file on a possibly large list. Maybe you
  could call `directory-files-and-attributes' per directory, instead.
  
* As said before, the commands you apply might vary on different
  hosts. For example, on my QNAP NAS server, getting du info on "/tmp"
  with "find /tmp -type f -exec du -sb \{\} \+" does not work. It must
  be "find /tmp -type f | xargs du -sb" instead. So the commands must be
  configurable per host. See for example, how `grep-host-defaults-alist'
  is computed via `grep-compute-defaults' in grep.el.
  
Best regards, Michael.

Re: [ELPA] New package: disk-usage

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]

Great review, thanks you very much.  I'll apply all your suggestions.  Need to
discuss this one though:

> * In `disk-usage--list-recursively', you make a loop over
>
>              for attributes = (file-attributes name)
>
>   This is slow, at least on remote systems, because you apply
>   `file-attributes' on every file on a possibly large list. Maybe you
>   could call `directory-files-and-attributes' per directory, instead.

Hmmm, not sure about this, because walking a directory recursively with
directory-files-and-attributes is extremely slow, which is why I resorted to
using the `find' shell command instead.

Alternatively, I could mix-match both approaches:  run `find' to list all
directories recursively, then run `directory-files-and-attributes` on this result.

Does anyone have experience with that kind of performance issues?

The upside is that it would remove the need for custom `find' arguments since
the following is portable:

--8<---------------cut here---------------start------------->8---
  find DIR -type d
--8<---------------cut here---------------end--------------->8---

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ELPA] New package: disk-usage

[Michael Albinus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Alternatively, I could mix-match both approaches:  run `find' to list all
> directories recursively, then run `directory-files-and-attributes` on
> this result.

That's what I had in my mind.

Best regards, Michael.

Re: [ELPA] New package: disk-usage

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

Hi Michael,

I've pushed your suggestions.

- Regarding the TRAMP issue, I fail to test with "/sudo::", probably because
  `find/du` cannot run there.  Let me know if it works for you on remote machines.

- Regarding the optimization, local tests show no difference.  Let me know if
  you notice a significant improvement remotely.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ELPA] New package: disk-usage

[Michael Albinus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Hi Michael,

Hi Pierre,

> - Regarding the TRAMP issue, I fail to test with "/sudo::", probably because
>   `find/du` cannot run there.  Let me know if it works for you on
> remote machines.
>
> - Regarding the optimization, local tests show no difference.  Let me know if
>   you notice a significant improvement remotely.

Could you pls sync with elpa? I would check then.

> Cheers!

Best regards, Michael.

Re: [ELPA] New package: disk-usage

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 55 bytes --]

Done.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ELPA] New package: disk-usage

[Michael Albinus]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Hi Michael,

Hi Pierre,

> I've pushed your suggestions.

Thanks.

> - Regarding the TRAMP issue, I fail to test with "/sudo::", probably because
>   `find/du` cannot run there.  Let me know if it works for you on
> remote machines.

I did need to apply further changes to let it run sufficiently on /sudo::

* In disk-usage--list-recursively, the (concat (file-remote-p ...) trick
  must be applied earlier.

* In disk-usage--list-recursively and disk-usage--list I needed to adapt
  the directory-files-and-attributes call; otherwise also /. and
  /.. would be reported.

If the remote case still doesn't work for you, set tramp-verbose to 6,
and rerun the test. Show the resulting Tramp debug buffer.

> - Regarding the optimization, local tests show no difference.  Let me know if
>   you notice a significant improvement remotely.

I have no figures, but it feels faster.

One other point worth to fix: Pls don't run
disk-usage-toggle-recursive globally. It shall affect only the current
buffer; I don't want to have a recursive disk-usage report for every
remote directory. It takes too much time.

> Cheers!

Best regards, Michael.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 3026 bytes --]

*** /tmp/ediffhiunfK	2019-03-03 11:26:50.677462619 +0100
--- /home/albinus/src/elpa/packages/disk-usage/disk-usage.el	2019-03-03 10:59:27.620803344 +0100
***************
*** 263,269 ****
                       (and (file-accessible-directory-p directory)
                            (directory-files-and-attributes
                             directory
!                            'full nil 'nosort)))))
      (or (cl-loop for l in listing
                   for attributes = (cl-rest l)
                   for path = (cl-first l)
--- 263,270 ----
                       (and (file-accessible-directory-p directory)
                            (directory-files-and-attributes
                             directory
!                            'full directory-files-no-dot-files-regexp
! 			   'nosort)))))
      (or (cl-loop for l in listing
                   for attributes = (cl-rest l)
                   for path = (cl-first l)
***************
*** 280,288 ****
                            :name path
                            :size (file-attribute-size attributes))
                   ;; Folders
!                  else if (and (eq t (file-attribute-type attributes))
!                               (not (string= "." (file-name-base path)))
!                               (not (string= ".." (file-name-base path))))
                   collect
                   (disk-usage--file-info-make
                    :name path
--- 281,287 ----
                            :name path
                            :size (file-attribute-size attributes))
                   ;; Folders
!                  else if (eq t (file-attribute-type attributes))
                   collect
                   (disk-usage--file-info-make
                    :name path
***************
*** 305,313 ****
                                          "-type" "d")
                            (buffer-string))
                          "\n" 'omit-nulls)))
!     (cl-loop for dir in subdirs
!              append (cl-loop for file in (directory-files-and-attributes dir 'full nil 'nosort)
!                              for name = (concat (file-remote-p directory) (car file))
                               for attributes = (cdr file)
                               when (and attributes
                                         (not (file-attribute-type attributes))
--- 304,317 ----
                                          "-type" "d")
                            (buffer-string))
                          "\n" 'omit-nulls)))
!     (cl-loop for dir in (mapcar (lambda (item)
! 				  (concat (file-remote-p directory) item))
! 				subdirs)
!              append (cl-loop for file in (directory-files-and-attributes
! 					  dir 'full
! 					  directory-files-no-dot-files-regexp
! 					  'nosort)
!                              for name = (car file)
                               for attributes = (cdr file)
                               when (and attributes
                                         (not (file-attribute-type attributes))