Re: master 400df210ce0: Fix last change of 'delete-file'

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 10 Aug 2023 15:44:54 +0200
> 
> >>>>> On Thu, 10 Aug 2023 16:25:32 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> I donʼt know if it matters, but along with esrʼs change this means we
>     >> now use the unexpanded file name for eg `find-file-name-handler'
> 
>     Eli> All file handlers are perfectly equipped to deal with unexpanded file
>     Eli> names.  It must be so, don't you agree?  Because if it wasn't, how
>     Eli> could file operations deal with relative file names?
> 
> I was thinking of the opposite case, where someone has a personal file
> handler with a regexp with an absolute path in it.

That'd be a buggy file handler, I think, unless it also checks
default-directory.

>     Eli> Only if the caller doesn't expand by itself.  And even if it doesn't
>     Eli> why do you think it's a problem?  Primitives that deal with file 
> names
>     Eli> must always call expand-file-name early on, for this very reason.  No
>     Eli> primitive should assume it will receive only absolute file names.
> 
> I donʼt think itʼs a problem; I was just noting the change, and
> wondering if it mattered.

I don't think it could matter.  Before the change we had Fdelete_file
which could handle relative file names perfectly well, eight?  So some
Lisp could call delete-file passing it a relative file name, and that
would work correctly, right?  Now we have the same arrangement, except
that the primitive was renamed.  In effect, the call to
expand-file-name was pushed a bit further into the processing
pipeline.  That cannot cause any harm, as long as code before
expand-file-name expects absolute file names.  But no general-purpose
Lisp code should ever expect only absolute file names, because we make
them absolute in the primitives.