GNU bug report logs -
#6799
24.0.50; Please add dired-details.el to Emacs [patch]
Previous Next
Reported by: "Drew Adams" <drew.adams <at> oracle.com>
Date: Thu, 5 Aug 2010 14:59:01 UTC
Severity: wishlist
Tags: patch
Found in version 24.0.50
Done: Christopher Schmidt <christopher <at> ch.ristopher.com>
Bug is archived. No further changes may be made.
Full log
Message #56 received at submit <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> 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
This bug report was last modified 12 years and 145 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.