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: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 30938 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: bug#30938: 27.0; `dired-do-create-files' etc.: do NOT always raise error if no files
Date: Fri, 30 Mar 2018 10:57:03 +0300

> Date: Thu, 29 Mar 2018 21:01:44 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 30938 <at> debbugs.gnu.org
> 
> Instead of asking me if I don't see there is something
> wrong with that, why don't you tell us what you think
> is wrong with it?
> 
> I said from the beginning:
> 
>   Please revert this change as soon as possible,
>   while you look for a better way to do what you
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   intended to do for it.
> 
> I'm open to other ways to do what is needed, if they
> are better.  Feel free to propose something.
> 
> I'm fine with what I proposed - either proposal:
> 
> 1. What I proposed at the outset: revert the bad change
>    and do nothing until a better approach is decided on.
> 
> 2. What I proposed in my follow-up: provide an INTERACTIVEP
>    arg to distinguish interactive use, and (at most) raise
>    a `user-error' only in the interactive-call case.
> 
> You asked if there was a better approach than doing #2.
> I replied that #2 seems fine, to me.  But please feel free
> to propose another approach, explaining why you think it's
> better.
> 
> Someone apparently thought it was OK to change 13 commands
> to ALWAYS raise an error in the no-files case.  Why are
> you shocked to hear that I would be OK with changing those
> same commands to not raise the error in the non-interactive
> case - IOW, to return them to their longstanding behavior
> in that case?

A lot of discussion gone under the bridge, but I asked a question in
the very beginning that was apparently ignored:

  Please provide at least one example (preferably more than one) of a
  real-life use case where these changes get in the way.

Without an answer to that, I cannot see why we have to do anything
about this issue, because up front I see no problem here at all, not
one that has been spelled out.

Previous Next

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