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

[Eli Zaretskii <eliz@gnu.org>]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Thu, 10 Aug 2023 15:12:01 +0200
> 
> >>>>> On Sun,  6 Aug 2023 10:04:06 -0400 (EDT), Eli Zaretskii <eliz@gnu.org> said:
> 
>     Eli> branch: master
>     Eli> commit 400df210ce0cc1ee0113b14a5ad92764d148c620
>     Eli> Author: Eli Zaretskii <eliz@gnu.org>
>     Eli> Commit: Eli Zaretskii <eliz@gnu.org>
> 
>     Eli>     Fix last change of 'delete-file'
>     
>     Eli>     * src/fileio.c (Fdelete_file_internal): Expand file name here, as
>     Eli>     all primitives must.
>     Eli>     (internal_delete_file): Adjust to the fact that Fdelete_file was
>     Eli>     renamed.
>     
>     Eli>     * lisp/files.el (delete-file): Don't expand-file-name here, as
>     Eli>     the called primitives already do.  Fix typo in doc string.
> 
> 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'

All file handlers are perfectly equipped to deal with unexpanded file
names.  It must be so, don't you agree?  Because if it wasn't, how
could file operations deal with relative file names?

> and donʼt expand it until (if) we reach `internal_delete_file'.

Only if the caller doesn't expand by itself.  And even if it doesn't
why do you think it's a problem?  Primitives that deal with file names
must always call expand-file-name early on, for this very reason.  No
primitive should assume it will receive only absolute file names.