From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Tino Calancha Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: dired-du Date: Sat, 27 May 2017 19:06:21 +0900 (JST) Message-ID: References: <8737brwz2a.fsf@calancha-pc> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1128609307-1495879584=:14415" X-Trace: blaine.gmane.org 1495879598 12161 195.159.176.226 (27 May 2017 10:06:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 27 May 2017 10:06:38 +0000 (UTC) User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Cc: Emacs developers , Tino Calancha To: Yuri Khan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 27 12:06:34 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dEYcD-00033D-T6 for ged-emacs-devel@m.gmane.org; Sat, 27 May 2017 12:06:34 +0200 Original-Received: from localhost ([::1]:40115 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dEYcJ-0006D5-49 for ged-emacs-devel@m.gmane.org; Sat, 27 May 2017 06:06:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dEYcD-0006D0-Bz for emacs-devel@gnu.org; Sat, 27 May 2017 06:06:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dEYcA-0000Ji-6Z for emacs-devel@gnu.org; Sat, 27 May 2017 06:06:33 -0400 Original-Received: from mail-pf0-x22e.google.com ([2607:f8b0:400e:c00::22e]:35003) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dEYc8-0000JP-99 for emacs-devel@gnu.org; Sat, 27 May 2017 06:06:30 -0400 Original-Received: by mail-pf0-x22e.google.com with SMTP id n23so27805802pfb.2 for ; Sat, 27 May 2017 03:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=IficHM4Afa8i6yCAD1R2tWhF0tpU/LdXrR7WTGc27m0=; b=X2FgukX1MymEn2/xXZm/4KbElwBEqv2iqUvKOXoRsknJHsoXJ973KCF80FInhqrr/a 9NDEvBr4GUvl9A8x94S9j1d8Kgzb+HWoTCu/Sy+lGuLUsr4m5NzJgMJfaZPOuHsDeAW7 4KX4abHbG3cqyi8vy5t3u9LZWtxKj7wq8UN/6Fvdc87OHjTQafGnMoxyfp204qU7HNnV EPPy6FckPZXwEvB1N+u+6uNwVTELw12PBxghg+zqpoWMu3FhxKHAAV5qqt+UbKK2lmaw rVVnnC8BPYXyK/uqCbJlRSubOTCQ9pWuGmd3Kyi7QF5nWQxYUzlKpC6H7dYSATfprLRs gidA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=IficHM4Afa8i6yCAD1R2tWhF0tpU/LdXrR7WTGc27m0=; b=PTPdOmPo/14kTWi4Ix0gzF+Gdpin33trJU1cTqGIWHOZp1f7U7bPFz5r80qVEvrEI7 UQAO79NBe55WJGaLW3fw6zNZ8letXig+dj0nmoHXhhiVS35Irw7a7bReHWhg1qfv6RUu GcIOs7rv1Vc2x4SAghhiuFl6Jt8Y4h5vs71Xo0KZins3SKc46MwVZz6eBpLWl/+P1zEz 4Ij1YQigOh0355LYZZC+jDPryEEJKFOy45AnFy3HUWSohRSF7fxEzIAhEOvOL0QVHF/K 8TmrwhS7AMs1lY2vufHzfQsB8I60d6rlqmbMEz7Y3/XtlRhNHLwL48kXNYCYL3/vVCkz tLWw== X-Gm-Message-State: AODbwcCKKnmQR6Pzq2z9HKg1OPGsmPsXAnUq+Bj717b1XC5p88wWuERb L4CLKOVkuQP28w== X-Received: by 10.98.152.71 with SMTP id q68mr7267646pfd.25.1495879585939; Sat, 27 May 2017 03:06:25 -0700 (PDT) Original-Received: from calancha-pc (222.139.137.133.dy.bbexcite.jp. [133.137.139.222]) by smtp.gmail.com with ESMTPSA id l198sm7138946pga.50.2017.05.27.03.06.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 May 2017 03:06:24 -0700 (PDT) X-Google-Original-From: Tino Calancha X-X-Sender: calancha@calancha-pc In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400e:c00::22e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:215260 Archived-At: --8323329-1128609307-1495879584=:14415 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 27 May 2017, Yuri Khan wrote: > On Fri, May 26, 2017 at 8:02 PM, Tino Calancha 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. --8323329-1128609307-1495879584=:14415--