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

[Stefan Monnier]

> 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