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

[Robert Pluim <rpluim@gmail.com>]

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

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

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

The file handler isnʼt buggy: it never gets a chance to run.

Let me illustrate. Suppose we have an entry of

("\\`/var/.*\\.txt" . my-file-handler)

in `file-name-handler-alist'.

(delete-file "foo.txt") when `default-directory' is "/var" would
previously result in `my-file-handler' being called. Now itʼs not
called at all, and the deletion is handled by `delete-file-internal'

Robert
--