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

[Christopher Schmidt]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>    (forward-line arg)
>> +  (while (and (progn
>> +            (while (and (< arg 0)
>> +                        (bolp)
>> +                        (/= (1+ (point)) (point-max))
>> +                        (eq (get-text-property (1+ (point)) 'invisible)
>> +                            'dired-hide-details-information))
>> +              (forward-char -1))
>> +            (invisible-p (point)))
>> +          (let ((p (funcall (if (> arg 0)
>> +                                'next-single-property-change
>> +                              'previous-single-property-change)
>> +                            (point)
>> +                            'invisible)))
>> +            (when p
>> +              (goto-char p)
>> +              t))))
>>    (dired-move-to-filename))
>
> What is this for?

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.

    (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 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.

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.

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.

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

        Christopher