all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* [ELPA] New package: dired-du
@ 2017-05-26 13:02 Tino Calancha
  2017-05-26 13:45 ` Clément Pit-Claudel
  2017-05-26 17:04 ` Yuri Khan
  0 siblings, 2 replies; 11+ messages in thread
From: Tino Calancha @ 2017-05-26 13:02 UTC (permalink / raw)
  To: Emacs developers


New library implementing a Dired interface for `du'.

I)
This library defines a minor mode `dired-du-mode' to display
the recursive size of directories in Dired buffers.  This mode
uses the external `du' program when available.  Otherwise, it
performs a rough estimation with Lisp.

II)
In addition, this file provides a command `dired-du-count-sizes',
to show the total size of the marked files.  By default, it shows
the size of the files marked with `dired-marker-char'.   If `dired-du-mode'
is disabled, then ignores the size of directories.  Otherwise, it takes
in account the size of the dirs.
When called with a prefix prompts for the marks and asks if the dirs must
be taken in account.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
The idea of this library arose after bugs 22829 and 22892.

Some people have shown interest on this feature elsewhere:
https://emacs.stackexchange.com/questions/20766/display-recursive-folder-sizes-in-line-in-dired
https://superuser.com/questions/462079/how-can-i-display-folder-sizes-in-emacs-dired

The file is available for inspection in the following Elpa repo. branch:
scratch/dired-du



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [ELPA] New package: dired-du
  2017-05-26 13:02 [ELPA] New package: dired-du Tino Calancha
@ 2017-05-26 13:45 ` Clément Pit-Claudel
  2017-05-26 14:57   ` Tino Calancha
  2017-05-26 17:04 ` Yuri Khan
  1 sibling, 1 reply; 11+ messages in thread
From: Clément Pit-Claudel @ 2017-05-26 13:45 UTC (permalink / raw)
  To: emacs-devel

On 2017-05-26 09:02, Tino Calancha wrote:
> New library implementing a Dired interface for `du'.

This is nice, but why isn't this directly in dired? I don't think we should assume that Emacs is feature-frozen and evolve it only through new packages.  Otherwise we risk fragmentation, and we contribute to the general feeling that Emacs isn't optimally usable right out of the box.

(I had the same comments about your other recent library, kmb; these are generally useful features: they should go into the base distribution, or at least be discussed).

Cheers,
Clément.

> I)
> This library defines a minor mode `dired-du-mode' to display
> the recursive size of directories in Dired buffers.  This mode
> uses the external `du' program when available.  Otherwise, it
> performs a rough estimation with Lisp.
> 
> II)
> In addition, this file provides a command `dired-du-count-sizes',
> to show the total size of the marked files.  By default, it shows
> the size of the files marked with `dired-marker-char'.   If `dired-du-mode'
> is disabled, then ignores the size of directories.  Otherwise, it takes
> in account the size of the dirs.
> When called with a prefix prompts for the marks and asks if the dirs must
> be taken in account.
> 
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> The idea of this library arose after bugs 22829 and 22892.
> 
> Some people have shown interest on this feature elsewhere:
> https://emacs.stackexchange.com/questions/20766/display-recursive-folder-sizes-in-line-in-dired
> https://superuser.com/questions/462079/how-can-i-display-folder-sizes-in-emacs-dired
> 
> The file is available for inspection in the following Elpa repo. branch:
> scratch/dired-du
> 
> 




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [ELPA] New package: dired-du
  2017-05-26 13:45 ` Clément Pit-Claudel
@ 2017-05-26 14:57   ` Tino Calancha
  0 siblings, 0 replies; 11+ messages in thread
From: Tino Calancha @ 2017-05-26 14:57 UTC (permalink / raw)
  To: Clément Pit-Claudel; +Cc: Emacs developers

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



On Fri, 26 May 2017, Clément Pit-Claudel wrote:

