bug#48883: dired marking bugs

bug#48883: dired marking bugs

[Boruch Baum]

In testing my diredc package, I'm coming across the following bugs
reproducable in \emacs -Q -nw:

1) Improper marking of directory heading line

   1.1) The correct and expected behavior of dired is that when one
        navigates to a directory heading line (eg. the first line of a
        simple dired buffer) and presses 'm', all "real" files of that
        directory are marked, [IMPORTANT] the lines for the "not-real"
        files '.' and '..' are not marked, and [IMPORTANT] the directory
        line itself is not marked.

   1.2) Likewise, typing 'u' on that line unmarks all said lines.

   1.3) Now, advance one line, to the line typically presenting a
        summary, beginning with the word 'total', and press the sequence
        'C-u -1 m'.

   1.4) Why is there now a mark on the prior line, the directory line?
        Note that the result differs from actually performing 'm' on
        that line also in that none of the "real" files in the directory
        are marked. Note also that performing 'u' on the line does not
        remove the mark, but performing 'U' on the buffer does.

   1.5) Attempting to perform an operation on the marked directory line
        (eg. 'C' to copy it) returns the message "No files specified"

2) Improper marking of "not-real" files '.' and '..'

   2.1) See paragraph 1.1.

   2.2) However, those lines can be manually marked using the 'm'
        command, and attempting to perform an operation on them (eg. 'C'
        to copy them) returns messaging indicating a willingness to
        overwrite whatever target directory is chosen. I haven't risked
        let it operate.

   2.3) As in paragraph 1.3, it is possible to mark the two lines using
        a negative prefix argument.

3) Improper advancing to (point-max)

   3.1) Marking the final entry in a dired buffer advances POINT to a
        blank line, which is pretty much never desirable to a user.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#48883: [External] : bug#48883: dired marking bugs

[Drew Adams]

I'll chime in here, unsolicited - feel free to ignore.

Glad you reported this, Boruch.  Congratulations on
finding a decades-old problem!

> I'm coming across the following bugs
> reproducable in \emacs -Q -nw:
> 
> 1) Improper marking of directory heading line
> 
>    1.1) The correct and expected behavior of dired is that when one
>         navigates to a directory heading line (eg. the first line of a
>         simple dired buffer) and presses 'm', all "real" files of that
>         directory are marked, [IMPORTANT] the lines for the "not-real"
>         files '.' and '..' are not marked, and [IMPORTANT] the directory
>         line itself is not marked.
> 
>    1.2) Likewise, typing 'u' on that line unmarks all said lines.

(You don't say so, but I think/hope you agree that
1.1 and 1.2 are OK, not something improper.)

>    1.3) Now, advance one line, to the line typically presenting a
>         summary, beginning with the word 'total', and press the sequence
>         'C-u -1 m'.
> 
>    1.4) Why is there now a mark on the prior line, the directory line?
>         Note that the result differs from actually performing 'm' on
>         that line also in that none of the "real" files in the directory
>         are marked. Note also that performing 'u' on the line does not
>         remove the mark, but performing 'U' on the buffer does.

Agreed - a bug.

This change to `dired-repeat-over-lines' seems to
take care of that OK:

In the second `while' (the one for negative movement),
change (save-excursion (funcall function)) to this:
(when (dired-get-filename nil t) ; <=======
  (save-excursion (funcall function)))

[I've added `dired-repeat-over-lines' to dired+.el and
made that change.  If this gets fixed in vanilla Dired
too (hopefully) then I'll be able to remove that
dired+.el change - except for older Emacs versions.] 

>    1.5) Attempting to perform an operation on the marked directory line
>         (eg. 'C' to copy it) returns the message "No files specified"

IMO, that's not a problem.  (I assume here you're
talking about point being on the dir heading line
and no (other) files being marked.)  There _are_
(should be) no files specified.

> 2) Improper marking of "not-real" files '.' and '..'
> 
>    2.1) See paragraph 1.1.
> 
>    2.2) However, those lines can be manually marked using the 'm'
>         command, and attempting to perform an operation on them (eg. 'C'
>         to copy them) returns messaging indicating a willingness to
>         overwrite whatever target directory is chosen. I haven't risked
>         let it operate.
> 
>    2.3) As in paragraph 1.3, it is possible to mark the two lines using
>         a negative prefix argument.

