From: "Drew Adams" <drew.adams@oracle.com>
To: "'Juri Linkov'" <juri@jurta.org>
Cc: emacs-devel@gnu.org
Subject: RE: patch for Dired second header line info
Date: Sun, 2 Mar 2008 08:27:36 -0800 [thread overview]
Message-ID: <002801c87c82$539474d0$0600a8c0@us.oracle.com> (raw)
In-Reply-To: <87y791mess.fsf@jurta.org>
> >> Are you sure this change will not break other packages that
> >> rely on the first word `total' at the beginning of a dired
> >> buffer?
> >
> > How could I (or anyone) be sure of that? Who knows what
> > some package might rely on?
>
> Using one of several code search engines, for instance,
> http://www.krugle.org/kse/files?query=%22total+used%22&lang=elisp
> you can find a few packages that rely on the format of this string,
> including your ls-lisp+.el
> http://www.emacswiki.org/cgi-bin/wiki/ls-lisp%2B.el.
1. It was a rhetorical question.
The right way is to use a function or variable, and external packages can
then adapt. Avoiding hard-coding would also facilitate translation and other
transformations. If there are libraries today that depend on "total" at the
beginning of the line, it is because they have no choice.
2. My package ls-lisp+.el is 1/2 of the patch I sent. The other half is in
files+.el.
IOW, ls-lisp+.el is not an example of an existing package that will be
broken by my patch - it _is_ my patch. (These libraries let users of older
Emacs users also have the new feature.)
> >> Also I think instead of displaying the number of files listed
> >> in the current dired buffer, more useful would be to display
> >> the total number of files in the current directory. There are
> >> features that hide files in the dired buffer (e.g.
> >> dired-omit-mode), so displaying the total number of
> >> files will be helpful for users to see that there are more
> >> hidden files.
> >
> > I disagree - it's a feature, not a bug, to see how many
> > files are currently visible.
> >
> > For example, if I use Dired with wildcards, I want to see
> > how many matching files there are. If I hide the files with
> > extension `elc', I want to see how many files are left.
> > And so on. The figure should reflect the current
> > display state.
>
> Sorry, it didn't appear to me that the number of listed files would be
> useful too. But we can display both numbers on the same line
> using the traditional notation "listed/total", e.g.
>
> total used in directory 49439 available 56233408 files 691/1000
Good idea. Go for it. And perhaps that will obviate the need for `files
listed' instead of `files'.
I still prefer the order I suggested, and shortening and clarifying `total
used in directory' to `space used' or `kbytes used'.
> > BTW, I did not check until now, but that is also apparently
> > the approach Windows Explorer uses (FWIW). If you hide system
> > files, for instance, the file count excludes them.
>
> BTW, such file managers also display the number and total
> size of selected files.
Yes. I agree that `files 691/1000' is preferable.
BTW, if the meanings of `space used' and `available' were comparable, we
could do the same thing there. But one is presumably the space used in the
directory, and the other is presumably the space available on the disk, so
two labels are needed in that case.
> I have a function `dired-count-marked-files' that
> does the same and displays this information in the echo area
> after marking a file.
>
> Maybe instead of the echo area and instead of the header line
> beginning with `total' we could display this information in the
> mode line?
That was in fact the starting point for my patch: a help-gnu-emacs question
was answered by a post from Kevin Rodgers that used the mode line that way.
I specifically want to avoid putting such stuff in the mode line -
especially in the minor-mode lighter list. The lighter list has a specific
meaning that should not be muddied, and the list is already busy enough. I
typically have 3 or 4 minor modes active at the same time.
It's true that we already do that kind of thing in some modes (e.g. `grep'),
but I think it's bad practice in general and should not be expanded. And
this file/space info is not as important as the info we put in the `grep'
lighter. A temporary indication of something can sometimes be appropriate in
a lighter area, but we shouldn't turn lighters into essays or status lines.
Would you also add the space used/available to the Dired lighter? And would
you list the used/available figures for every inserted subdir in the mode
line? This is a bad idea, IMO.
So no, I disagree that the mode line is a good place to put this info.
> There is a special mode-line symbol %i and %I (`size-indication-mode')
> that is not very useful in dired mode. We could use it (or
> create a new %-construct) to display the total number of selected/all
> files and their sizes in the mode line in more concise format.
I vote against it. Just one vote.
next prev parent reply other threads:[~2008-03-02 16:27 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-01 1:03 patch for Dired second header line info Drew Adams
2008-03-01 13:31 ` Richard Stallman
2008-03-01 16:31 ` Drew Adams
2008-03-01 23:09 ` Richard Stallman
2008-03-02 2:55 ` Juri Linkov
2008-03-02 8:05 ` Drew Adams
2008-03-02 14:36 ` Juri Linkov
2008-03-02 16:27 ` Drew Adams [this message]
2008-03-02 17:49 ` Drew Adams
2008-03-02 17:57 ` Juri Linkov
2008-03-02 18:56 ` Drew Adams
2008-03-02 19:06 ` Drew Adams
2008-03-03 0:47 ` Drew Adams
2008-03-03 18:27 ` Richard Stallman
2008-03-03 21:45 ` Stefan Monnier
2008-03-03 22:29 ` Drew Adams
2008-03-04 17:38 ` Richard Stallman
2008-03-04 19:44 ` Drew Adams
2008-03-04 22:28 ` Drew Adams
2008-03-05 21:33 ` Richard Stallman
2008-03-03 18:27 ` Richard Stallman
2008-03-03 19:01 ` Drew Adams
2008-03-02 17:56 ` Juri Linkov
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='002801c87c82$539474d0$0600a8c0@us.oracle.com' \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=juri@jurta.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.