From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: dired-details: show/hide file details in Dired Date: Tue, 3 Jul 2007 22:51:40 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1183528341 26024 80.91.229.12 (4 Jul 2007 05:52:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 4 Jul 2007 05:52:21 +0000 (UTC) Cc: rob@giardina.us, emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 04 07:52:19 2007 connect(): Connection refused Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1I5xmj-0006Yt-JC for ged-emacs-devel@m.gmane.org; Wed, 04 Jul 2007 07:52:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I5xmi-0005ei-Rl for ged-emacs-devel@m.gmane.org; Wed, 04 Jul 2007 01:52:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I5xme-0005cu-HL for emacs-devel@gnu.org; Wed, 04 Jul 2007 01:52:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I5xmc-0005aY-Da for emacs-devel@gnu.org; Wed, 04 Jul 2007 01:52:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I5xmc-0005aQ-4j for emacs-devel@gnu.org; Wed, 04 Jul 2007 01:52:10 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1I5xma-0004yB-3Z; Wed, 04 Jul 2007 01:52:08 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l645q2S1014035; Tue, 3 Jul 2007 23:52:02 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l6441cxi001895; Tue, 3 Jul 2007 23:52:01 -0600 Original-Received: from dhcp-amer-whq-csvpn-gw3-141-144-80-71.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 3011369671183528307; Tue, 03 Jul 2007 22:51:47 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:74272 Archived-At: > How about also installing the enhancements provided by > dired-details+.el? > > Once dired-details.el is installed, please post a copy > and we can think about which of its features we want to install. I already posted a copy, here: http://www.emacswiki.org/cgi-bin/wiki/dired-details%2b.el. > 1. Update the hide/show overlays automatically whenever you > create new files or directories or rename existing files > or directories. This means tweaking the definitions of > `dired-byte-compile', `dired-compress', > `dired-create-files' and `dired-create-directory' (instead > of advising them). > > That sounds useful. What precisely are the "hide/show overlays", though? > Which feature uses them? Is that something in dired-details? Yes. dired-details uses "an invisible, evaporable overlay for each file-line's details", to quote the doc string of `dired-details-hide'. AFAICT, this dired-details+ feature corresponds to the only TODO item in dired-details: "add a hook for dired-add-file to hide new entries as necessary". Without this feature, any of the changes mentioned (e.g. adding a file) results in a full, detailed display of the target file, instead of keeping its display in sync with the rest of the Dired buffer (details hidden or shown). The dired-details+ code (like the dired-details code) uses defadvice. If this display-sync feature is added to Emacs, then the following code or equivalent would need to be added at the end of each of the functions mentioned, to be able to get rid of the defadvice that implements this feature: (dired-details-delete-overlays) (dired-details-activate) Suitably guarded by `fboundp' or `featurep', perhaps, so that it is used only with dired-details. All this code does is update the buffer display, to synchronize it for the target files. > 2. Provide a user option, `dired-details-propagate-flag' > which, if non-nil, propagates the last hide/show state > you chose to the next Dired buffer you open. > > I would rather not install that. In that case, then that should be the only behavior, IMO, not what is defined in dired-details.el. That is, if you don't want to have a user option for this, then IMO the behavior should be to let the hide/show toggling affect future Dired buffers, instead of them all defaulting to the same initial state. The toggle is still local, so display of existing Dired buffers is not affected, but if you open Dired on other directories (e.g. subdirs or parent dirs), then the current display state (hidden or shown) is used (instead of some default state). In my use, at least, this makes more sense, because it requires a lot less toggling. Typically, if I currently want to hide (show) details in some Dired buffer, then I probably want to do the same in the next Dired buffer I open. It is not the case that I always want to start every Dired buffer in the same default state. Without this modal behavior, you need to toggle more often or you need to periodically re-customize the default state. The user's current display state is a better guide to how s?he wants the next Dired buffer to be displayed than is some default value. I also recommend that the empty string (instead of "[...]") be used as the default value of the hidden string (used for the overlay). For one thing, it saves screen real estate. For another thing, it makes window and frame fitting easier and more accurate. For another thing, someone who uses dired-details will not need a "[...]" reminder that there is hidden text present - that's pretty useless, IMO. If you are keen on not multiplying user options, then I'd say just hard-code this as the empty string. That sums up the tweaks that dired-details+ makes to dired-details. There are only a few dozen lines of code in the file.