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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6799 in the body.
You can then email your comments to 6799 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Cc: 'Rob Giardina' <rob <at> razoo.com>
Subject: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Thu, 5 Aug 2010 07:20:38 -0700

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-08-02 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags -Ic:/xpm/include'

---

Per Juanma's request, this is a another reminder to please add
`dired-details.el', with links to the threads that reference Rob Giardino's
patches.

--------------------------------------
> From: Juanma Barranquero   Sent: Thursday, August 05, 2010 3:19 AM
> To: help-gnu-emacs <at> gnu.org Subject: Re: A "smaller" dired
> 
> On Wed, Aug 4, 2010 at 17:50, Drew Adams wrote
>
> > [FWIW - This feature was OK'd for addition to vanilla Emacs 
> >  a few years ago, but no one has bothered to add it.
> >  The author of dired-details.el and myself tried
> >  several times to get past the inertia, but to no avail so far.]
> 
> A patch, or at least a reminder, to the bug list with a wishlist tag
> would help IMO.

--------------------------------------
> From: Drew Adams        Sent: Sunday, July 19, 2009 7:34 AM
> To: emacs-devel <at> gnu.org Subject: RE: dired-details[+].el
> 
> > I discovered dired-details and dired-details+ and found them useful.
> > Could they be added to emacs?
> > 
> > http://www.emacswiki.org/emacs/DiredDetails
> 
> They were supposed to be added. Rob Giardina submitted an 
> Emacs 23 patch two
> years ago that integrates the functionality of both in a 
> better way even than
> the separate libraries dired-details[+].el. 
> 
> I don't think any reason was ever given for why the patch 
> wasn't incorporated
> (committed). RMS asked for comment on the merged code, but no 
> one ever answered
> his request (on emacs-devel, at least). The last time I 
> ping'ed the list about
> this was 2008-07 - I never got an answer either.
> 
> Last ping:
> http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg01152.html
> 
> Rob's change log and RMS's call for comment:
> http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg01187.html
> 
> Original thread:
> http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg00226.html

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <6799 <at> debbugs.gnu.org>
Subject: RE: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Fri, 28 Jan 2011 15:08:18 -0800

PING

This code has been agreed to since RMS was in charge, and it was made available
(integrated) by Rob Giardina - years ago.  What's the story?

> Per Juanma's request, this is a another reminder to please add
> `dired-details.el', with links to the threads that reference 
> Rob Giardino's patches.
> 
> > From: Juanma Barranquero   Sent: Thursday, August 05, 2010 3:19 AM
> > To: help-gnu-emacs <at> gnu.org Subject: Re: A "smaller" dired
> > 
> > > [FWIW - This feature was OK'd for addition to vanilla Emacs 
> > >  a few years ago, but no one has bothered to add it.
> > >  The author of dired-details.el and myself tried
> > >  several times to get past the inertia, but to no avail so far.]
> > 
> > A patch, or at least a reminder, to the bug list with a wishlist tag
> > would help IMO.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 6799 <at> debbugs.gnu.org
Subject: Re: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Sun, 13 Mar 2011 04:28:02 +0100

On Sat, Jan 29, 2011 at 00:08, Drew Adams <drew.adams <at> oracle.com> wrote:
> PING
>
> This code has been agreed to since RMS was in charge, and it was made available
> (integrated) by Rob Giardina - years ago.  What's the story?

Let's move this forward.

Which was the intention, adding dired-details.el, or patching dired.el
to add the functionality?

    Juanma

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Juanma Barranquero'" <lekktu <at> gmail.com>
Cc: 6799 <at> debbugs.gnu.org
Subject: RE: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Sun, 13 Mar 2011 09:58:27 -0700

> <drew.adams <at> oracle.com> wrote:
> > PING
> >
> > This code has been agreed to since RMS was in charge, and 
> > it was made available (integrated) by Rob Giardina - years ago.
> > What's the story?
> 
> Let's move this forward.
> 
> Which was the intention, adding dired-details.el, or patching dired.el
> to add the functionality?

Please contact Rob Giardina.  I believe that he patched the existing Dired code
(and some C code? and some other Lisp code?), doing everything that was needed.

Dunno what his current address is.  Here are some that have worked in the past:

rob <AT> razoo <DOT> com
rob <DOT> giardina <AT> gmail <DOT> com
rob <AT> giardina <DOT> us

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

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'Juanma Barranquero' <lekktu <at> gmail.com>, 6799 <at> debbugs.gnu.org
Subject: Re: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Thu, 12 Apr 2012 21:10:59 +0200

"Drew Adams" <drew.adams <at> oracle.com> writes:

> Please contact Rob Giardina.  I believe that he patched the existing
> Dired code (and some C code? and some other Lisp code?), doing
> everything that was needed.
>
> Dunno what his current address is.  Here are some that have worked in
> the past:
>
> rob <AT> razoo <DOT> com
> rob <DOT> giardina <AT> gmail <DOT> com
> rob <AT> giardina <DOT> us

If you want this code included in Emacs, please assemble the patch and
post it here.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Lars Magne Ingebrigtsen'" <larsi <at> gnus.org>
Cc: 'Juanma Barranquero' <lekktu <at> gmail.com>, 6799 <at> debbugs.gnu.org,
	rob <at> giardina.us
Subject: RE: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Thu, 12 Apr 2012 13:05:06 -0700

As I have said several times now, ask Rob Giardina.  He made a whole set of
changes to various Emacs files, including perhaps C code.  I am not aware of
what changes he made. 

Rob has sent mail as recently as 2011/11/29 to emacs-orgmode <at> gnu.org.  His
address for that was rob <at> giardina.us.  (No, I do not subscribe to that mailing
list.  But I know how to use Google.)  Please contact Rob.

> > Please contact Rob Giardina.  I believe that he patched the existing
> > Dired code (and some C code? and some other Lisp code?), doing
> > everything that was needed.
> 
> If you want this code included in Emacs, please assemble the patch and
> post it here.

It is not a question of "if I want".  It was decided by RMS that this should be
included in Emacs.  Long, long ago.  Rob did the work required for this to
happen, but no one ever committed it, AFAIK.

What I use, personally, is dired-details.el plus dired-details+.el, and they
suffice.  But Rob went to the trouble of patching Emacs in various places,
integrating the features cleanly at a more basic level etc.

I have no idea what Rob's changes were, but if you search the mailing list
perhaps you can find references to them.  Rob refers to a patch for 2005-07-07
CVS, here:
http://comments.gmane.org/gmane.emacs.devel/74172

Here is the last mail from Rob on the subject, AFAIK:
http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg00215.html

Here is my last mail on the subject, with relevant links: 

