From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: rob@giardina.us, joakim@verona.se,
'Emacs Development' <emacs-devel@gnu.org>
Subject: RE: dired-details[+].el
Date: Wed, 16 May 2012 09:10:40 -0700 [thread overview]
Message-ID: <DA2548DB224B451A984377771B39F664@us.oracle.com> (raw)
In-Reply-To: <jwvsjf0gq97.fsf-monnier+emacs@gnu.org>
Thanks for looking into this again, Stefan.
> A technical reason is lack of copyright paperwork. I'm not
> sure if the email I used in the Cc is valid. If so, Rob,
> could you contact me to get this copyright business out of the way?
Hopefully Rob will answer, but I'm pretty sure he already took care of the
copyright stuff. The most recent reply we have from Rob is from this address:
rob.giardina@gmail.com.
This is that reply:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6799#23. Note too that he included
the latest patches in that message.
> > Rob's change log and RMS's call for comment:
> > http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg01187.html
>
> This was mangled by the non-MIME forwarding, but I think I managed to
> unmangle it (see after my sig). Some of the hunks don't
> apply any more, but they're trivial to fix. There are a few minor
> details to make before we can install the code:
Please check also the patches in his message a few weeks ago (see above), just
in case there is some difference that might be important.
> > + (define-key map "(" 'dired-details-hide)
> > + (define-key map ")" 'dired-details-show)
> > + (define-key map ";" 'dired-details-toggle)
>
> I'd rather place the bindings on a "dired-details" prefix.
FWIW, I think we need only one keybinding, for just `dired-details-toggle'.
It's good to have the other commands too, but I'm not sure they need key
bindings. Just one opinion. Personally, I use only the toggle, and I bind it
to `)' - and also to `(', for the heck of it. I never use the other two
commands, but users are different.
So in particular I see no need for a prefix key - a single keystroke should be
sufficient for everything that one wants to do with `dired-details'.
Note that the toggle (at least as I defined it, and I think Rob's patches kept
this behavior) affects future Dired buffers - IOW the new setting persists after
toggling in the current Dired buffer, so that it is used thereafter
(everywhere).
> > +(defcustom dired-details-hide-link-targets t
> > + "*Hide symbolic link target paths."
> > + :group 'dired-details
> > + :type 'boolean)
>
> FWIW I find something like (setq truncate-lines t) to be better.
Not the same thing. And not better, IMO - less specific. Hiding symlink
targets should apply regardless of line length. Truncating is only about
handling long lines. (But I don't really care about this matter.)
> Since line truncation is the default in tabulated-list-mode, maybe we
> should also make it the default in dired.
Egads, no, please.
No, I won't fight over the default value, but I think truncated lines as the
default is nearly always a bad idea. An extra reason is that some users will
have no clue what's going on and how to show the missing info.
Truncating lines is nearly a barbarism that should go the way of the dinosaurs.
No, just kidding. It can be handy if you know how to toggle it, but truncation
should not be the default (anywhere), IMHO.
Again though, not very important.
> > +(defun dired-details-toggle (&optional arg default-too)
> > + "Toggle visibility of dired details.
> > +With positive prefix argument ARG hide the details, with negative
> > +show them."
> > + (interactive "P")
> > + (let ((hide (if (null arg)
> > + (not (eq 'hidden dired-details-state))
> > + (> (prefix-numeric-value arg) 0))))
> > + (if default-too
> > + (setq dired-details-initially-hide hide))
> > + (if hide (dired-details-hide)
> > + (dired-details-show))))
>
> Use define-minor-mode.
I think I disagree, and I feel more strongly about this point. The current
behavior is what I like, and I'm not sure how using a minor mode would provide
it. This is the behavior:
Toggling affects only the current Dired buffer and subsequently
created Dired buffers. It does not affect other existing Dired buffers.
A local minor mode would affect only the current Dired buffer and not
subsequently created ones. A global minor mode would affect all Dired buffers
at the same time.
The current toggle is very handy. Toggling twice, just to show something for a
moment for example, does not show everything in all Dired buffers (as would a
global minor mode). It has an effect only on the current buffer (since you did
it twice).
And the fact that toggling sets the "mode" for all new Dired buffers is very
handy, though it's hard for me to do justice as to why. Just try it for a
while, to see. Drill down the directory hierarchy, for instance. But again, I
can't really characterize the value using a particular example - just try it.
I really suggest (ask that) you play with the existing feature a while, before
suggesting behavior changes.
> > +(defun dired-details-hide-overlay (o)
> > + (overlay-put o 'invisible t)
> > + (overlay-put o 'before-string dired-details-hidden-string))
>
> Why use dired-details-hidden-string rather than just using the
> traditional ellipsis with buffer-invisibility-spec?
The first thing I did when getting dired-details.el was change the string to "",
and I've never looked back. In my use of it, hiding the details means showing
nothing in their place. And in the commentary of dired-details+.el I
recommended that others do the same.
FWIW, This is important to me. When I hide details I get a _minimal_ Dired
display. And I automatically fit its frame to the content, so the frame takes
up a minimum of screen real estate. It's thus almost like a speedbar (narrow),
but the buffer still has the full functionality of Dired.
HTH.
prev parent reply other threads:[~2012-05-16 16:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-19 9:55 dired-details[+].el joakim
2009-07-19 14:34 ` dired-details[+].el Drew Adams
2012-05-16 15:24 ` dired-details[+].el Stefan Monnier
2012-05-16 16:10 ` Drew Adams [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DA2548DB224B451A984377771B39F664@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=joakim@verona.se \
--cc=monnier@iro.umontreal.ca \
--cc=rob@giardina.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).