RE: dired-hide-details-mode have no effect suddenly

[Drew Adams <drew.adams@oracle.com>]

> > Then recursively bisect your init file to find the culprit.
> 
> I am sure this is a proper suggestion. It's just that the workflow would
> look something like, comment out half, use Emacs to a point in time when
> I feel the problem should have occurred (but it didn't occur),
> un-comment half of the first commented half plus the first un-commented
> half and repeat using Emacs to a point in time when I feel that the
> problem should have occurred and so on. I mean, it's just a bit tricky
> when the problem is seemingly intermittent. Like now for example, Emacs
> has been running for a couple of days and details hide as expected.
> 
> Could there be some variables to check while it's working as expected
> and then check again when it's not working as expected? Or something
> like that.

`C-h f dired-hide-details TAB' shows you these variables:

dired-hide-details-hide-information-lines
dired-hide-details-hide-symlink-targets
dired-hide-details-mode
dired-hide-details-mode-hook

You might start with the last two, checking in your init
file, `custom-file', or other code you might load.

You can also put (debug-on-entry 'dired-hide-details-mode)
in your init file, to find out what code is calling it.
In the debugger, look at how it gets called, then use `c'
to skip debugging.  Use `M-x cancel-debug-on-entry RET'
to cancel such debugger entry.

But it's probably easier to just grep for `dired-hide-details'
in directories of customization and 3rd-party code you load.