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

Previous Next

Full log

Message #62 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <christopher <at> ch.ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Mon, 11 Feb 2013 16:08:42 +0000 (GMT)

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

Hi Stefan,

thank you very much for your feedback.

>> 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.
[...]
>> 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.

Emacs behaves correctly.  (forward-line -1) is executed but the point
does not move across one visible line.  (dired-next-line -1) should skip
hidden lines, though.  (next-line -1) does the right thing.

Unfortunately next-line has some quirks, such as goal-column,
next-line-add-newlines, etc.  What about using line-move directly?  The
workaround is less cumbersome.

    (defun dired-next-line (arg)
      "Move down lines then position at filename.
    Optional prefix ARG says how many lines to move; default is one line."
      (interactive "p")
      (let ((line-move-visual)
            (goal-column))
        (line-move arg t))
      ;; We never want to move point into an invisible line.
      (while (and (invisible-p (point))
                  (not (if (and arg (< arg 0)) (bobp) (eobp))))
        (forward-char (if (and arg (< arg 0)) -1 1)))
      (dired-move-to-filename))

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

There is the message "Dired-Hide-Details mode (disabled|enabled)".

Is there any reason for locate-filename-indentation to be 4 rather than
2 by default?

Dired-hide-details-mode considers everything from the third character to
the file name to be a detail.  That is dired-hide-details-mode hides
these two spaces if enabled.  This is either a bug or a feature.  I do
not know.

Other than that, dired-hide-details-mode it is a no-op in locate-mode
buffers.

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

Could we set the derived-mode-parent property of locate-mode to
dired-mode?  One way or another, (derived-mode-p 'dired-mode) should
return non-nil in locate-mode buffers.

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

Ok.

>> 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), ...

As long as these modes use dired-insert-set-properties in the way it is
meant to be there should not be a problem.

        Christopher

Previous Next

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