bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]

[Stefan Monnier <monnier@iro.umontreal.ca>]

> dired-(next|previous)-line use (forward|backward)-line for point
> movement.  These functions ignore hidden lines and subsequent point
> movement by the editing loop does not do the right thing when point
> moves backwards over a hidden line.

Thanks.  Then the code needs a clear comment about it, citing the
specific concrete case that it's trying to fix.

>     (defvar use-case 0)

>     (with-selected-window
>         (or (get-buffer-window "*moose*")
>             (progn
>               (split-window-below)))
>       (switch-to-buffer (get-buffer-create "*moose*"))
>       (erase-buffer)

>       (insert "Header\n"
>               (propertize "Hidden\n" 'invisible t)
>               "Stuff")

>       (cl-ecase use-case
>         (0
>          (goto-char (point-min))
>          (forward-line 1))
>         (1
>          (goto-char (point-max))
>          (forward-line -1))
>         (2
>          (goto-char (point-min))
>          (next-line 1))
>         (3
>          (goto-char (point-max))
>          (next-line -1)))
>       (prog1 use-case
>         (setq use-case (% (1+ use-case) 4))))

> Put that in scratch, eval the first form, eval the second form four
> times in a row.  Use case 1 does not work.  The change you cited tries
> to work around this problem in dired.

I'm not sure what this shows: I get a buffer with two visible lines
("Header" and "Stuff"); case 0 moves point to just before "Stuff" and so
does case 1, and both seem right to my understanding of the code
you provided.

> I do not know whether dired-(next|previous)-line should use
> (next|previous)-line with nil-bound line-move-visual.  AFAICT
> (next|previous)-line do not do the right thing either.
>>> +  (if (derived-mode-p 'locate-mode)
>>> +      (setq dired-hide-details-mode nil)
>> Could you explain why locate-mode needs such special treatment (here
>> and in locate-mode-map)?  I'm mostly worried here that maybe some
>> other mode might require similar treatment.
> The buffer generated by M-x locate RET does not contain any "details" to
> hide.  dired-hide-details-mode would be a no-op there.

A no-op doesn't sound like a bad thing.

> Locate buffers are not real dired buffer.  locate-mode is an independent
> major mode whose keymap derives from dired-mode-map.  locate runs
> dired-mode-hook despite the current buffer not being derived from
> dired-mode.

Indeed, it looks messy: it runs dired-mode-hook but not from
locate-mode.  Of course, part of it is because dired-mode is still not
written as a proper mode function (e.g. it requires a `dir' argument),
so locate can't use it to derive from it.

> I think ignoring locate is better than complaining that
> dired-hide-details-mode is enabled in a buffer that is not derived
> from dired-mode.

If, as you say, dired-details would simply be a no-op in locate, then
I think the better option is to simply ignore locate, in the sense of
not doing anything special about, rather than write code that tries to
actively avoid running dired-details code in locate.

> I am not aware of any other mode that behaves that way.

I was thinking of virtual-dired (in dired-x), vc-dired (which doesn't
exist any more in Emacs, but there might still be similar thingies out
there), ...


        Stefan