IMO, there's nothing wrong with marking `.' or `..',
and nothing wrong with Dired having some operations
that work on them.

It's fine for it to have some other operations that
don't work for them, of course.  In that case, users
can be informed about that when they try those ops.

> 3) Improper advancing to (point-max)
> 
>    3.1) Marking the final entry in a dired buffer advances POINT to a
>         blank line, which is pretty much never desirable to a user.

I don't see that as a problem.  FWIW, with my code
(`dired+.el') a user can optionally wrap around from
the last line to the first, and vice versa, using the
line motion commands (e.g. `SPC', `down').

bug#48883: [External] : bug#48883: dired marking bugs

[Boruch Baum]

[-- Attachment #1: Type: text/plain, Size: 3934 bytes --]

On 2021-06-06 22:12, Drew Adams wrote:
> >    1.1) The correct and expected behavior of dired is that when one
> >    ...
> >    1.2) Likewise, typing 'u' on that line unmarks all said lines.
>
> (You don't say so, but I think/hope you agree that
> 1.1 and 1.2 are OK, not something improper.)

Agreed.

>
> >    1.3) Now, advance one line, to the line typically presenting a
> >         summary, beginning with the word 'total', and press the sequence
> >         'C-u -1 m'.
> >
> >    1.4) Why is there now a mark on the prior line, the directory line?
> >         Note that the result differs from actually performing 'm' on
> >         that line also in that none of the "real" files in the directory
> >         are marked. Note also that performing 'u' on the line does not
> >         remove the mark, but performing 'U' on the buffer does.

> This change to `dired-repeat-over-lines' seems to
> take care of that OK:
>
> In the second `while' (the one for negative movement),
> change (save-excursion (funcall function)) to this:
> (when (dired-get-filename nil t) ; <=======
>   (save-excursion (funcall function)))

I don't like that change because it allows operations on '.' and '..'
which makes me uncomfortable.

I have a patch in testing, but I want to do some more work before
submitting it (and who knows, some emacs devel may insist none of this
is a bug!).

What I see as possibly the issue is function `dired-between-files'. I'm
not equipped to perform a 'git blame', but the function's comment
indicated a change at some point, and I suspect that's when the bug
arose.

> >    1.5) Attempting to perform an operation on the marked directory line
> >         (eg. 'C' to copy it) returns the message "No files specified"
>
> IMO, that's not a problem.  (I assume here you're
> talking about point being on the dir heading line
> and no (other) files being marked.)  There _are_
> (should be) no files specified.

Agreed. I should have made that clear.

> IMO, there's nothing wrong with marking `.' or `..',
> and nothing wrong with Dired having some operations
> that work on them.

I don't feel comfortable with that. Do you have any specific case in
mind?

> > 3) Improper advancing to (point-max)
> >
> >    3.1) Marking the final entry in a dired buffer advances POINT to a
> >         blank line, which is pretty much never desirable to a user.
>
> I don't see that as a problem.

I agree that it isn't a *problem*, just that it's not friendly.

