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

Previous Next

Package: emacs;

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


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: Fri, 15 Feb 2013 10:25:50 -0500
> dired-hide-details-mode also hides full lines other than header and
> file/directory lines.  This includes the informational line right after
> the header line.
>     /my/directory:
>     total used in directory 1M available 1.0G  <--
>     drwx------  2 me me 4.0K Feb 11 17:35 file

Is that the only full line that it hides, or are there others?

> Apply the patch, revert all hunks to dired-(next|previous)-line and move
> point around the first lines of a dired buffer with hidden details.  Use
> C-n and C-p for point movement.

AFAICT, the resulting behavior (when replacing dired-next-line's body
with forward-line plus dired-move-to-filename) is slightly suboptimal,
but only for that one "hidden usage line" at the top, and even then it's
nothing too terrible.

Thinking of how to "fix it right", I think we'd need to introduce
something like a point-adjustment-function which dired-next-line could
set, and would take a "direction" argument.  So keyboard.c's
adjust_point_for_property would call this function after
adjusting point.  But it seems difficult to introduce such a thing in
a robust way:
- We could have it as a variable, which gets cleared before running the
  next command, but then dired-next-line should only set it when called
  interactively (otherwise if the caller calls dired-next-line within,
  say, a save-excursion, you'd get surprising side-effects).
- We could have it as a property on the `dired-next-line' symbol, but
  then we get the reverse problem, that a wrapper command that just
  calls dired-next-line and not much else would fail to get this part of
  dired-next-line's behavior.

Maybe a cleaner solution is to export keyboard.c's
adjust_point_for_property to Elisp so that dired-next-line can call
it explicitly (to replace your "(while (and (invisible-p (point))) ...)"
loop).


        Stefan




This bug report was last modified 12 years and 146 days ago.

Previous Next


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