dired cons bug?

dired cons bug?

[Harald Judt]

[-- Attachment #1.1: Type: text/plain, Size: 1132 bytes --]

Hi,

I have a question regarding using dired programmatically in Emacs 28.1. Say I
do the following call to open a dired buffer and insert the files:

(dired (cons "/home/user" '("/home/user/tmp/test/a/a" 
"/home/user/tmp/test/b/b" "/home/user/tmp/test/c/c")))

It works fine, I get a nice listing and can move around like expected, mark
files and try to delete them. Now it gets interesting: Usually after hitting
"x" to execute, then confirming the deletion, the buffer will refresh. But not
in this case, not when I open dired using the cons above. I can revert the
buffer using "g".

Note that when I simply do (dired "/home/user/tmp/test"), then insert the
subdir to show the files and delete them, this is not reproducible. The buffer
will be refreshed immediately after the delete operation completes.

Why? Am I missing something? Is this a (known) bug or expected behaviour? I've
tried with emacs -Q, so it seems to be no configuration problem.

Regards,
Harald

-- 
`Experience is the best teacher.'

PGP Key ID: 4FFFAB21B8580ABD
Fingerprint: E073 6DD8 FF40 9CF2 0665 11D4 4FFF AB21 B858 0ABD

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: dired cons bug?

[Jean Louis]

* Harald Judt <h.judt@gmx.at> [2022-08-11 08:05]:
> Hi,
> 
> I have a question regarding using dired programmatically in Emacs 28.1. Say I
> do the following call to open a dired buffer and insert the files:
> 
> (dired "/home/"(cons "/home/admin" '("/home/user/tmp/test/a/a" "/home/user/tmp/test/b/b" "/home/user/tmp/test/c/c")))

Function is not intended to be use that way.

(dired DIRNAME &optional SWITCHES)

DIRNAME must be directory name. Not cons and some files inside.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: dired cons bug?

[Eli Zaretskii]

> Date: Thu, 11 Aug 2022 08:55:40 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> * Harald Judt <h.judt@gmx.at> [2022-08-11 08:05]:
> > Hi,
> > 
> > I have a question regarding using dired programmatically in Emacs 28.1. Say I
> > do the following call to open a dired buffer and insert the files:
> > 
> > (dired "/home/"(cons "/home/admin" '("/home/user/tmp/test/a/a" "/home/user/tmp/test/b/b" "/home/user/tmp/test/c/c")))
> 
> Function is not intended to be use that way.
> 
> (dired DIRNAME &optional SWITCHES)
> 
> DIRNAME must be directory name. Not cons and some files inside.

Did you consult the doc string before writing the above?  It says:

  If DIRNAME is a string, Dired displays a list of files in DIRNAME (which
  may also have shell wildcards appended to select certain files).

  If DIRNAME is a cons, its first element is taken as the directory name
  and the rest as an explicit list of files to make directory entries for.
  In this case, SWITCHES are applied to each of the files separately, and
  therefore switches that control the order of the files in the produced
  listing have no effect.

So yes, passing a cons as an argument _is_ supported.

To the OP: please report this as a bug using report-emacs-bug, so that
we could fix it.

Re: dired cons bug?

[Harald Judt]

[-- Attachment #1.1: Type: text/plain, Size: 1780 bytes --]

Am 11.08.22 um 07:55 schrieb Jean Louis:
> * Harald Judt <h.judt@gmx.at> [2022-08-11 08:05]:
>> Hi,
>>
>> I have a question regarding using dired programmatically in Emacs 28.1. Say I
>> do the following call to open a dired buffer and insert the files:
>>
>> (dired "/home/"(cons "/home/admin" '("/home/user/tmp/test/a/a" "/home/user/tmp/test/b/b" "/home/user/tmp/test/c/c")))
> 
> Function is not intended to be use that way.
> 
> (dired DIRNAME &optional SWITCHES)
> 
> DIRNAME must be directory name. Not cons and some files inside.

Documentation says something different, and why should it work if that was not 
true?

------------------------------------------------------------------------
If DIRNAME is a string, Dired displays a list of files in DIRNAME (which
may also have shell wildcards appended to select certain files).

If DIRNAME is a cons, its first element is taken as the directory name
and the rest as an explicit list of files to make directory entries for.
In this case, SWITCHES are applied to each of the files separately, and
therefore switches that control the order of the files in the produced
listing have no effect.

You can flag files for deletion with d and then
delete them by typing x.
Type h after entering Dired for more info.
------------------------------------------------------------------------

But then it also says this, which I have missed until now:

`If DIRNAME is already in a Dired buffer, that buffer is used without refresh.'