OK. I've changed my mind, and am submitting my current patch. The reason
I thought not to above is that I might want to propose changing function
`dired-between-files'. However, from performing M-x rzgrep on the lisp
directory, I see it referred to 9 times, and I haven't checked them yet:

./dired.el.gz:3498:      (while (and (not (eobp)) (dired-between-files)) (forward-line 1))
./dired.el.gz:3509:      (while (and (not (bobp)) (dired-between-files)) (forward-line -1))
./dired.el.gz:3515:(defun dired-between-files ()
./dired.el.gz:3570:      (while (and (< (point) end) (dired-between-files))
./dired.el.gz:3652:        (or (dired-between-files)
./files.el.gz:6944:;;		 dired-between-files, (shortcut for (not (dired-move-to-filename)))
./net/ange-ftp.el.gz:5440:;;(or (assq 'vms ange-ftp-dired-between-files-alist)
./net/ange-ftp.el.gz:5441:;;    (setq ange-ftp-dired-between-files-alist
./net/ange-ftp.el.gz:5443:;;		ange-ftp-dired-between-files-alist)))

Also, because dired is such an old feature of emacs, and since it is the
subject of so many third-party[1] extensions, any *fix* to that function,
even if correct, might have undesirable consequences downstream, so I
want to careful about it.


[1] I know I keep saying 'third-party' but I have no idea who is the second-party.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

[-- Attachment #2: dired.patch --]
[-- Type: text/x-diff, Size: 1557 bytes --]

(defun dired-repeat-over-lines (arg function)
  ;; This version skips non-file lines.
  (let ((pos (make-marker)))
    (beginning-of-line)
    (cond
     ((> arg 0)
       (while (and (> arg 0) (not (eobp)))
         (setq arg (1- arg))
         (beginning-of-line)
       ;;(while (and (not (eobp)) (dired-between-files)) (forward-line 1))
         (while (and (not (eobp))
                     (condition-case nil
                       (not (dired-get-filename))
                       (error t)))
           (forward-line 1))
         (save-excursion
           (forward-line 1)
           (move-marker pos (1+ (point))))
         (save-excursion (funcall function))
         ;; Advance to the next line--actually, to the line that *was* next.
         ;; (If FUNCTION inserted some new lines in between, skip them.)
         (goto-char pos))
       (when (eobp)
         (forward-line -1)
         (dired-move-to-filename)))
     ((< arg 0)
       (while (and (< arg 0) (not (bobp)))
         (setq arg (1+ arg))
         (forward-line -1)
       ;;(while (and (not (bobp)) (dired-between-files)) (forward-line -1))
         (while (and (not (bobp))
                     (condition-case nil
                       (not (dired-get-filename))
                       (error t)))
           (forward-line -1))
         (beginning-of-line)
         (when (condition-case nil
                 (dired-get-filename)
                 (error nil))
           (save-excursion (funcall function))))
       (move-marker pos nil)
       (dired-move-to-filename)))))

bug#48883: [External] : bug#48883: dired marking bugs

[Drew Adams]

> > In the second `while' (the one for negative movement),
> > change (save-excursion (funcall function)) to this:
> > (when (dired-get-filename nil t) ; <=======
> >   (save-excursion (funcall function)))
> 
> I don't like that change because it allows operations
> on '.' and '..' which makes me uncomfortable.

OK.

I disagree that ALL operations on `.' and `..' should
be disallowed, but what you say follows what will
likely be wanted for vanilla Emacs, I expect.

My own position (used in Dired+), is that Dired
operations can in principle be anything.

They are operations on the buffer and its text, first
and foremost.  Only some of them are operations on
files and dirs listed in the buffer.

My position (for Dired+, and suggested but not
expected for vanilla Dired) is that it's up to the
particular function whether and how it might be
relevant for `.' or `..'.

Some operations might make sense; others might not.
The idea that NO operation could make sense on `.'
or `..' would be misguided, IMO.  It's unnecessarily
limiting.  `.' and `..' are just names for certain
directories.  Dired doesn't outlaw operations on
other lines that name directories.