> On 2017-05-26 09:02, Tino Calancha wrote:
>> New library implementing a Dired interface for `du'.
>
> This is nice, but why isn't this directly in dired? I don't think we should assume that Emacs is feature-frozen and evolve it only through new packages.  Otherwise we risk fragmentation, and we contribute to the general feeling that Emacs isn't optimally usable right out of the box.
I agree that it might be handy to have this feature into Emacs core.

Cheers,
Tino

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [ELPA] New package: dired-du
  2017-05-26 13:02 [ELPA] New package: dired-du Tino Calancha
  2017-05-26 13:45 ` Clément Pit-Claudel
@ 2017-05-26 17:04 ` Yuri Khan
  2017-05-26 17:53   ` Eli Zaretskii
                     ` (2 more replies)
  1 sibling, 3 replies; 11+ messages in thread
From: Yuri Khan @ 2017-05-26 17:04 UTC (permalink / raw)
  To: Tino Calancha; +Cc: Emacs developers

On Fri, May 26, 2017 at 8:02 PM, Tino Calancha <tino.calancha@gmail.com> wrote:

> New library implementing a Dired interface for `du'.

That sounds great.

> I)
> This library defines a minor mode `dired-du-mode' to display
> the recursive size of directories in Dired buffers.  This mode
> uses the external `du' program when available.  Otherwise, it
> performs a rough estimation with Lisp.

Would it be useful to extract the Lisp replacement of du as a separate
library, or does that raise too many questions about cache management?

> II)
> In addition, this file provides a command `dired-du-count-sizes',
> to show the total size of the marked files.  By default, it shows
> the size of the files marked with `dired-marker-char'.   If `dired-du-mode'
> is disabled, then ignores the size of directories.  Otherwise, it takes
> in account the size of the dirs.
> When called with a prefix prompts for the marks and asks if the dirs must
> be taken in account.
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> The file is available for inspection in the following Elpa repo. branch:
> scratch/dired-du

You are caching directory information in a buffer-local variable
‘dired-du-dir-info’. A single Dired buffer can show multiple
directories, and it can be killed and re-opened. Wouldn’t it make
sense to share the cache across all Dired buffers and persist it
independently of buffer lifetimes?

From experience with other file managers implementing directory size
calculation, it is useful to have a command that recalculates the
sizes of marked subdirectories, or the subdirectory at point, if none
are marked. (Their cached size should be discarded and replaced with
the newly calculated one.)

Also, you are defining many functions that are copies of dired’s but
with added functionality. Would it be better to improve dired’s
functions instead?



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [ELPA] New package: dired-du
  2017-05-26 17:04 ` Yuri Khan
@ 2017-05-26 17:53   ` Eli Zaretskii
  2017-05-26 18:12     ` Yuri Khan
  2017-05-27 10:06   ` Tino Calancha
  2017-05-29 14:41   ` Filipp Gunbin
  2 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2017-05-26 17:53 UTC (permalink / raw)
  To: Yuri Khan; +Cc: emacs-devel, tino.calancha

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sat, 27 May 2017 00:04:34 +0700
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > I)
> > This library defines a minor mode `dired-du-mode' to display
> > the recursive size of directories in Dired buffers.  This mode
> > uses the external `du' program when available.  Otherwise, it
> > performs a rough estimation with Lisp.
> 
> Would it be useful to extract the Lisp replacement of du as a separate
> library, or does that raise too many questions about cache management?

Why not use get-free-disk-space, which would make the library much
more portable?



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [ELPA] New package: dired-du
  2017-05-26 17:53   ` Eli Zaretskii
@ 2017-05-26 18:12     ` Yuri Khan
  2017-05-26 19:03       ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Yuri Khan @ 2017-05-26 18:12 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Emacs developers, Tino Calancha

On Sat, May 27, 2017 at 12:53 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Would it be useful to extract the Lisp replacement of du as a separate
>> library, or does that raise too many questions about cache management?
>
> Why not use get-free-disk-space, which would make the library much
> more portable?

How does get-free-disk-space help calculate disk space usage by a
directory? (Short of measuring the free space before and after
deleting said directory.)



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [ELPA] New package: dired-du
  2017-05-26 18:12     ` Yuri Khan
