unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Kangas <stefan@marxist.se>
To: Boruch Baum <boruch_baum@gmx.com>
Cc: 34338@debbugs.gnu.org
Subject: bug#34338: 26.1; delete-file return codes and failures
Date: Fri, 08 Nov 2019 14:00:09 +0100	[thread overview]
Message-ID: <87h83etteu.fsf@marxist.se> (raw)
In-Reply-To: <20191031012641.lam4pwo3cenf7tsu@E15-2016.optimum.net> (Boruch Baum's message of "Wed, 30 Oct 2019 21:33:29 -0400")

tags 34338 - wontfix
reopen 34338
thanks

Boruch Baum <boruch_baum@gmx.com> writes:

> On 2019-10-30 23:52, Stefan Kangas wrote:
>> Boruch Baum <boruch_baum@gmx.com> writes:
>>
>> Do you have a use-case in mind here?  Can't the caller just check using
>> 'file-exists-p' if it matters instead?
>
> It _should_ *always* matter. Did you delete the file or not? If it didn't
> matter, why waste your time attempting the deletion?

I think Eli answered this point well, and I still think a use-case
would have been helpful here.  If I was trying to convince people to
spend time on this, I would try to provide a code example where the
suggested change would simplify the code and/or make maintenance
easier.

> Having delete-file return the value is: a) consistent with what I think
> is the expectation of most CS folks;

Not sure if I'm like most CS folks, but that wasn't my expectation.
IME, this works differently in different languages.

> b) the most efficient, since it already knows the exact point of any
> failure, and basically just passes the return value it gets from the
> underlying OS.

That's a good point.

In any case, I closed the bug in the belief that there was nothing
more to do here given the lack of response.  I'm not against the
change as such.

I've therefore reopened the bug in the hope that someone would want to
take a crack at implementing this.  Boruch, perhaps you could consider
volunteering?

Best regards,
Stefan Kangas





  parent reply	other threads:[~2019-11-08 13:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-05 21:47 bug#34338: 26.1; delete-file return codes and failures Boruch Baum
2019-02-06  8:24 ` Michael Albinus
2019-02-06  9:35   ` Boruch Baum
2019-02-06 16:19 ` Eli Zaretskii
2019-02-06 21:02   ` Boruch Baum
2019-02-07  3:36     ` Eli Zaretskii
2019-02-07  5:14       ` Boruch Baum
2019-10-09 11:48 ` Stefan Kangas
2019-10-30 21:07   ` Stefan Kangas
2019-10-30 22:22     ` Boruch Baum
2019-10-30 22:52       ` Stefan Kangas
2019-10-31  1:33         ` Boruch Baum
2019-10-31 14:32           ` Eli Zaretskii
2019-11-01  9:34             ` Boruch Baum
2019-11-01  9:55               ` Eli Zaretskii
2019-11-08 13:00           ` Stefan Kangas [this message]
2019-10-31 14:01       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h83etteu.fsf@marxist.se \
    --to=stefan@marxist.se \
    --cc=34338@debbugs.gnu.org \
    --cc=boruch_baum@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).