[The same is true for shell commands, BTW.  They
don't exclude acting on `.' or `..'.]

> What I see as possibly the issue is function `dired-between-files'. I'm
> not equipped to perform a 'git blame', but the function's comment
> indicated a change at some point, and I suspect that's when the bug
> arose.

The bug exists at least as far back as Emacs 20.

Yes, we could consider that the bug is in
`dired-move-to-filename' (used by
`dired-between-files').  So far, I've chosen to
consider it to be just in `dired-repeat-over-lines'.

> > IMO, there's nothing wrong with marking `.' or `..',
> > and nothing wrong with Dired having some operations
> > that work on them.
> 
> I don't feel comfortable with that. Do you have
> any specific case in mind?

See above.  

BTW, even vanilla Emacs presents some specific cases.

It lets `dired-get-filename' treat `.' and `..' as
regular file names, with non-nil arg
NO-ERROR-IF-NOT-FILEP.

And `dired-find-file' operates normally on `.' and `..'.

[That has always been the case, AFAIK.  But before Emacs
21 it didn't use `dired-get-filename' (via
`dired-get-file-for-visit').  Starting with 21, it has,
passing non-nil NO-ERROR-IF-NOT-FILEP.]

Likewise, `dired-mouse-find-file-other-window' operates
on `.' and `..'.

bug#48883: [External] : bug#48883: dired marking bugs

[Boruch Baum]

Here's a follow-up related bug: If one marks one of what I've been
calling the "not-real" files '.' or ',,' and then perform action 't' to
toggle the marks, those elements do not toggle.


--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#48883: [External] : bug#48883: dired marking bugs

[Drew Adams]

> Here's a follow-up related bug: If one marks one of what I've been
> calling the "not-real" files '.' or ',,' and then perform action 't' to
> toggle the marks, those elements do not toggle.

+1.

bug#48883: [External] : bug#48883: dired marking bugs

[Drew Adams]

> > Here's a follow-up related bug: If one marks one of what I've been
> > calling the "not-real" files '.' or ',,' and then perform action 't' to
> > toggle the marks, those elements do not toggle.
> 
> +1.

Hm, the doc string says that `.' and `..' are never
toggled.  That means that this was intentional (why?).

But (luckily) `dired-toggle-marks' is not used
anywhere in the vanilla Emacs Lisp code (except as
for key bindings).

A proper change could perhaps be one of the following:

* Just let it toggle `.' and `..', reversing the
  design (intention) for those.

* Do that only when invoked interactively (so any code
  that invokes it non-interactively isn't affected).

* Add a user option, to control whether it toggles
  `.' and `..'.

(For Dired+ I'll go with the first, at least until
or unless vanilla Emacs decides to do something
else for this.)
___

BTW, the doc string for this is not good.  It speaks
of "other flags (such as `D')".  It should say "other
marks (such as `D')."  `D' is the only mark that we
refer to also as a "flag" - there are no other flags.
___

BTW2: What is the "insdel" referred to in the code
comment?

bug#48883: [External] : bug#48883: dired marking bugs

[Boruch Baum]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

Attached are two updated fix files.

file dired.2.patch is a slight modifcation of my first submission, to
cover a case of being in an empty directory.

file dired.3.patch is possibly a 'better' fix in that it addresses a
deficiency in function `dired-between-lines'. The emacs developers may
decide that method is undesirable and prefer the first patch.

Technically, neither file is a 'patch' file, but both are simple small
drop-in replacements for content of file dired.el @line ~3500. If for
this, you decide you need a real patch file, fine, just tell me for
which option.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

[-- Attachment #2: dired.2.patch --]
[-- Type: text/x-diff, Size: 1590 bytes --]

(defun dired-repeat-over-lines (arg function)
  ;; This version skips non-file lines.
  (let ((pos (make-marker)))
    (beginning-of-line)
    (cond
     ((> arg 0)
       (while (and (> arg 0) (not (eobp)))
         (setq arg (1- arg))
         (beginning-of-line)
       ;;(while (and (not (eobp)) (dired-between-files)) (forward-line 1))
         (while (and (not (eobp))
                     (condition-case nil
                       (not (dired-get-filename))
                       (error t)))
           (forward-line 1))
         (save-excursion
           (forward-line 1)
           (move-marker pos (1+ (point))))
         (unless (eobp)
           (save-excursion (funcall function))
           ;; Advance to the next line--actually, to the line that *was* next.
           ;; (If FUNCTION inserted some new lines in between, skip them.)
           (goto-char pos)))
       (when (eobp)
         (forward-line -1)
         (dired-move-to-filename)))
     ((< arg 0)
       (while (and (< arg 0) (not (bobp)))
         (setq arg (1+ arg))
         (forward-line -1)
       ;;(while (and (not (bobp)) (dired-between-files)) (forward-line -1))
         (while (and (not (bobp))
                     (condition-case nil
                       (not (dired-get-filename))
                       (error t)))
           (forward-line -1))
         (beginning-of-line)
         (when (condition-case nil
                 (dired-get-filename)
                 (error nil))
           (save-excursion (funcall function))))
       (move-marker pos nil)
       (dired-move-to-filename)))))

[-- Attachment #3: dired.3.patch --]
[-- Type: text/x-diff, Size: 1505 bytes --]

(defun dired-repeat-over-lines (arg function)
  ;; This version skips non-file lines.
  (let ((pos (make-marker)))
    (beginning-of-line)
    (cond
     ((> arg 0)
       (while (and (> arg 0) (not (eobp)))
         (setq arg (1- arg))
         (beginning-of-line)
         (while (and (not (eobp)) (dired-between-files)) (forward-line 1))
         (save-excursion
           (forward-line 1)
           (move-marker pos (1+ (point))))
         (unless (eobp)
           (save-excursion (funcall function))
           ;; Advance to the next line--actually, to the line that *was* next.
           ;; (If FUNCTION inserted some new lines in between, skip them.)
           (goto-char pos)))
       (when (eobp)
         (forward-line -1)
         (dired-move-to-filename)))
     ((< arg 0)
       (while (and (< arg 0) (not (bobp)))
         (setq arg (1+ arg))
         (forward-line -1)
         (while (and (not (bobp)) (dired-between-files)) (forward-line -1))
         (beginning-of-line)
         (when (condition-case nil
                 (dired-get-filename)
                 (error nil))
           (save-excursion (funcall function))))
       (move-marker pos nil)
       (dired-move-to-filename)))))

(defun dired-between-files ()
  ;; This used to be a regexp match of the `total ...' line output by
  ;; ls, which is slightly faster, but that is not very robust; notably,
  ;; it fails for non-english locales.
  (not (condition-case nil
         (dired-get-filename)
         (error nil))))

bug#48883: dired marking bugs

[Arthur Miller]

Boruch Baum <boruch_baum@gmx.com> writes:

> In testing my diredc package, I'm coming across the following bugs
> reproducable in \emacs -Q -nw:
>
> 1) Improper marking of directory heading line
>
>    1.1) The correct and expected behavior of dired is that when one
>         navigates to a directory heading line (eg. the first line of a
>         simple dired buffer) and presses 'm', all "real" files of that
>         directory are marked, [IMPORTANT] the lines for the "not-real"
>         files '.' and '..' are not marked, and [IMPORTANT] the directory
>         line itself is not marked.
I have no idea if that is "correct and expected behaviour", I don't see
it said in manual, or I missed it, but anyway, the headline in Dired is
a waste of space since you can see dir name in modeline or frame title,
and '.' and '..' are just a design misstake in Unix OS; should have
never been exposed to users as files. Just turn off those things
(dired-omit-mode), you will probably be better without them. :-). Sorry
if I sound negative.

>    1.2) Likewise, typing 'u' on that line unmarks all said lines.
'U' unmarks everything, no need to put cursor to headline ever.