> From: Drew Adams Sent: Sunday, July 19, 2009 7:34 AM
> > I discovered dired-details and dired-details+ and found them useful.
> > Could they be added to emacs?
> > 
> > http://www.emacswiki.org/emacs/DiredDetails
> 
> They were supposed to be added. Rob Giardina submitted an 
> Emacs 23 patch two years ago that integrates the functionality
> of both in a better way even than the separate libraries
> dired-details[+].el. 
> 
> I don't think any reason was ever given for why the patch 
> wasn't incorporated (committed). RMS asked for comment on
> the merged code, but no one ever answered his request
> (on emacs-devel, at least). The last time I ping'ed the
> list about this was 2008-07 - I never got an answer either.
> 
> Last ping:
> http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg01152.html
> 
> Rob's change log and RMS's call for comment:
> http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg01187.html
> 
> Original thread:
> http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg00226.html

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

From: Rob Giardina <rob <at> giardina.us>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Juanma Barranquero <lekktu <at> gmail.com>,
	Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 6799 <at> debbugs.gnu.org
Subject: Re: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Wed, 25 Apr 2012 11:46:46 -0400

[Message part 1 (text/plain, inline)]

Thanks for remembering this patch Drew. I did work with RMS a long way
back but it fell by the wayside in the last phases.

The patch is just elisp and doc, no C. The changes are pretty simple
and contain all the community enhancements added later
(dired-details+).

Basically, it adds some bindings to a few functions that will loop
over the dired file listing lines to add invisibile overlays to the
messiest parts of the lines. Pretty self-contained.

It would have to be re-tested at this point. I've attached the old
ones if it will help decide if you want the feature. I can test some
fresh patches on HEAD in the next few weeks when my biz/personal life
calms a bit.

Regards,
Rob

On Thu, Apr 12, 2012 at 4:05 PM, Drew Adams <drew.adams <at> oracle.com> wrote:
>
> As I have said several times now, ask Rob Giardina.  He made a whole set of
> changes to various Emacs files, including perhaps C code.  I am not aware of
> what changes he made.
>
> Rob has sent mail as recently as 2011/11/29 to emacs-orgmode <at> gnu.org.  His
> address for that was rob <at> giardina.us.  (No, I do not subscribe to that mailing
> list.  But I know how to use Google.)  Please contact Rob.
>
> > > Please contact Rob Giardina.  I believe that he patched the existing
> > > Dired code (and some C code? and some other Lisp code?), doing
> > > everything that was needed.
> >
> > If you want this code included in Emacs, please assemble the patch and
> > post it here.
>
> It is not a question of "if I want".  It was decided by RMS that this should be
> included in Emacs.  Long, long ago.  Rob did the work required for this to
> happen, but no one ever committed it, AFAIK.
>
> What I use, personally, is dired-details.el plus dired-details+.el, and they
> suffice.  But Rob went to the trouble of patching Emacs in various places,
> integrating the features cleanly at a more basic level etc.
>
> I have no idea what Rob's changes were, but if you search the mailing list
> perhaps you can find references to them.  Rob refers to a patch for 2005-07-07
> CVS, here:
> http://comments.gmane.org/gmane.emacs.devel/74172
>
> Here is the last mail from Rob on the subject, AFAIK:
> http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg00215.html
>
> Here is my last mail on the subject, with relevant links:
>
> > From: Drew Adams Sent: Sunday, July 19, 2009 7:34 AM
> > > I discovered dired-details and dired-details+ and found them useful.
> > > Could they be added to emacs?
> > >
> > > http://www.emacswiki.org/emacs/DiredDetails
> >
> > They were supposed to be added. Rob Giardina submitted an
> > Emacs 23 patch two years ago that integrates the functionality
> > of both in a better way even than the separate libraries
> > dired-details[+].el.
> >
> > I don't think any reason was ever given for why the patch
> > wasn't incorporated (committed). RMS asked for comment on
> > the merged code, but no one ever answered his request
> > (on emacs-devel, at least). The last time I ping'ed the
> > list about this was 2008-07 - I never got an answer either.
> >
> > Last ping:
> > http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg01152.html
> >
> > Rob's change log and RMS's call for comment:
> > http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg01187.html
> >
> > Original thread:
> > http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg00226.html
>

[dired-x.el.patch (application/octet-stream, attachment)]

[dired.el.patch (application/octet-stream, attachment)]

