Re: [19.25, efs 1.9] dired-handler-fn
sandy@ibm550.sissa.it
Thu, 14 Jul 1994 19:48:01 +0200
>>>>> On Thu, 14 Jul 94 16:48:50 BST,
Denis Howe <dbh@doc.ic.ac.uk> said:
> I think the solution is to allow handlers to be called only for
> certain operations.
I agree completely. We are getting clobbered by the fact that
find-file-name-handler searches the alist, finds a handler, that
handler inhibits itself, find-file-name-handler searches the alist
again, etc etc. Lots of funcall'ing and lots of regexp matching.
> The files could be specified by regexp as they
> are now and the operations could be specified by attaching properties
> to the operation's symbol.
> find-file-name-handler already gets the operation as an argument (to
> see if it currently has any inhibited handlers) so it could proceed as
> follows:
> match the filename against each car of file-name-handler-alist
> for each match, look at the cdr (HANDLER)
> if HANDLER has a function value then funcall it as before
> otherwise do (get file-op HANDLER)
> If get returns something then funcall that as the real handler
> else do nothing.
> This scheme is good because
> ...
> * it is backward compatible with the old defintion of
> file-name-handler-alist.
There is a backward compatibility problem associated to the fact that
although efs and ange-ftp both store the handler function in the I/O
function's p-list, they don't use the name of the handler as the prop
name. efs uses 'efs, and ange-ftp uses 'ange-ftp. Instead efs would
have to use 'efs-file-handler-function. OK by me, I can change it
easily enough, but the need to change all lisp packages using the
file-name-handler-alist might make it hard to persuade Richard to make
the change.
Another possible solution is to allow the car of elements in the
file-name-handler-alist to be lambda expressions. If CAR is a string,
find-file-name-handler matches it as a regexp against the filename.
If it's a lambda, then it calls it with args OPERATION And FILENAME.
If it returns non-nil, then a handler is assumed to be found.
This would be slower than Denis's proposal, but it would be more
general. I think that it would be fast enough though, as it would
still avoid the recursive re-calling of handlers. Personally, either
solution would be good enough, as both would suit how efs and dired
are currently using handlers.
By the way, even with these new proposals, Richard's addition of
inhibit-file-name-operation and inhibit-file-name-handlers are still
useful. He made the point to me that even if the file-name-handler
stuff is changed to avoid the most common instances of recursive
handlers, there should still be some way for a handler to call its
OPERATION recursively. I agree with this.
--sandy