bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Christopher Schmidt
Subject: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Fri, 15 Feb 2013 18:44:24 +0000 (GMT)

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 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?

Each and every line that is not a file line and that
dired-insert-set-properties is called upon.

In dired it is only this informational line.  In find-dired the
footer is hidden as well.

    find finished at Fri Feb 15 20:00:00

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

Yes, that would be great.

        Christopher





reply via email to

[Prev in Thread] Current Thread [Next in Thread]