>    1.3) Now, advance one line, to the line typically presenting a
>         summary, beginning with the word 'total', and press the sequence
>         'C-u -1 m'.
>
>    1.4) Why is there now a mark on the prior line, the directory line?
>         Note that the result differs from actually performing 'm' on
>         that line also in that none of the "real" files in the directory
>         are marked. Note also that performing 'u' on the line does not
>         remove the mark, but performing 'U' on the buffer does.
>
>    1.5) Attempting to perform an operation on the marked directory line
>         (eg. 'C' to copy it) returns the message "No files specified"
>
> 2) Improper marking of "not-real" files '.' and '..'
>
>    2.1) See paragraph 1.1.
>
>    2.2) However, those lines can be manually marked using the 'm'
>         command, and attempting to perform an operation on them (eg. 'C'
>         to copy them) returns messaging indicating a willingness to
>         overwrite whatever target directory is chosen. I haven't risked
>         let it operate.
>
>    2.3) As in paragraph 1.3, it is possible to mark the two lines using
>         a negative prefix argument.
Have you checked the code. Not a bug, feature :).

> 3) Improper advancing to (point-max)
>
>    3.1) Marking the final entry in a dired buffer advances POINT to a
>         blank line, which is pretty much never desirable to a user.
Yeah, that is annoying, I agree with you. For my own use, I have thse
two functions, so I never place cursor on either headline or one past
last filename:

#+begin_src emacs-lisp

(defun dired-go-to-first ()
  (interactive)
  (goto-char (point-min))
  (dired-next-line 1)
  (skip-chars-forward " \n\t"))

(defun dired-go-to-last ()
  (interactive)
  (goto-char (point-max))
  (dired-next-line -1)
  (skip-chars-forward " \n\t"))
  
#+end_src

bug#48883: dired marking bugs

[Filipp Gunbin]

On 07/06/2021 20:53 +0200, Arthur Miller wrote:

> Boruch Baum <boruch_baum@gmx.com> writes:
>
>> In testing my diredc package, I'm coming across the following bugs
>> reproducable in \emacs -Q -nw:
>>
>> 1) Improper marking of directory heading line
>>
>>    1.1) The correct and expected behavior of dired is that when one
>>         navigates to a directory heading line (eg. the first line of a
>>         simple dired buffer) and presses 'm', all "real" files of that
>>         directory are marked, [IMPORTANT] the lines for the "not-real"
>>         files '.' and '..' are not marked, and [IMPORTANT] the directory
>>         line itself is not marked.
> I have no idea if that is "correct and expected behaviour", I don't see
> it said in manual, or I missed it, but anyway, the headline in Dired is
> a waste of space since you can see dir name in modeline or frame title,
> [...]

