emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael Albinus
Subject: Re: master 400df210ce0: Fix last change of 'delete-file'
Date: Sat, 12 Aug 2023 11:57:19 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> > The addition of expand-file-name to delete-file made that function a
>> > bit slower, and for local files that is a net loss.  We should extend
>> > instead find-file-name-handler to work for non-absolute file names to
>> > avoid this overhead.
>>
>> It is not a recent addition, it has been there for ages. In Fdelete_file.
>
> I'm talking about the situation on master now, after delete-file was
> split into two parts.  After my change today, delete-file calls
> expand-file-name (because find-file-name-handler needs that), and then
> delete-file-internal calls expand-file-name again (because every
> primitive must).

But this is due to moving delete-file from C core to Lisp. We have the
same situation with other Lisp functions, which support file name
handlers and call a C-level function. For example, make-temp-file /
make-temp-file-internal, make-directory / make-directory-internal,
delete-directory / delete-directory-internal.

>> > Indeed, the fact that find-file-name-handler needs an absolute file
>> > name is never mentioned anywhere in the documentation.  It is strange
>> > this didn't pop up earlier.
>>
>> find-file-name-handler does not need an absolute file name in
>> general. Several handlers are invoked based on the file name
>> extensions. It are the remote file names which require absolute file
>> names.
>
> A caller of find-file-name-handler cannot (and should not) know which
> parts of the file name the handlers look at.

Yes.

>> If we add expand-file-name for cases it isn't applied yet, Emacs might
>> become slower. And perhaps we introduce new faults by this, because
>> everybody has arranged with the current behavior.
>
> But the situation now is bad already: if I call
> file-name-as-directory, for example, with a relative file name in a
> remote directory, the handler is not invoked.  Isn't that a bug?

Perhaps. But in practice, I'm not aware of bug reports about.

However, we cannot call Fexpand_file_name in Ffind_file_name_handler,
because expand-file-name supports also file name handlers. This would be
an infloop. And just binding file-name-handler-alist to nil doesn't
return the proper result, but a result which is similar only:

--8<---------------cut here---------------start------------->8---
(let ((default-directory "/ssh::")
      file-name-handler-alist)
  (expand-file-name "123"))

=> "/ssh::/123"
--8<---------------cut here---------------end--------------->8---

This might be sufficient, but there are cases where we fail. On MS
Windows, for example, we have

--8<---------------cut here---------------start------------->8---
(let ((default-directory "/ssh::")
      file-name-handler-alist)
  (expand-file-name "123"))

=> "c:/ssh::/123"
--8<---------------cut here---------------end--------------->8---

Best regards, Michael.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]