@ 2017-05-26 19:03       ` Eli Zaretskii
  0 siblings, 0 replies; 11+ messages in thread
From: Eli Zaretskii @ 2017-05-26 19:03 UTC (permalink / raw)
  To: Yuri Khan; +Cc: emacs-devel, tino.calancha

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sat, 27 May 2017 01:12:07 +0700
> Cc: Tino Calancha <tino.calancha@gmail.com>, Emacs developers <emacs-devel@gnu.org>
> 
> On Sat, May 27, 2017 at 12:53 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Would it be useful to extract the Lisp replacement of du as a separate
> >> library, or does that raise too many questions about cache management?
> >
> > Why not use get-free-disk-space, which would make the library much
> > more portable?
> 
> How does get-free-disk-space help calculate disk space usage by a
> directory?

It doesn't for that job, but one could use directory-files-recursively
and file-attributes.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [ELPA] New package: dired-du
  2017-05-26 17:04 ` Yuri Khan
  2017-05-26 17:53   ` Eli Zaretskii
@ 2017-05-27 10:06   ` Tino Calancha
  2017-05-27 10:59     ` Yuri Khan
  2017-05-29 14:41   ` Filipp Gunbin
  2 siblings, 1 reply; 11+ messages in thread
From: Tino Calancha @ 2017-05-27 10:06 UTC (permalink / raw)
  To: Yuri Khan; +Cc: Emacs developers, Tino Calancha

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



On Sat, 27 May 2017, Yuri Khan wrote:

> On Fri, May 26, 2017 at 8:02 PM, Tino Calancha <tino.calancha@gmail.com> wrote:
>
>> New library implementing a Dired interface for `du'.
>
> That sounds great.
>
>> I)
>> This library defines a minor mode `dired-du-mode' to display
>> the recursive size of directories in Dired buffers.  This mode
>> uses the external `du' program when available.  Otherwise, it
>> performs a rough estimation with Lisp.
>
> Would it be useful to extract the Lisp replacement of du as a separate
> library, or does that raise too many questions about cache management?
That part is expected to be very slow.  I just added recently as a 
fallback, but it is not the recomended way.  Actually I show one 
warning encouraging the user to install `du'.
>
>> II)
>> In addition, this file provides a command `dired-du-count-sizes',
>> to show the total size of the marked files.  By default, it shows
>> the size of the files marked with `dired-marker-char'.   If `dired-du-mode'
>> is disabled, then ignores the size of directories.  Otherwise, it takes
>> in account the size of the dirs.
>> When called with a prefix prompts for the marks and asks if the dirs must
>> be taken in account.
>>
>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>> The file is available for inspection in the following Elpa repo. branch:
>> scratch/dired-du
>
> You are caching directory information in a buffer-local variable
> ‘dired-du-dir-info’. A single Dired buffer can show multiple
> directories, and it can be killed and re-opened. Wouldn’t it make
> sense to share the cache across all Dired buffers and persist it
> independently of buffer lifetimes?
I don't know.  I decided the implementation according with my 
use case:
i just wanted to see the actual size of my dirs in human readable units. 
For this naive purpose the buffer locallity of `dired-du-dir-info' is 
fine.
Once other people start using the lib we might find convenient to change
those particular aspects of the implementation.

> From experience with other file managers implementing directory size
> calculation, it is useful to have a command that recalculates the
> sizes of marked subdirectories, or the subdirectory at point, if none
> are marked. (Their cached size should be discarded and replaced with
> the newly calculated one.)
Good idea.  I just added the command `dired-du-update-dir-info' for
that operation.
Thank you.
>
> Also, you are defining many functions that are copies of dired’s but
> with added functionality. Would it be better to improve dired’s
> functions instead?
Of course it would.
If the lib is ported to master branch, some parts of the lib will be 
absorbed by dired.el, dired-aux.el, dired-x.el, and the file will be
much shorter.
On the other hand, one of the nice things about Elpa is that you can 
support older Emacs.  This file works for Emacs >= 24.4.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [ELPA] New package: dired-du
  2017-05-27 10:06   ` Tino Calancha
@ 2017-05-27 10:59     ` Yuri Khan
  2017-05-29  1:37       ` Tino Calancha
  0 siblings, 1 reply; 11+ messages in thread
From: Yuri Khan @ 2017-05-27 10:59 UTC (permalink / raw)
  To: Tino Calancha; +Cc: Emacs developers

On Sat, May 27, 2017 at 5:06 PM, Tino Calancha <tino.calancha@gmail.com> wrote:

>> Would it be useful to extract the Lisp replacement of du as a separate
>> library, or does that raise too many questions about cache management?
>
> That part is expected to be very slow.  I just added recently as a fallback,
> but it is not the recomended way.  Actually I show one warning encouraging
> the user to install `du'.

