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

[Robert Pluim]

>>>>> On Thu, 10 Aug 2023 16:25:32 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> 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'

    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.

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

    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.

Robert
--