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: Wed, 4 Jul 2007 23:58:56 -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 1183618855 23294 80.91.229.12 (5 Jul 2007 07:00:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 5 Jul 2007 07:00:55 +0000 (UTC) Cc: Rob Giardina , emacs-devel@gnu.org To: , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 05 09:00:53 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 1I6LKb-0002ll-22 for ged-emacs-devel@m.gmane.org; Thu, 05 Jul 2007 09:00:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I6LKa-00072R-Fh for ged-emacs-devel@m.gmane.org; Thu, 05 Jul 2007 03:00:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I6LKW-00071p-UK for emacs-devel@gnu.org; Thu, 05 Jul 2007 03:00:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I6LKW-00071V-HC for emacs-devel@gnu.org; Thu, 05 Jul 2007 03:00:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I6LKW-00071N-1x for emacs-devel@gnu.org; Thu, 05 Jul 2007 03:00:44 -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 1I6LKS-0005TP-24; Thu, 05 Jul 2007 03:00:40 -0400 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l656xF6E011831; Thu, 5 Jul 2007 00:59:15 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l656xEYD026248; Thu, 5 Jul 2007 00:59:14 -0600 Original-Received: from dhcp-amer-whq-csvpn-gw3-141-144-81-61.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3013326341183618747; Wed, 04 Jul 2007 23:59:07 -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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 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:74335 Archived-At: > It seems to work on a short test; however, I do like the long listing > that dired provides, I especially find it important to see permission, > owners, size, and date, as well name. And I hardly ever use frames. > > What does dired-details.el have to do with frames? This was already explained in the thread, but I will repeat it, since you ask. If you use a one-buffer frame for each Dired buffer, and you shrink the buffer horizontally by hiding all info but the file names, then it makes sense to also shrink the frame. Otherwise, you've gained nothing in terms of display real estate. That is the motivation for automatically fitting the frame. Similarly, if you expand the displayed buffer contents, then it makes sense to expand the frame to fit it, so lines don't wrap. The idea is to synchronize the frame display with the buffer display. I was clear from the beginning, however, that I was _not_ proposing that the frame-fitting in dired-details+ be included in Emacs: July 2: > The frame-fitting enhancement need not be applied, since Emacs > does not yet have my frame-fitting code. But I think some of > the other enhancements could be integrated. July 4: > No, not really. As I said, the frame-fitting part is optional... > I use non-nil pop-up-frames, so frame fitting is important to me, > but it is not necessary for the other features provided by > dired-details+.el. You can no doubt imagine that without frame > fitting not much would be gained by removing Dired details: the > frame would occupy just as much screen real estate as for > the detailed listing. There was also a discussion of possibly fitting the Emacs window as well, for those who do not use one buffer per frame. There is currently no code written to do that, but, IMO, it would be a useful addition. Here is that exchange: > > similar to how your frames shrink, Dired could split the window > > and show more when you got space back from hiding details... > > I agree that it could be good to automatically expand and contract > the current Dired window or windows (just as I do with the frame), > provided that a user agrees with that behavior via an option > (somewhere). I have not implemented that - patches welcome ;-). For the record - 1. The frame-fitting call in dired-details+.el has no effect if either (a) user option `autofit-frames-flag' is nil or (b) there is more than one window in the frame. Here is the function called in dired-details+.el, _if_ it is available (soft require, fboundp): (defun fit-frame-if-one-window () "Resize frame to fit selected window if it is alone in the frame. Usable in `temp-buffer-show-hook'. This does nothing if `autofit-frames-flag' is nil." (and (one-window-p t) autofit-frames-flag (fit-frame))) 2. Again, I did _not_, in any case, propose that the dired-details+.el call to `fit-frame-if-one-window' be installed in Emacs, "since Emacs does not yet have my frame-fitting code." FYI - Besides the modal display preference (new Dired buffers use the current display state), which you have rejected, dired-details+ just makes dired-details update the display automatically: 1. By refreshing the current hide/show state whenever the listing of files changes (e.g. new file). Think of this as a kind of refresh or revert. 2. By fitting the frame when the hide/show state changes. I propose adding #1 now. If frame-fitting code is later added to Emacs, then #2 might also be considered at that time.