That’s why I’m suggesting extracting it: so that the casual user
reading the code does not spend time in the fallback; or,
alternatively, focuses on it specifically.

>> Wouldn’t it make sense to share the cache across all Dired buffers
>> and persist it independently of buffer lifetimes?
>
> I don't know.  I decided the implementation according with my use case:
> i just wanted to see the actual size of my dirs in human readable units. For
> this naive purpose the buffer locallity of `dired-du-dir-info' is fine.
> Once other people start using the lib we might find convenient to change
> those particular aspects of the implementation.

Okay.

I wonder… will it work over Tramp/ssh?



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [ELPA] New package: dired-du
  2017-05-27 10:59     ` Yuri Khan
@ 2017-05-29  1:37       ` Tino Calancha
  0 siblings, 0 replies; 11+ messages in thread
From: Tino Calancha @ 2017-05-29  1:37 UTC (permalink / raw)
  To: Yuri Khan; +Cc: Emacs developers, Tino Calancha

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



On Sat, 27 May 2017, Yuri Khan wrote:

>>> Wouldn’t it make sense to share the cache across all Dired buffers
>>> and persist it independently of buffer lifetimes?
>>
>> I don't know.  I decided the implementation according with my use case:
>> i just wanted to see the actual size of my dirs in human readable units. For
>> this naive purpose the buffer locallity of `dired-du-dir-info' is fine.
>> Once other people start using the lib we might find convenient to change
>> those particular aspects of the implementation.
>
> Okay.
>
> I wonder… will it work over Tramp/ssh?
It hasn't being heavily tested, but it works for the only machine that
i can access remotely with Tramp.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [ELPA] New package: dired-du
  2017-05-26 17:04 ` Yuri Khan
  2017-05-26 17:53   ` Eli Zaretskii
  2017-05-27 10:06   ` Tino Calancha
@ 2017-05-29 14:41   ` Filipp Gunbin
  2 siblings, 0 replies; 11+ messages in thread
From: Filipp Gunbin @ 2017-05-29 14:41 UTC (permalink / raw)
  To: Yuri Khan; +Cc: Emacs developers, Tino Calancha

On 27/05/2017 00:04 +0700, Yuri Khan wrote:

> You are caching directory information in a buffer-local variable
> ‘dired-du-dir-info’. A single Dired buffer can show multiple
> directories, and it can be killed and re-opened. Wouldn’t it make
> sense to share the cache across all Dired buffers and persist it
> independently of buffer lifetimes?

But it may be convenient to know that to recalculate everything from
scratch you just kill & reopen dired buffer and don't mingle with some
caches somewhere..

Filipp




^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2017-05-29 14:41 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-05-26 13:02 [ELPA] New package: dired-du Tino Calancha
2017-05-26 13:45 ` Clément Pit-Claudel
2017-05-26 14:57   ` Tino Calancha
2017-05-26 17:04 ` Yuri Khan
2017-05-26 17:53   ` Eli Zaretskii
2017-05-26 18:12     ` Yuri Khan
2017-05-26 19:03       ` Eli Zaretskii
2017-05-27 10:06   ` Tino Calancha
2017-05-27 10:59     ` Yuri Khan
2017-05-29  1:37       ` Tino Calancha
2017-05-29 14:41   ` Filipp Gunbin

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.