Re: dired-handler-fn (was: Re: XEemacs-19.11 and ef..)
sandy@ibm550.sissa.it
Sun, 17 Jul 1994 16:31:55 +0200
Joerg-Martin,
On Sun, 17 Jul 94 you wrote:
> 1. You could avoid some calls to dired-handler-fn
> if this were installed to the file-name-handler-alist
> not when dired is loaded,
> but when the first dired
This is a good idea.
> buffer is created, and if it were uninstalled when the
> dired-buffers list is empty. (only the 2nd point matters when
> dired is autoloaded)
This would be tough to check, I think. The dired buffer list isn't
always current. For eg,. it can't track every call to kill-buffer.
dired is frequently double-checking this list to make it current. The
problem is that dired will only be checking this list if dired
functions are running. Meaning, an empty and at the same time current
dired buffer list is unlikely.
> 2. The handlers call dired-check-file-name-handler-alist
> extensively.
True, but it's a very cheap call, most of the time. I'll try making
dired-internal-noselect call it instead of dired-handler-fn. It'll
reduce the number of times that it gets called.
> There should be some provisions to
> make sure that _every_ package installs itself into
> the alist in the correct order, which would then make
> this call unnecessary.
> It is e.g. wrong to install efs before JKA's compression package.
The problem here is getting every package to agree on the correct
order. I'm suprised that the order of jks-compr and efs matter. Is
there a good reason why they should?
> 3. Instead of handling the regexp ".*" (why not ".", btw?)
Oh I don't know. I guess that there is a small difference in match
speed. I'll use ".".
> one could install an entry for all directories that are actually
> edited in a dired buffer. But I am really
> not sure which possibility would be faster.
What would worry me here is overflowing the regexp stack. Only so
many "\\|"'s are supported in regexps. I forget the number, but it's
not huge.
--sandy