Maybe that has something to do with my problem? How could I get the buffer to 
be used *WITH* refresh?

Regards,
Harald

-- 
`Experience is the best teacher.'

PGP Key ID: 4FFFAB21B8580ABD
Fingerprint: E073 6DD8 FF40 9CF2 0665 11D4 4FFF AB21 B858 0ABD

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: dired cons bug?

[Harald Judt]

[-- Attachment #1.1: Type: text/plain, Size: 1852 bytes --]

Am 10.08.22 um 13:26 schrieb Harald Judt:
> Hi,
> 
> I have a question regarding using dired programmatically in Emacs 28.1. Say I
> do the following call to open a dired buffer and insert the files:
> 
> (dired (cons "/home/user" '("/home/user/tmp/test/a/a" 
> "/home/user/tmp/test/b/b" "/home/user/tmp/test/c/c")))
> 
> It works fine, I get a nice listing and can move around like expected, mark
> files and try to delete them. Now it gets interesting: Usually after hitting
> "x" to execute, then confirming the deletion, the buffer will refresh. But not
> in this case, not when I open dired using the cons above. I can revert the
> buffer using "g".
> 
> Note that when I simply do (dired "/home/user/tmp/test"), then insert the
> subdir to show the files and delete them, this is not reproducible. The buffer
> will be refreshed immediately after the delete operation completes.
> 
> Why? Am I missing something? Is this a (known) bug or expected behaviour? I've
> tried with emacs -Q, so it seems to be no configuration problem.
> 
> Regards,
> Harald

I have found an explanation for my own question: The problem is that after a 
dired-do-xxxx command, the buffer of the _target_ directory will be refreshed. 
But the target directory of /home/user/tmp/test/a/a would be 
/home/user/tmp/test/a/, and that is different from the one used in the base 
dir of the cons (/home/user/). In fact, if I add a file /home/user/x and add 
that to the file list and delete it, the buffer will be reverted correctly. If 
I delete any of the other files, it won't.

Now, what could I do to programmatically revert the current dired buffer after 
executing a dired-do command?

Harald

-- 
`Experience is the best teacher.'

