GNU bug report logs - #30938
27.0; `dired-do-create-files' etc.: do NOT always raise error if no files

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Juri Linkov <juri <at> linkov.net>
Cc: "30938 <at> debbugs.gnu.org" <30938 <at> debbugs.gnu.org>
Subject: bug#30938: 27.0; `dired-do-create-files' etc.: do NOT always raise error if no files
Date: Thu, 21 Apr 2022 15:01:47 +0000

> Skimming this bug report, it seems like the conclusion was that we
> don't want to change anything here, so I'm closing this bug report.

Very unfortunate.

For the record, and for Someone who might care to
fix this mistake in the future, here's a summary,
with text from previous messages.
___

There's no reason to assume that interactive and
non-interactive use of a given command should have
the same behavior wrt `dired-get-marked-files' arg
ERROR. Such hardcoding provides no benefit and can
get in the way.

A non-interactive use case for an arbitrary command
that calls ` dired-get-marked-files' does not
necessarily have `user-error' as the right behavior
for an empty set of marked files.

A common use case where the error can kick in is
when a FILTER passed to `dired-get-marked-files'
results in an empty file list.

While it is typically a user error if nothing is
marked and point is not on any file line, it is
not necessarily an error when neither of those is
the case - even for an interactive case.  The
individual command needs to decide whether that
is an error case.

Similarly, for a command B that _invokes_ such a
command A.  It's up to _B to decide_ whether to
raise an error.  If A systematically causes
`dired-get-marked-files' to raise an error in a
context where an error makes sense for A, that
can conflict with what makes sense for B.

Previous Next

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