bug#42605: 28.0.50; File lines in find-dired buffers not updated

bug#42605: 28.0.50; File lines in find-dired buffers not updated

[Michael Heerdegen]

Hi,

I run M-x find-dired and get a dired buffer.  When I delete any file in
that buffer, the file's line is not removed from the buffer.  This is
sometimes a bit annoying (and not really useful I guess?).  Dunno what
other kinds of dired buffers and file actions are also affected.

One aspect of the issue is that `dired-fun-in-all-buffers' and
`dired-buffers-for-dir', which the former is based on, only consider
dired buffers in the `dired-buffers' variable, which, AFAICT, doesn't
include such "non-standard" dired buffers.  I also dunno whether looking
in the buffer's `dired-subdir-alist' would be sufficient in my case.

OTOH, when I delete a file in a buffer, dired could be smart enough to
guess that the current buffer does include the file.


TIA,

Michael.


In GNU Emacs 28.0.50 (build 159, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
 of 2020-07-29 built on drachen
Repository revision: 4250db4ac5291554182e688e36e42e99ffe6f889
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux bullseye/sid

bug#42605: 28.0.50; File lines in find-dired buffers not updated

[Drew Adams]

Hi Michael,

> I run M-x find-dired and get a dired buffer.  When I delete any file in
> that buffer, the file's line is not removed from the buffer.  This is
> sometimes a bit annoying (and not really useful I guess?).  Dunno what
> other kinds of dired buffers and file actions are also affected.
> 
> One aspect of the issue is that `dired-fun-in-all-buffers' and
> `dired-buffers-for-dir', which the former is based on, only consider
> dired buffers in the `dired-buffers' variable, which, AFAICT, doesn't
> include such "non-standard" dired buffers.  I also dunno whether looking
> in the buffer's `dired-subdir-alist' would be sufficient in my case.
> 
> OTOH, when I delete a file in a buffer, dired could be smart enough to
> guess that the current buffer does include the file.

FWIW, I don't understand the last paragraph.  What do
you mean by "delete a file in a buffer"? Do you mean
somehow delete a file (from disk) from a buffer that
is visiting it?  Or delete it from a Dired buffer?
I'm guessing it's the latter, but in that case Dired
does do that, doesn't it?

For the rest, here's something to maybe consider:

`find-dired' gives you a snapshot of what's on disk
at a given time.  Dired does that too, but for Dired
there's an optional behavior of having its display
auto-revert, to pick up any disk changes when you
revisit the Dired buffer.

Is that what you're requesting for `find-dired' too?
If so, should it be turned on by the same option,
`dired-auto-revert-buffer'?  I can think that someone
might well want a different option for it.

I can also think that someone might sometimes want
the current behavior, i.e., s?he would turn off such
a new option.

For example, you might want to have a buffer with
such a `find-dired' snapshot, as reference/comparison,
as you go through and delete or modify some of the
listed files, i.e., to keep track of what you've done
so far.  (But I guess such tracking would kind of be
available anyway, if you sort the `find-dired' output
by time.)

bug#42605: 28.0.50; File lines in find-dired buffers not updated

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> > OTOH, when I delete a file in a buffer, dired could be smart enough to
> > guess that the current buffer does include the file.
>
> FWIW, I don't understand the last paragraph.  What do
> you mean by "delete a file in a buffer"? Do you mean
> somehow delete a file (from disk) from a buffer that
> is visiting it?  Or delete it from a Dired buffer?
> I'm guessing it's the latter, but in that case Dired
> does do that, doesn't it?

I hit D in the find-dired result buffer.  Dired deletes the file but
it's not removed from the buffer.

> `find-dired' gives you a snapshot of what's on disk
> at a given time.  Dired does that too, but for Dired
> there's an optional behavior of having its display
> auto-revert, to pick up any disk changes when you
> revisit the Dired buffer.
>
> Is that what you're requesting for `find-dired' too?
> If so, should it be turned on by the same option,
> `dired-auto-revert-buffer'?  I can think that someone
> might well want a different option for it.

No, that's not what I want.  That might be very slow, so it's no general
solution.  And also not necessary I think.

Michael.

bug#42605: 28.0.50; File lines in find-dired buffers not updated

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> For example, you might want to have a buffer with
> such a `find-dired' snapshot, as reference/comparison,
> as you go through and delete or modify some of the
> listed files, i.e., to keep track of what you've done
> so far.

I think the canonical answer for that is `virtual-dired'.

Michael.

bug#42605: 28.0.50; File lines in find-dired buffers not updated

[Drew Adams]

> I hit D in the find-dired result buffer.  Dired deletes the file but
> it's not removed from the buffer.

I see.  Yes, that sounds like a bug.  Thx.

bug#42605: 28.0.50; File lines in find-dired buffers not updated

[Matt Huszagh]

> I see.  Yes, that sounds like a bug.  Thx.

I don't think this is just an issue with dired. I've been noticing it
Emacs-wide. The only exception I've found is that using vterm updates
instantly. But `directory-files' etc. present the same issue.

Happy to debug further and provide more info if desired.

Matt

bug#42605: 28.0.50; File lines in find-dired buffers not updated

[Stefan Kangas]

Matt Huszagh <huszaghmatt@gmail.com> writes:

> I don't think this is just an issue with dired. I've been noticing it
> Emacs-wide. The only exception I've found is that using vterm updates
> instantly. But `directory-files' etc. present the same issue.
>
> Happy to debug further and provide more info if desired.

I think we should individually adress any issues you are seeing in
different parts of Emacs.

Could you please open, for each of these issues, new bug reports with a
recipe for how to reproduce the issues, starting from "emacs -Q"?
Please also state what you see and how this is different from what you
would expect to see.

Best regards,
Stefan Kangas