[dired.texi.patch (application/octet-stream, attachment)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: rob <at> giardina.us, rob.giardina <at> gmail.com, 6799 <at> debbugs.gnu.org,
	joakim <at> verona.se
Subject: Re: dired-details[+].el
Date: Wed, 16 May 2012 18:57:31 -0400

>> A technical reason is lack of copyright paperwork.  I'm not 
>> sure if the email I used in the Cc is valid.  If so, Rob,
>> could you contact me to get this copyright business out of the way?
> Hopefully Rob will answer, but I'm pretty sure he already took care of
> the copyright stuff.

At least I can't find him in the FSF's copyright-list.
Sometimes some entries are missing, so if he says he did sign the
papers, I'll ask the copyright clerk to investigate.

> The most recent reply we have from Rob is from
> this address: rob.giardina <at> gmail.com.

Thanks, I added it to the Cc.

> This is that reply:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6799#23.  Note too that
> he included the latest patches in that message.

Thanks.  Moved this thread to the bug.  The patch there looks very
similar to the one I just reviewed.

>> > +    (define-key map "(" 'dired-details-hide)
>> > +    (define-key map ")" 'dired-details-show)
>> > +    (define-key map ";" 'dired-details-toggle)
>> I'd rather place the bindings on a "dired-details" prefix.
> FWIW, I think we need only one keybinding, for just `dired-details-toggle'.

Actually, I think you're right.

>> > +(defcustom dired-details-hide-link-targets t
>> > +  "*Hide symbolic link target paths."
>> > +  :group 'dired-details
>> > +  :type 'boolean)
>> FWIW I find something like (setq truncate-lines t) to be better.
> Not the same thing.  And not better, IMO - less specific.  Hiding symlink
> targets should apply regardless of line length.  Truncating is only about
> handling long lines.  (But I don't really care about this matter.)

Not the same thing indeed, but in many cases, truncation makes
hiding unnecessary.

>> Since line truncation is the default in tabulated-list-mode, maybe we
>> should also make it the default in dired.
> Egads, no, please.
> No, I won't fight over the default value, but I think truncated lines as the
> default is nearly always a bad idea.

I find truncated lines to be the only good choice for text displayed in
columns, where wrapping breaks the clean visual display.
I don't claim it's perfect, but I think it's a generally better default.

> An extra reason is that some users will have no clue what's going on
> and how to show the missing info.

If that's really a problem, it's a general one that needs to be fixed in
general (e.g. by adding horizontal scroll bars and/or supporting
horizontal scrolling via two-finger gestures or things like that).

> Truncating lines is nearly a barbarism that should go the way of the
> dinosaurs.  No, just kidding.  It can be handy if you know how to
> toggle it, but truncation should not be the default (anywhere), IMHO.

Obviously a matter of taste.

> Again though, not very important.

>> > +(defun dired-details-toggle (&optional arg default-too)
>> > +  "Toggle visibility of dired details.
>> > +With positive prefix argument ARG hide the details, with negative
>> > +show them."
>> > +  (interactive "P")
>> > +  (let ((hide (if (null arg)
>> > +                  (not (eq 'hidden dired-details-state))
>> > +                (> (prefix-numeric-value arg) 0))))
>> > +    (if default-too
>> > +        (setq dired-details-initially-hide hide))
>> > +    (if hide (dired-details-hide)
>> > +      (dired-details-show))))
>> Use define-minor-mode.
> I think I disagree, and I feel more strongly about this point.
> The current behavior is what I like, and I'm not sure how using
> a minor mode would provide it.  This is the behavior:
>  Toggling affects only the current Dired buffer and subsequently
>  created Dired buffers.  It does not affect other existing Dired buffers.

I don't see why using define-minor-mode would prevent this behavior.

> A local minor mode would affect only the current Dired buffer and not
> subsequently created ones.  A global minor mode would affect all Dired
> buffers at the same time.

A local minor mode can change global defaults as well.

>> > +(defun dired-details-hide-overlay (o)
>> > +  (overlay-put o 'invisible t)
>> > +  (overlay-put o 'before-string dired-details-hidden-string))
>> Why use dired-details-hidden-string rather than just using the
>> traditional ellipsis with buffer-invisibility-spec?
> The first thing I did when getting dired-details.el was change the
> string to "", and I've never looked back.  In my use of it, hiding the
> details means showing nothing in their place.  And in the commentary
> of dired-details+.el I recommended that others do the same.

You could still get this result by changing buffer-invisibility-spec, so
it's not an objection.


        Stefan

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: rob <at> giardina.us, rob.giardina <at> gmail.com, 6799 <at> debbugs.gnu.org,
	joakim <at> verona.se
Subject: RE: dired-details[+].el
Date: Wed, 16 May 2012 16:52:43 -0700

> I don't see why using define-minor-mode would prevent this behavior.

How, for example?  Or I can wait and see. ;-)  My main point here was to get the
behavior, not how to get it.  My limited use of `define-minor-mode' didn't
suggest to me how to do it.

> > A local minor mode would affect only the current Dired 
> > buffer and not subsequently created ones.  A global minor mode would 
> > affect all Dired buffers at the same time.
> 
> A local minor mode can change global defaults as well.

Ah, yes.  So we can have the same behavior with `define-minor-mode' - great.

> >> Why use dired-details-hidden-string rather than just using the
> >> traditional ellipsis with buffer-invisibility-spec?
> >
> > The first thing I did when getting dired-details.el was change the
> > string to "", and I've never looked back.  In my use of it, 
> > hiding the details means showing nothing in their place.  And in
> > the commentary of dired-details+.el I recommended that others do the same.
> 
> You could still get this result by changing 
> buffer-invisibility-spec, so it's not an objection.

To me, it's a cop-out to tell users to go fiddle with
`buffer-invisibility-spec'.

To me, the most Lisp-averse Emacs newbie should be able to easily get rid of the
useless `...'.  S?he (including I) should not have to go look up
`buffer-invisibility-spec' in the Elisp manual.  Or even have to scan a Dired
mode doc string to find something about how to use `buffer-invisibility-spec' to
get rid of it...

But maybe I'm misunderstanding your suggestion.

I say "useless" because I see no good reason why we should _ever_ show `...' for
this feature.  `...' indicates a particular position where something is elided,
but the same columns are elided from each row.  The position indicates nothing -
the column of repeated ellipses just constitutes noise and wastes space.

To me, it's just as clear, and simpler, for the toggle to simply remove those
columns, without replacing them by `...'.

To me.

Try it - and see if it isn't clear enough, and cleaner & simpler for users.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Rob Giardina'" <rob <at> giardina.us>
Cc: 'Juanma Barranquero' <lekktu <at> gmail.com>,
	'Lars Magne Ingebrigtsen' <larsi <at> gnus.org>, 6799 <at> debbugs.gnu.org,
	'Stefan Monnier' <monnier <at> iro.umontreal.ca>
Subject: RE: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Sat, 21 Jul 2012 13:12:40 -0700

ping.

Still hoping, after all these years...

The replies from Emacs Dev have varied from gee-we-don't-know-how-to-find-Rob
(even though he has replied to this bug list and his email address works) to
gee-we-don't-know-whether-he-has-signed-papers (even though he has replied here
indicating that he has).

What's the problem?

(Again, this is for Emacs, not for me.  I am content with loading
dired-details(+).el for my own use.  But it's a shame that Emacs users do not
have this great feature as part of Emacs.)


> From: rob.giardina <at> gmail.com [mailto:rob.giardina <at> gmail.com] 
> Sent: Wednesday, April 25, 2012 8:47 AM
> 
> Thanks for remembering this patch Drew. I did work with RMS a long way
> back but it fell by the wayside in the last phases.
> 
> The patch is just elisp and doc, no C. The changes are pretty simple
> and contain all the community enhancements added later
> (dired-details+).
> 
> Basically, it adds some bindings to a few functions that will loop
> over the dired file listing lines to add invisibile overlays to the
> messiest parts of the lines. Pretty self-contained.
> 
> It would have to be re-tested at this point. I've attached the old
> ones if it will help decide if you want the feature. I can test some
> fresh patches on HEAD in the next few weeks when my biz/personal life
> calms a bit.
> 
> Regards,
> Rob
> 
> On Thu, Apr 12, 2012 at 4:05 PM, Drew Adams 
> <drew.adams <at> oracle.com> wrote:
> >
> > As I have said several times now, ask Rob Giardina.  He 
> > made a whole set of changes to various Emacs files,
> > including perhaps C code.  I am not aware of
> > what changes he made.
> >
> > Rob has sent mail as recently as 2011/11/29 to 
> > emacs-orgmode <at> gnu.org.  His address for that was
> > rob <at> giardina.us.  (No, I do not subscribe to that mailing
> > list.  But I know how to use Google.)  Please contact Rob.
> >
> > > > Please contact Rob Giardina.  I believe that he patched 
> > > > the existing
> > > > Dired code (and some C code? and some other Lisp code?), doing
> > > > everything that was needed.
> > >
> > > If you want this code included in Emacs, please assemble 
> > > the patch and post it here.
> >
> > It is not a question of "if I want".  It was decided by RMS 
> > that this should be included in Emacs.  Long, long ago.
> > Rob did the work required for this to
> > happen, but no one ever committed it, AFAIK.
> >
> > What I use, personally, is dired-details.el plus 
> > dired-details+.el, and they
> > suffice.  But Rob went to the trouble of patching Emacs in 
> > various places,
> > integrating the features cleanly at a more basic level etc.
> >
> > I have no idea what Rob's changes were, but if you search 
> > the mailing list
> > perhaps you can find references to them.  Rob refers to a 
> > patch for 2005-07-07
> > CVS, here:
> > http://comments.gmane.org/gmane.emacs.devel/74172
> >
> > Here is the last mail from Rob on the subject, AFAIK:
> > http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg00215.html
> >
> > Here is my last mail on the subject, with relevant links:
> >
> > > From: Drew Adams Sent: Sunday, July 19, 2009 7:34 AM
> > > > I discovered dired-details and dired-details+ and found 
> > > > them useful.
> > > > Could they be added to emacs?
> > > >
> > > > http://www.emacswiki.org/emacs/DiredDetails
> > >
> > > They were supposed to be added. Rob Giardina submitted an
> > > Emacs 23 patch two years ago that integrates the functionality
> > > of both in a better way even than the separate libraries
> > > dired-details[+].el.
> > >
> > > I don't think any reason was ever given for why the patch
> > > wasn't incorporated (committed). RMS asked for comment on
> > > the merged code, but no one ever answered his request
> > > (on emacs-devel, at least). The last time I ping'ed the
> > > list about this was 2008-07 - I never got an answer either.
> > >
> > > Last ping:
> > > 
> http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg01152.html
> > >
> > > Rob's change log and RMS's call for comment:
> > > 
> http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg01187.html
> > >
> > > Original thread:
> > > 
> http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg00226.html

Message #35 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
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,
	Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Sat, 15 Dec 2012 21:15:16 +0000 (GMT)

[Message part 1 (text/plain, inline)]

"Drew Adams" <drew.adams <at> oracle.com> writes:
> ping.
>
> Still hoping, after all these years...
>
> The replies from Emacs Dev have varied from
> gee-we-don't-know-how-to-find-Rob (even though he has replied to this
> bug list and his email address works) to
> gee-we-don't-know-whether-he-has-signed-papers (even though he has
> replied here indicating that he has).
>
> What's the problem?
>
> (Again, this is for Emacs, not for me.  I am content with loading
> dired-details(+).el for my own use.  But it's a shame that Emacs users
> do not have this great feature as part of Emacs.)

Here is my attempt.

[my-dired-hide-details-mode.el (application/emacs-lisp, attachment)]

[Message part 3 (text/plain, inline)]

Usage:

    (progn
      (require 'cl-lib)
      (require 'dired)
      (require 'my-dired-hide-details-mode))

Press `(' in any dired buffer to toggle details.

Other than dired-details by Rob this implementation does not use
overlays but text properties which is a lot faster.

I just wrote this a few minutes ago but the code seems to work fine with
dired, wdired and find-dired.

If there is interest, I can polish the code, add documentation and
customisation options and come up with a full patch for the trunk.  I
think, due to the way my-dired-hide-details-mode is designed, it would
be best to add the code directly to dired.el - that is

    add new code to dired-insert-set-properties
    add new minor mode dired-hide-details-mode
    bind dired-hide-details-mode in dired-mode-map

It would be necessary to fix a few bugs find-dired as well.  Nothing
fancy, though.

WDYT?

        Christopher

Message #38 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
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,
	Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Sat, 15 Dec 2012 22:17:33 +0000 (GMT)

[Message part 1 (text/plain, inline)]

Christopher Schmidt <christopher <at> ch.ristopher.com> writes:
> Here is my attempt.

Here is a better one.

[my-dired-hide-details-mode.el (application/emacs-lisp, attachment)]

[Message part 3 (text/plain, inline)]

        Christopher

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: bug-gnu-emacs <at> gnu.org
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,
	Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Sun, 16 Dec 2012 17:31:39 -0500

>   (save-restriction
>     (widen)

Please add a comment explaining why widening should be used here.

> 		 do (let ((buffer-read-only))
> 		      (put-text-property (point) end
> 					 'invisible my-dired-hide-details-mode))

Better bind inhibit-read-only to t.  Or better yet, use
with-silent-modifications (but move it outside the loop).

Also, rather than set the invisible property to nil or t, better set it
to another symbol (e.g. `dired-details'), whose meaning is then
controlled by add-to-invisibility-spec.

> (defadvice dired-insert-set-properties
>   (after my-add-hide-props (beg end) activate)

Obviously, this would have to be turned into a patch, and since it's not
small, it would need to be moved to its own function (which would be
called from dired-insert-set-properties).

> (defadvice find-dired (after my-fix-move-process-mark-to-arg activate)
>   (move-marker (process-mark (get-buffer-process (current-buffer)))
> 	       (save-excursion
> 		 (goto-char (point-min))
> 		 (forward-line 1)
> 		 (point))))

How is that related to dired-details?


        Stefan

Message #44 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
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,
	Stefan Monnier <monnier <at> iro.umontreal.ca>,
	Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Mon, 17 Dec 2012 13:24:31 +0000 (GMT)

[Message part 1 (text/plain, inline)]

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

Hi Stefan,

thanks for your input.  Here is a preliminary patch for the trunk.

[dired-dired-hide-details-mode.diff (text/x-diff, inline)]

--- lisp/dired.el
+++ lisp/dired.el
@@ -230,6 +230,12 @@
   :version "22.1"
   :group 'dired)
 
+(defcustom dired-hide-details-hide-symlink-targets t
+  "If non-nil, `dired-hide-details-mode' hides symbolic link targets."
+  :type 'boolean
+  :version "24.4"
+  :group 'dired)
+
 ;; Internal variables
 
 (defvar dired-marker-char ?*		; the answer is 42
@@ -1222,15 +1228,22 @@
     (goto-char beg)
     (while (< (point) end)
       (condition-case nil
-	  (if (dired-move-to-filename)
-	      (add-text-properties
-	       (point)
-	       (save-excursion
-		 (dired-move-to-end-of-filename)
-		 (point))
-	       '(mouse-face highlight
-		 dired-filename t
-		 help-echo "mouse-2: visit this file in other window")))
+	  (when (dired-move-to-filename)
+	    (put-text-property (+ (line-beginning-position) 2) (point)
+			       'invisible 'dired-detail)
+	    (add-text-properties
+	     (point)
+	     (progn
+	       (dired-move-to-end-of-filename)
+	       (point))
+	     '(mouse-face
+	       highlight
+	       dired-filename t
+	       help-echo "mouse-2: visit this file in other window"))
+	    (when (and dired-hide-details-hide-symlink-targets
+		       (< (+ (point) 4) (line-end-position)))
+	      (put-text-property (+ (point) 4) (line-end-position)
+				 'invisible 'dired-detail)))
 	(error nil))
       (forward-line 1))))
 
@@ -1494,6 +1507,7 @@
     ;; hiding
     (define-key map "$" 'dired-hide-subdir)
     (define-key map "\M-$" 'dired-hide-all)
+    (define-key map "(" 'dired-hide-details-mode)
     ;; isearch
     (define-key map (kbd "M-s a C-s")   'dired-do-isearch)
     (define-key map (kbd "M-s a M-C-s") 'dired-do-isearch-regexp)
@@ -1584,6 +1598,14 @@
       '(menu-item "Toggle Image Thumbnails in This Buffer" image-dired-dired-toggle-marked-thumbs
                   :help "Add or remove image thumbnails in front of marked file names"))
 
+    (define-key map [menu-bar immediate unhide-details]
+      '(menu-item "UnHide Details" dired-hide-details-mode
+		  :help "Unhide details in buffer"
+		  :visible dired-hide-details-mode))
+    (define-key map [menu-bar immediate hide-details]
+      '(menu-item "Hide Details" dired-hide-details-mode
+		  :help "Hide details in buffer"
+		  :visible (not dired-hide-details-mode)))
     (define-key map [menu-bar immediate revert-buffer]
       '(menu-item "Refresh" revert-buffer
 		  :help "Update contents of shown directories"))
@@ -1912,6 +1934,9 @@
 	selective-display t		; for subdirectory hiding
 	mode-line-buffer-identification
 	(propertized-buffer-identification "%17b"))
+  ;; ignore dired-detail value of invisible text property by default
+  (when (eq buffer-invisibility-spec t)
+    (setq buffer-invisibility-spec (list t)))
   (set (make-local-variable 'revert-buffer-function)
        (function dired-revert))
   (set (make-local-variable 'buffer-stale-function)
@@ -2228,6 +2253,20 @@
       (substring file (match-end 0))
     file))
 
+;;; Minor mode for hiding details
+;;;###autoload
+(define-minor-mode dired-hide-details-mode
+  "Hide details in `dired-mode'."
+  :group 'dired
+  (unless (derived-mode-p 'dired-mode)
+    (error "Not a Dired buffer"))
+  (funcall (if dired-hide-details-mode
+	       'add-to-invisibility-spec
+	     'remove-from-invisibility-spec)
+	   'dired-detail))
+
+(put 'dired-hide-details-mode 'safe-local-variable 'booleanp)
+
 ;;; Functions for finding the file name in a dired buffer line.
 
 (defvar dired-permission-flags-regexp

[Message part 3 (text/plain, inline)]

I would love to hear your feedback.

>>   (save-restriction
>>     (widen)
>
> Please add a comment explaining why widening should be used here.

Widening is not necessary any more.

>>               do (let ((buffer-read-only))
>>                    (put-text-property (point) end
>>                                       'invisible my-dired-hide-details-mode))
>
> Better bind inhibit-read-only to t.  Or better yet, use
> with-silent-modifications (but move it outside the loop).
>
> Also, rather than set the invisible property to nil or t, better set
> it to another symbol (e.g. `dired-details'), whose meaning is then
> controlled by add-to-invisibility-spec.

Right.  Obviously this simplifies the implementation.

>> (defadvice dired-insert-set-properties
>>   (after my-add-hide-props (beg end) activate)
>
> Obviously, this would have to be turned into a patch, and since it's
> not small, it would need to be moved to its own function (which would
> be called from dired-insert-set-properties).

Check the new patch.  Altogether 7 new lines are added to
dired-insert-set-properties.

>> (defadvice find-dired (after my-fix-move-process-mark-to-arg activate)
>>   (move-marker (process-mark (get-buffer-process (current-buffer)))
>>             (save-excursion
>>               (goto-char (point-min))
>>               (forward-line 1)
>>               (point))))
>
> How is that related to dired-details?

This is not necessary any more.

My former implementation hid every non-file line that
dired-insert-set-properties is called upon.  Vanilla dired calls
dired-insert-set-properties on every line except the directory
headerline so my-dired-hide-details-mode hid the information line.

    total used in directory RMS available VI

Initially find-dired inserts the directory headerline, newline and the
find arguments and set the process mark is set to 1.

In the process filter of find find-dired evals

    (dired-insert-set-properties (process-mark proc)
                                 (1+ (point)))
    (move-marker (process-mark proc) (1+ (point)))

with (point) being right before the end of the last complete line added
by find.

That is dired-insert-set-properties is called on the first and second
line so my former code added the invisible property to the directory
headerline as well.  This is why I added that advice - just move the
process mark to the second line so dired-insert-set-properties is not
called on the directory headerline.

I removed the hiding of non-file lines.  Hiding full lines via text
properties might cause confusion when it comes to interactive line
movement.  There are no changed to find-dired.el now.

        Christopher

Message #47 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: Sun, 10 Feb 2013 15:02:21 +0000 (GMT)

[Message part 1 (text/plain, inline)]

Christopher Schmidt <christopher <at> ch.ristopher.com> writes:
> Here is a preliminary patch for the trunk.

Here is the final patch.  Drew Adams and Michael Heerdegen tested it and
did not find any problems.

[Message part 2 (text/x-diff, inline)]

--- lisp/ChangeLog
+++ lisp/ChangeLog
@@ -1,5 +1,25 @@
 2013-02-10  Christopher Schmidt  <christopher <at> ch.ristopher.com>
 
+	* locate.el (locate-mode-map): Disable dired-hide-details-mode.
+
+	* find-dired.el (find-dired): Call dired-insert-set-properties on
+	initial information line.  Set process mark on end of buffer.
+	(find-dired-sentinel): Call dired-insert-set-properties on
+	summary.
+
+	* dired.el (dired-hide-details-hide-symlink-targets)
+	(dired-hide-details-hide-information-lines): New options.
+	(dired-insert-directory): Set properties after final treatment of
+	output.
+	(dired-insert-set-properties): Set dired-hide-details-*
+	properties.
+	(dired-mode-map): Bind dired-hide-details-mode.
+	(dired-mode): Set buffer-invisibility-spec to a list.
+	(dired-next-line): Skip hidden lines.
+	(dired-previous-line): Use dired-next-line.
+	(dired-hide-details-mode): New minor mode.
+	(dired-hide-details-update-invisibility-spec): New function.
+
 	* minibuf-eldef.el (minibuffer-default--in-prompt-regexps): Handle
 	"foo (bar, default: xxx): " prompts.
 
--- lisp/dired.el
+++ lisp/dired.el
@@ -230,6 +230,18 @@
   :version "22.1"
   :group 'dired)
 
+(defcustom dired-hide-details-hide-symlink-targets t
+  "If non-nil, `dired-hide-details-mode' hides symbolic link targets."
+  :type 'boolean
+  :version "24.4"
+  :group 'dired)
+
+(defcustom dired-hide-details-hide-information-lines t
+  "Non-nil means hide lines other than header and file/dir lines."
+  :type 'boolean
+  :version "24.4"
+  :group 'dired)
+
 ;; Internal variables
 
 (defvar dired-marker-char ?*		; the answer is 42
@@ -1196,7 +1208,6 @@
       ;; Note: adjust dired-build-subdir-alist if you change this.
       (setq dir (replace-regexp-in-string "\\\\" "\\\\" dir nil t)
             dir (replace-regexp-in-string "\n" "\\n" dir nil t)))
-    (dired-insert-set-properties opoint (point))
     ;; If we used --dired and it worked, the lines are already indented.
     ;; Otherwise, indent them.
     (unless (save-excursion
@@ -1205,18 +1216,21 @@
       (let ((indent-tabs-mode nil))
 	(indent-rigidly opoint (point) 2)))
     ;; Insert text at the beginning to standardize things.
-    (save-excursion
-      (goto-char opoint)
-      (if (and (or hdr wildcard)
-               (not (and (looking-at "^  \\(.*\\):$")
-                         (file-name-absolute-p (match-string 1)))))
+    (let ((content-point opoint))
+      (save-excursion
+	(goto-char opoint)
+	(when (and (or hdr wildcard)
+		   (not (and (looking-at "^  \\(.*\\):$")
+			     (file-name-absolute-p (match-string 1)))))
 	  ;; Note that dired-build-subdir-alist will replace the name
 	  ;; by its expansion, so it does not matter whether what we insert
 	  ;; here is fully expanded, but it should be absolute.
-	  (insert "  " (directory-file-name (file-name-directory dir)) ":\n"))
-      (when wildcard
-	;; Insert "wildcard" line where "total" line would be for a full dir.
-	(insert "  wildcard " (file-name-nondirectory dir) "\n")))))
+	  (insert "  " (directory-file-name (file-name-directory dir)) ":\n")
+	  (setq content-point (point)))
+	(when wildcard
+	  ;; Insert "wildcard" line where "total" line would be for a full dir.
+	  (insert "  wildcard " (file-name-nondirectory dir) "\n")))
+      (dired-insert-set-properties content-point (point)))))
 
 (defun dired-insert-set-properties (beg end)
   "Add various text properties to the lines in the region."
@@ -1224,15 +1238,24 @@
     (goto-char beg)
     (while (< (point) end)
       (condition-case nil
-	  (if (dired-move-to-filename)
-	      (add-text-properties
-	       (point)
-	       (save-excursion
-		 (dired-move-to-end-of-filename)
-		 (point))
-	       '(mouse-face highlight
-		 dired-filename t
-		 help-echo "mouse-2: visit this file in other window")))
+	  (if (not (dired-move-to-filename))
+	      (put-text-property (line-beginning-position)
+				 (1+ (line-end-position))
+				 'invisible 'dired-hide-details-information)
+	    (put-text-property (+ (line-beginning-position) 1) (1- (point))
+			       'invisible 'dired-hide-details-detail)
+	    (add-text-properties
+	     (point)
+	     (progn
+	       (dired-move-to-end-of-filename)
+	       (point))
+	     '(mouse-face
+	       highlight
+	       dired-filename t
+	       help-echo "mouse-2: visit this file in other window"))
+	    (when (< (+ (point) 4) (line-end-position))
+	      (put-text-property (+ (point) 4) (line-end-position)
+				 'invisible 'dired-hide-details-link)))
 	(error nil))
       (forward-line 1))))
 
@@ -1496,6 +1519,7 @@
     ;; hiding
     (define-key map "$" 'dired-hide-subdir)
     (define-key map "\M-$" 'dired-hide-all)
+    (define-key map "(" 'dired-hide-details-mode)
     ;; isearch
     (define-key map (kbd "M-s a C-s")   'dired-do-isearch)
     (define-key map (kbd "M-s a M-C-s") 'dired-do-isearch-regexp)
@@ -1586,6 +1610,14 @@
       '(menu-item "Toggle Image Thumbnails in This Buffer" image-dired-dired-toggle-marked-thumbs
                   :help "Add or remove image thumbnails in front of marked file names"))
 
+    (define-key map [menu-bar immediate unhide-details]
+      '(menu-item "UnHide Details" dired-hide-details-mode
+		  :help "Unhide details in buffer"
+		  :visible dired-hide-details-mode))
+    (define-key map [menu-bar immediate hide-details]
+      '(menu-item "Hide Details" dired-hide-details-mode
+		  :help "Hide details in buffer"
+		  :visible (not dired-hide-details-mode)))
     (define-key map [menu-bar immediate revert-buffer]
       '(menu-item "Refresh" revert-buffer
 		  :help "Update contents of shown directories"))
@@ -1914,6 +1946,9 @@
 	selective-display t		; for subdirectory hiding
 	mode-line-buffer-identification
 	(propertized-buffer-identification "%17b"))
+  ;; ignore dired-hide-details-* value of invisible text property by default
+  (when (eq buffer-invisibility-spec t)
+    (setq buffer-invisibility-spec (list t)))
   (set (make-local-variable 'revert-buffer-function)
        (function dired-revert))
   (set (make-local-variable 'buffer-stale-function)
@@ -1978,15 +2013,32 @@
   "Move down lines then position at filename.
 Optional prefix ARG says how many lines to move; default is one line."
   (interactive "p")
+  (unless arg
+    (setq arg 1))
   (forward-line arg)
+  (while (and (progn
+		(while (and (< arg 0)
+			    (bolp)
+			    (/= (1+ (point)) (point-max))
+			    (eq (get-text-property (1+ (point)) 'invisible)
+				'dired-hide-details-information))
+		  (forward-char -1))
+		(invisible-p (point)))
+	      (let ((p (funcall (if (> arg 0)
+				    'next-single-property-change
+				  'previous-single-property-change)
+				(point)
+				'invisible)))
+		(when p
+		  (goto-char p)
+		  t))))
   (dired-move-to-filename))
 
-(defun dired-previous-line (arg)
+(defun dired-previous-linel (arg)
   "Move up lines then position at filename.
 Optional prefix ARG says how many lines to move; default is one line."
   (interactive "p")
-  (forward-line (- arg))
-  (dired-move-to-filename))
+  (dired-next-line (- (or arg 1))))
 
 (defun dired-next-dirline (arg &optional opoint)
   "Goto ARG'th next directory file line."
@@ -2230,6 +2282,42 @@
       (substring file (match-end 0))
     file))
 
+;;; Minor mode for hiding details
+;;;###autoload
+(define-minor-mode dired-hide-details-mode
+  "Hide details in `dired-mode'."
+  :group 'dired
+  (if (derived-mode-p 'locate-mode)
+      (setq dired-hide-details-mode nil)
+    (unless (derived-mode-p 'dired-mode)
+      (error "Not a Dired buffer"))
+    (dired-hide-details-update-invisibility-spec)
+    (if dired-hide-details-mode
+	(add-hook 'wdired-mode-hook
+		  'dired-hide-details-update-invisibility-spec
+		  nil
+		  t)
+      (remove-hook 'wdired-mode-hook
+		   'dired-hide-details-update-invisibility-spec
+		   t))))
+
+(defun dired-hide-details-update-invisibility-spec ()
+  (funcall (if dired-hide-details-mode
+	       'add-to-invisibility-spec
+	     'remove-from-invisibility-spec)
+	   'dired-hide-details-detail)
+  (funcall (if (and dired-hide-details-mode
+		    dired-hide-details-hide-information-lines)
+	       'add-to-invisibility-spec
+	     'remove-from-invisibility-spec)
+	   'dired-hide-details-information)
+  (funcall (if (and dired-hide-details-mode
+		    dired-hide-details-hide-symlink-targets
+		    (not (derived-mode-p 'wdired-mode)))
+	       'add-to-invisibility-spec
+	     'remove-from-invisibility-spec)
+	   'dired-hide-details-link))
+
 ;;; Functions for finding the file name in a dired buffer line.
 
 (defvar dired-permission-flags-regexp
--- lisp/find-dired.el
+++ lisp/find-dired.el
@@ -210,13 +210,15 @@
     (insert "  " dir ":\n")
     ;; Make second line a ``find'' line in analogy to the ``total'' or
     ;; ``wildcard'' line.
-    (insert "  " args "\n")
+    (let ((point (point)))
+      (insert "  " args "\n")
+      (dired-insert-set-properties point (point)))
     (setq buffer-read-only t)
     (let ((proc (get-buffer-process (current-buffer))))
       (set-process-filter proc (function find-dired-filter))
       (set-process-sentinel proc (function find-dired-sentinel))
       ;; Initialize the process marker; it is used by the filter.
-      (move-marker (process-mark proc) 1 (current-buffer)))
+      (move-marker (process-mark proc) (point) (current-buffer)))
     (setq mode-line-process '(":%s"))))
 
 (defun kill-find ()
@@ -337,10 +339,11 @@
 	  (let ((buffer-read-only nil))
 	    (save-excursion
 	      (goto-char (point-max))
-	      (insert "\n  find " state)
-	      (forward-char -1)		;Back up before \n at end of STATE.
-	      (insert " at " (substring (current-time-string) 0 19))
-	      (forward-char 1)
+	      (let ((point (point)))
+		(insert "\n  find " state)
+		(forward-char -1)		;Back up before \n at end of STATE.
+		(insert " at " (substring (current-time-string) 0 19))
+		(dired-insert-set-properties point (point)))
 	      (setq mode-line-process
 		    (concat ":"
 			    (symbol-name (process-status proc))))
--- lisp/locate.el
+++ lisp/locate.el
@@ -382,6 +382,7 @@
     (define-key map "l"       'locate-do-redisplay)
     (define-key map "U"       'dired-unmark-all-files)
     (define-key map "V"       'locate-find-directory)
+    (define-key map [remap dired-hide-details-mode] nil)
     map)
   "Local keymap for Locate mode buffers.")
 

[Message part 3 (text/plain, inline)]

Should the key bindings and definition of dired-hide-details-mode go
into dired-x.el?

        Christopher

Message #50 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: Sun, 10 Feb 2013 15:08:20 +0000 (GMT)

Christopher Schmidt <christopher <at> ch.ristopher.com> writes:
> -(defun dired-previous-line (arg)
> +(defun dired-previous-linel (arg)

That's a typo.

        Christopher

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Sun, 10 Feb 2013 22:37:53 -0500

> Here is the final patch.  Drew Adams and Michael Heerdegen tested it and
> did not find any problems.

Thanks.  A few nitpicks and comments below.

> +  ;; ignore dired-hide-details-* value of invisible text property by default
> +  (when (eq buffer-invisibility-spec t)
> +    (setq buffer-invisibility-spec (list t)))

Please capitalize and punctuate your comments.

>    (forward-line arg)
> +  (while (and (progn
> +		(while (and (< arg 0)
> +			    (bolp)
> +			    (/= (1+ (point)) (point-max))
> +			    (eq (get-text-property (1+ (point)) 'invisible)
> +				'dired-hide-details-information))
> +		  (forward-char -1))
> +		(invisible-p (point)))
> +	      (let ((p (funcall (if (> arg 0)
> +				    'next-single-property-change
> +				  'previous-single-property-change)
> +				(point)
> +				'invisible)))
> +		(when p
> +		  (goto-char p)
> +		  t))))
>    (dired-move-to-filename))

What is this for?

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


        Stefan

Message #56 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 08:19:52 +0000 (GMT)

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>    (forward-line arg)
>> +  (while (and (progn
>> +		(while (and (< arg 0)
>> +			    (bolp)
>> +			    (/= (1+ (point)) (point-max))
>> +			    (eq (get-text-property (1+ (point)) 'invisible)
>> +				'dired-hide-details-information))
>> +		  (forward-char -1))
>> +		(invisible-p (point)))
>> +	      (let ((p (funcall (if (> arg 0)
>> +				    'next-single-property-change
>> +				  'previous-single-property-change)
>> +				(point)
>> +				'invisible)))
>> +		(when p
>> +		  (goto-char p)
>> +		  t))))
>>    (dired-move-to-filename))
>
> What is this for?

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.

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

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.

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.

I am not aware of any other mode that behaves that way.

        Christopher

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
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 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

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

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
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 12:58:30 -0500

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

I'm sorry if I'm maybe a bit dense, but I don't understand what
you're saying.  Please be more specific (and feel free to use
a concrete example from dired-details rather than from your test case).

I especially don't understand because IIUC dired-details only ever hides
parts of a line (i.e. it never hides an LF) and it never hides the
filename itself, so it neither affects what (forward-char arg) should
do nor what (dired-move-to-filename) should do and after those two, the
cursor should be placed in a visible spot, so there's no need to move
the cursor.

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

I have no idea, sorry.

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

Then let's not do anything special for locate-mode.

BTW, I saw another detail in your code that should be improved:

+    (define-key map [menu-bar immediate unhide-details]
+      '(menu-item "UnHide Details" dired-hide-details-mode
+		  :help "Unhide details in buffer"
+		  :visible dired-hide-details-mode))
+    (define-key map [menu-bar immediate hide-details]
+      '(menu-item "Hide Details" dired-hide-details-mode
+		  :help "Hide details in buffer"
+		  :visible (not dired-hide-details-mode)))

this should use a single entry with a toggle box.  Example from the
elisp manual:

          (menu-item "Debug on Error" toggle-debug-on-error
                     :button (:toggle
                              . (and (boundp 'debug-on-error)
                                     debug-on-error)))

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

That sounds right, yes.

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

OK, great.  Then feel free to install at your convenience (with a note
in etc/NEWS as well),


        Stefan

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>, <6799 <at> debbugs.gnu.org>
Subject: RE: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Mon, 11 Feb 2013 10:07:18 -0800

> Please be more specific (and feel free to use
> a concrete example from dired-details rather than from your 
> test case).

Just a nit.  To be fair and to avoid confusion, let's please not refer to these
enhancements using the name `dired-details'.  That name was taken by Rob
Giardina for his library dired-details.el (see the Subject line).

If this enhancement implements `dired-hide-details-mode', then please call it
that, or speak of "dired-hide-details".

Message #71 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 19:52:16 +0000 (GMT)

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> I'm sorry if I'm maybe a bit dense, but I don't understand what you're
> saying.  Please be more specific (and feel free to use a concrete
> example from dired-details rather than from your test case).

I am sorry for not being on point and specific.

> I especially don't understand because IIUC dired-details only ever
> hides parts of a line (i.e. it never hides an LF) and it never hides
> the filename itself, so it neither affects what (forward-char arg)
> nshould do nor what (dired-move-to-filename) should do and after those
> two, the cursor should be placed in a visible spot, so there's no need
> to move the cursor.

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

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.

> OK, great.  Then feel free to install at your convenience (with a note
> in etc/NEWS as well),

Thank you very much.  I am going to do that after I incorporate your
feedback and give the code another round of testing.  Thank you so much
for your feedback and your help.

        Christopher

Message #76 received at 6799-done <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <christopher <at> ch.ristopher.com>
To: 6799-done <at> debbugs.gnu.org
Subject: Re: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Wed, 13 Feb 2013 09:54:01 +0000 (GMT)

Christopher Schmidt <christopher <at> ch.ristopher.com> writes:
> Thank you very much.  I am going to do that after I incorporate your
> feedback and give the code another round of testing.  Thank you so
> much for your feedback and your help.

I applied the patch (r111768).

        Christopher

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: 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

Message #82 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: Fri, 15 Feb 2013 18:44:24 +0000 (GMT)

Stefan Monnier <monnier <at> 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

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

From: Juri Linkov <juri <at> jurta.org>
To: 6799 <at> debbugs.gnu.org
Subject: Re: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Sat, 16 Feb 2013 23:52:12 +0200

Usually I don't do this but when I called in a dired buffer
`M-x text-mode RET' it unexpectedly removed from display all text
except filenames (i.e. made other text invisible).

I wonder should such cases be handled e.g. by disabling
`dired-hide-details-mode' in the hook `after-change-major-mode-hook'?

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Juri Linkov'" <juri <at> jurta.org>, <6799 <at> debbugs.gnu.org>
Subject: RE: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Sat, 16 Feb 2013 14:58:41 -0800

> Usually I don't do this but when I called in a dired buffer
> `M-x text-mode RET' it unexpectedly removed from display all text
> except filenames (i.e. made other text invisible).
> 
> I wonder should such cases be handled e.g. by disabling
> `dired-hide-details-mode' in the hook `after-change-major-mode-hook'?

They should definitely be handled, one way or another.

`dired-hide-details-mode' makes sense only in a mode derived from Dired mode.

Your suggested fix sounds like the right approach in general, but I think
turning off `dired-hide-details-mode' should somehow be done BEFORE changing to
a mode that is not dired-derived, not afterward.

Can you use `change-major-mode-hook' instead, to do this before changing the
mode?  Is it possible at that point to test whether the target mode is
(derived-mode-p dired-mode)?

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

From: Juri Linkov <juri <at> jurta.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 6799 <at> debbugs.gnu.org
Subject: Re: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Sun, 17 Feb 2013 12:05:53 +0200

> Can you use `change-major-mode-hook' instead, to do this before
> changing the mode?  Is it possible at that point to test whether
> the target mode is (derived-mode-p dired-mode)?

Yes, it seems `change-major-mode-hook' is more suitable.
This is what `outline-mode' does to remove invisibility by using:

  (add-hook 'change-major-mode-hook 'show-all nil t)

Message #94 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: Sun, 17 Feb 2013 14:57:02 +0000 (GMT)

Juri Linkov <juri <at> jurta.org> writes:
> Usually I don't do this but when I called in a dired buffer `M-x
> text-mode RET' it unexpectedly removed from display all text except
> filenames (i.e. made other text invisible).

buffer-invisibility-spec is being set back to t.  I.e. all text with a
non-nil invisible text property is hidden.

> I wonder should such cases be handled e.g. by disabling
> `dired-hide-details-mode' in the hook `after-change-major-mode-hook'?

Disabling dired-hide-details-mode just modifies
buffer-invisibility-spec.  This will not change anything.

I guess the invisible text property should be set back to nil.
dired-hide-details-mode will not work from thereon in this buffer.

Is this a real issue?

        Christopher

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

From: Juri Linkov <juri <at> jurta.org>
To: 6799 <at> debbugs.gnu.org
Subject: Re: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Mon, 18 Feb 2013 11:49:02 +0200

> I guess the invisible text property should be set back to nil.
> dired-hide-details-mode will not work from thereon in this buffer.
>
> Is this a real issue?

It's not an issue to me, I just accidentally noticed that effect.
I don't know how likely is that someone does this routinely
that requires adding a function to remove invisible text property
to be called from `change-major-mode-hook'.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Juri Linkov'" <juri <at> jurta.org>, <6799 <at> debbugs.gnu.org>
Subject: RE: bug#6799: 24.0.50; Please add dired-details.el to Emacs [patch]
Date: Mon, 18 Feb 2013 06:38:58 -0800

> > I guess the invisible text property should be set back to nil.
> > dired-hide-details-mode will not work from thereon in this buffer.
> >
> > Is this a real issue?
> 
> It's not an issue to me, I just accidentally noticed that effect.
> I don't know how likely is that someone does this routinely
> that requires adding a function to remove invisible text property
> to be called from `change-major-mode-hook'.

IMO, it is a real issue, of course.  We are breaking a reasonable use of our
editor: to change the mode and do something different with the same text.

Users should be able to change the mode and then act on the text in various ways
- e.g., treating it as just a file listing.

Yes, there is also `list-directory' that could be used for that, but that's not
a reason not to fix this, at least if the fix is straightforward.  Is the fix
onerous or something?

Previous Next

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