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

[Christopher Schmidt <christopher@ch.ristopher.com>]

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