PGP Key ID: 4FFFAB21B8580ABD
Fingerprint: E073 6DD8 FF40 9CF2 0665 11D4 4FFF AB21 B858 0ABD

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: dired cons bug?

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2022-08-11 09:43]:
> > Date: Thu, 11 Aug 2022 08:55:40 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: help-gnu-emacs@gnu.org
> > 
> > * Harald Judt <h.judt@gmx.at> [2022-08-11 08:05]:
> > > Hi,
> > > 
> > > I have a question regarding using dired programmatically in Emacs 28.1. Say I
> > > do the following call to open a dired buffer and insert the files:
> > > 
> > > (dired "/home/"(cons "/home/admin" '("/home/user/tmp/test/a/a" "/home/user/tmp/test/b/b" "/home/user/tmp/test/c/c")))
> > 
> > Function is not intended to be use that way.
> > 
> > (dired DIRNAME &optional SWITCHES)
> > 
> > DIRNAME must be directory name. Not cons and some files inside.
> 
> Did you consult the doc string before writing the above?  It says:

You are right, I did not. Next time I will.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: dired cons bug?

[Eli Zaretskii]

> Date: Wed, 10 Aug 2022 13:26:25 +0200
> From: Harald Judt <h.judt@gmx.at>
> 
> I have a question regarding using dired programmatically in Emacs 28.1. Say I
> do the following call to open a dired buffer and insert the files:
> 
> (dired (cons "/home/user" '("/home/user/tmp/test/a/a" 
> "/home/user/tmp/test/b/b" "/home/user/tmp/test/c/c")))
> 
> It works fine, I get a nice listing and can move around like expected, mark
> files and try to delete them. Now it gets interesting: Usually after hitting
> "x" to execute, then confirming the deletion, the buffer will refresh. But not
> in this case, not when I open dired using the cons above. I can revert the
> buffer using "g".
> 
> Note that when I simply do (dired "/home/user/tmp/test"), then insert the
> subdir to show the files and delete them, this is not reproducible. The buffer
> will be refreshed immediately after the delete operation completes.
> 
> Why? Am I missing something? Is this a (known) bug or expected behaviour? I've
> tried with emacs -Q, so it seems to be no configuration problem.

I think it's a bug.  Please see if the patch below gives good results.

diff --git a/lisp/dired.el b/lisp/dired.el
index f261f9f..f7651c6 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -3674,7 +3674,10 @@ dired-internal-do-deletions
 		      (progress-reporter-update progress-reporter succ)
 		      (dired-fun-in-all-buffers
 		       (file-name-directory fn) (file-name-nondirectory fn)
-		       #'dired-delete-entry fn))
+		       #'dired-delete-entry fn)
+                      ;; For when FN's directory name is different
+                      ;; from the current buffer's dired-directory.
+                      (dired-delete-entry fn))
                   (quit (throw '--delete-cancel (message "OK, canceled")))
 		  (error ;; catch errors from failed deletions
 		   (dired-log "%s: %s\n" (car err) (error-message-string err))

Re: dired cons bug?

[Eli Zaretskii]

> Date: Thu, 11 Aug 2022 11:23:52 +0200
> From: Harald Judt <h.judt@gmx.at>
> 
> I have found an explanation for my own question: The problem is that after a 
> dired-do-xxxx command, the buffer of the _target_ directory will be refreshed. 
> But the target directory of /home/user/tmp/test/a/a would be 
> /home/user/tmp/test/a/, and that is different from the one used in the base 
> dir of the cons (/home/user/). In fact, if I add a file /home/user/x and add 
> that to the file list and delete it, the buffer will be reverted correctly. If 
> I delete any of the other files, it won't.
> 
> Now, what could I do to programmatically revert the current dired buffer after 
> executing a dired-do command?

I have posted a patch that's supposed to fix this.  Please try it.

Re: dired cons bug?

[Harald Judt]

[-- Attachment #1.1: Type: text/plain, Size: 1218 bytes --]

Hi Eli,

> >/Date: Thu, 11 Aug 2022 11:23:52 +0200/
> >/From: Harald Judt <h.judt@gmx.at>/
> >//
> >/I have found an explanation for my own question: The problem is that after a /
> >/dired-do-xxxx command, the buffer of the _target_ directory will be /
> >/refreshed. /
> >/But the target directory of /home/user/tmp/test/a/a would be /
> >//home/user/tmp/test/a/, and that is different from the one used in the base /
> >/dir of the cons (/home/user/). In fact, if I add a file /home/user/x and add /
> >/that to the file list and delete it, the buffer will be reverted correctly. /
> >/If /
> >/I delete any of the other files, it won't./
> >//
> >/Now, what could I do to programmatically revert the current dired buffer /
> >/after /
> >/executing a dired-do command?/
>
> I have posted a patch that's supposed to fix this.  Please try it.

Thanks for your patch, I have tried it and it indeed fixes my problems. I have 
not noticed any new problems caused by it so far, but I'll give it some more 
thorough testing next week.

Regards,

Harald

-- 
`Experience is the best teacher.'

PGP Key ID: 4FFFAB21B8580ABD
Fingerprint: E073 6DD8 FF40 9CF2 0665 11D4 4FFF AB21 B858 0ABD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]