From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.help Subject: RE: non noisy dired Date: Fri, 5 Jun 2009 08:25:16 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1244215586 16062 80.91.229.12 (5 Jun 2009 15:26:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Jun 2009 15:26:26 +0000 (UTC) To: "'rustom'" , Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jun 05 17:26:22 2009 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MCbJA-0008Lo-C1 for geh-help-gnu-emacs@m.gmane.org; Fri, 05 Jun 2009 17:26:16 +0200 Original-Received: from localhost ([127.0.0.1]:48975 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MCbJ9-000630-Mf for geh-help-gnu-emacs@m.gmane.org; Fri, 05 Jun 2009 11:26:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MCbIT-0005tI-8k for help-gnu-emacs@gnu.org; Fri, 05 Jun 2009 11:25:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MCbIO-0005qx-PT for help-gnu-emacs@gnu.org; Fri, 05 Jun 2009 11:25:32 -0400 Original-Received: from [199.232.76.173] (port=44473 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MCbIO-0005qs-45 for help-gnu-emacs@gnu.org; Fri, 05 Jun 2009 11:25:28 -0400 Original-Received: from acsinet12.oracle.com ([141.146.126.234]:50586) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MCbIN-0007iv-LA for help-gnu-emacs@gnu.org; Fri, 05 Jun 2009 11:25:27 -0400 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n55FO2MZ001432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Jun 2009 15:24:03 GMT Original-Received: from abhmt004.oracle.com (abhmt004.oracle.com [141.146.116.13]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n55FPPrf024555; Fri, 5 Jun 2009 15:25:26 GMT Original-Received: from dradamslap1 (/141.144.72.122) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Jun 2009 08:25:20 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acnl41rFZKx9006nR5eZQFm5RFZISwAByQ9Q X-Source-IP: abhmt004.oracle.com [141.146.116.13] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010206.4A2938E1.0173:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:64970 Archived-At: > > http://www.emacswiki.org/emacs/DiredDetails > > You'll never have to see anything other than the file name, > > unless you want to, and you can do that by hitting a toggle key. > > Drew: > autofit seems to need fit --did that (need to put that in the wiki > mention) After that emacs does resizing of windows in a way that is > disconcerting (to me :-) -- it made a small file into a window the > size of a matchbox! > But I guess I should be able to use it without fit -- need to try more > thoroughly Hi Rustom, I guess you're referring to `dired-details+.el', not just `dired-details.el' (which does not fit frames). In any case, this has nothing per se to do with the display or hiding of some Dired columns. I take it as a side issue. The issue is that `dired-details+.el' loads `autofit-frame.el', if you have that library in your `load-path'. Notice the "if", here - this is a user choice. If you choose to automatically fit single-window Dired frames, then, well, that's what you get. ;-) If you do want to load `autofit-frame.el', but you want to turn off frame-fitting in some particular context, you can bind or set `fit-frame-inhibit-fitting-flag' to t in that context. If you set or customize it to t at the top level, then frame-fitting will never take place. Finally, if you want to be able to manually fit frames (`M-x fit-frame'), but you want to inhibit automatic frame-fitting of one-window frames, then customize `autofit-frames-flag' to nil. So you have several ways to inhibit frame-fitting. As to the particular frame-fitting behavior you describe - If you are getting a matchbox size frame, then there are no doubt very few files and subdirectories in the Dired listing; that is, the buffer to be displayed is small, and with short lines. If that is not the case, then please report a fit-frame bug - send me a mail. You have control over the min and max size for frames that are fit. See the options available in library `fit-frame.el' (loaded by `autofit-frame.el'), including these: fit-frame-min-width fit-frame-min-height fit-frame-max-width fit-frame-max-width-percent fit-frame-max-height fit-frame-max-height-percent fit-frame-empty-width fit-frame-empty-height fit-frame-empty-special-display-width fit-frame-empty-special-display-height So if a matchbox size frame is large enough to show the entire buffer with no line wrapping, but you nevertheless want the frame to be bigger and include some more blank space, then just increase the minimum frame size. Resizing a frame so that it fits its displayed buffer (e.g. Dired, with no file details showing) changes the frame width to accommodate the longest line without wrapping it. You typically do not want to count the length of header lines in this calculation, however - in particular, for Info and Dired. It is normally the width of the Dired files and subdirs that you care about; it's better to let the header line wrap, and so to conserve screen space by fitting the frame to the longest file/subdir line, ignoring the header line length. But if you like, you can control this header-skipping (whether it is skipped, and how many lines are skipped) on a per-mode basis, using option `fit-frame-skip-header-lines-alist'. Wrapping header lines adds to the vertical space required, of course. The number of times a given line is wrapped is taken into account in calculating the needed frame height (pertinent only if the buffer has few enough lines that all can be displayed at once). Frame-fitting also takes into account the number of menu-bar and tool-bar lines your frame has (as indicated by those frame parameters), when it calculates the needed frame height. However, if the frame is fit to be narrower than the menu-bar or tool-bar, there is no way to obtain this info. That is, the code cannot know whether a menu-bar gets wrapped or how many times it does. The code just assumes that the menu-bar is wrapped, on average, once. If at some time the menu-bar is not wrapped at all (but it is showing), and you have few enough lines in the buffer to show all of them, then the frame will be one line taller than it really needs to be. If the menu-bar wraps more than once, then the frame will be slightly shorter than it really needs to be. In sum: 1. Frame-fitting does some calculation and uses some heuristics to do the best it can. (It tries, BTW, to adjust to different Emacs releases, which handle things such as the menu-bar and tool-bar very differently.) 2. You can control how it does this - consult the options in library `fit-frame.el'. You can also inhibit frame-fitting, either generally or in particular contexts. 3. Again, this has nothing per se to do with hiding Dired details. Automatically frame-fitting one-window Dired buffers whenever you toggle hiding/showing the file details is a feature of `dired-details+.el', not of vanilla `dired-details.el'. HTH. Please send a bug report if you encounter some behavior you think is incorrect.