The headlines are very much needed if you have -R in ls switches…

bug#48883: dired marking bugs

[Arthur Miller]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> On 07/06/2021 20:53 +0200, Arthur Miller wrote:
>
>> Boruch Baum <boruch_baum@gmx.com> writes:
>>
>>> In testing my diredc package, I'm coming across the following bugs
>>> reproducable in \emacs -Q -nw:
>>>
>>> 1) Improper marking of directory heading line
>>>
>>>    1.1) The correct and expected behavior of dired is that when one
>>>         navigates to a directory heading line (eg. the first line of a
>>>         simple dired buffer) and presses 'm', all "real" files of that
>>>         directory are marked, [IMPORTANT] the lines for the "not-real"
>>>         files '.' and '..' are not marked, and [IMPORTANT] the directory
>>>         line itself is not marked.
>> I have no idea if that is "correct and expected behaviour", I don't see
>> it said in manual, or I missed it, but anyway, the headline in Dired is
>> a waste of space since you can see dir name in modeline or frame title,
>> [...]
>
> The headlines are very much needed if you have -R in ls switches…

Aha, so it would insert a headline for each recursive listing. Ok, that
make sense.

Thanks for pointing it out. I have never used -R in listing
switches. Is it useful in real-world? I can just imagine how long time
would take for emacs to list entire /home/user dir. I tried it now just
for the test, but I had to press C-g after few seconds.

Actually when thinking of it, I don't use 'i' to insert a
directory either but I am aware of it, and I guess it also needs a
headline as a visual delimiter. Anyway I never really find it pretty or
useful to insert a subdir below entire content. Instead I use a
package dired-hacks which has a utility dired-subtree which lets me
toggle subdir similar to a conventional file manager. It works similar
to headlines in outline/org mode which I think is a bit more natural to use.

bug#48883: dired marking bugs

[Filipp Gunbin]

On 08/06/2021 06:15 +0200, Arthur Miller wrote:

> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>
>> On 07/06/2021 20:53 +0200, Arthur Miller wrote:
>>
>>> Boruch Baum <boruch_baum@gmx.com> writes:
>>>
>>>> In testing my diredc package, I'm coming across the following bugs
>>>> reproducable in \emacs -Q -nw:
>>>>
>>>> 1) Improper marking of directory heading line
>>>>
>>>>    1.1) The correct and expected behavior of dired is that when one
>>>>         navigates to a directory heading line (eg. the first line of a
>>>>         simple dired buffer) and presses 'm', all "real" files of that
>>>>         directory are marked, [IMPORTANT] the lines for the "not-real"
>>>>         files '.' and '..' are not marked, and [IMPORTANT] the directory
>>>>         line itself is not marked.
>>> I have no idea if that is "correct and expected behaviour", I don't see
>>> it said in manual, or I missed it, but anyway, the headline in Dired is
>>> a waste of space since you can see dir name in modeline or frame title,
>>> [...]
>>
>> The headlines are very much needed if you have -R in ls switches…
>
> Aha, so it would insert a headline for each recursive listing. Ok, that
> make sense.
>
> Thanks for pointing it out. I have never used -R in listing
> switches. Is it useful in real-world? I can just imagine how long time
> would take for emacs to list entire /home/user dir. I tried it now just
> for the test, but I had to press C-g after few seconds.
>
> Actually when thinking of it, I don't use 'i' to insert a
> directory either but I am aware of it, and I guess it also needs a
> headline as a visual delimiter. Anyway I never really find it pretty or
> useful to insert a subdir below entire content. Instead I use a
> package dired-hacks which has a utility dired-subtree which lets me
> toggle subdir similar to a conventional file manager. It works similar
> to headlines in outline/org mode which I think is a bit more natural to use.

Yes, I use -R and "i" all the time.  -R (together with (setq
dired-isearch-filenames t)) is useful for java projects, which usually
don't have much files, but a lot of nested directories.  "i" is
convenient for navigating when I know the directory structure.

Thanks for mentioning dired-hacks, I didn't know about it.

Filipp