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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 6799 <at> debbugs.gnu.org
Subject: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Mon, 11 Feb 2013 09:25:40 -0500

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.