Re: Error with tramp-archive-autoload-file-name-handler

[Felix Dietrich]

Hi Michael,

Michael Albinus <michael.albinus@gmx.de> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:

>> I've shortly tested the recipe given in that bug, and everything seems
>> to be OK with your patch. I will apply your patch in your name to the
>> emacs-28 branch, after I have merged it with other pending Tramp
>> patches.
>
> Done.

>> Perhaps you could provide a ChangeLog-style commit message?

Thanks for taking care of fixing the style of my commit message. :)


Hm, I had wanted to add that now ‘tramp-autoload-file-name-handler’ and
‘tramp-archive-autoload-file-name-handler’ look nearly the same, and
that a nicer solution would be to revert the changes of 4db69b32b8 (“Fix
bug#48476”) to tramp-archive.el and make the archive autoload handler an
alias again to ‘tramp-autoload-file-name-handler’ as well as changing
the latter to use ‘tramp-archive-enabled’ directly instead of via
‘tramp-archive-autoload’.  Interestingly, this does not work (almost
sent it without testing): it causes a similar issue as bug #48476 with
an error message “Recursive load” (no hang due to an infinite loop
though).  Do you remember why using ‘defalias’ here causes an infinite
recursion?

The attached patch shows the erroneous changes described above.  Here
the steps from bug #48476 to reproduce the issue:

    mkdir foo.tar
    cd foo.tar
    emacs

I also forced ‘tramp-gvfs-enabled’ to t because its checks do not seem
to take the DBUS_SESSION_BUS_ADDRESS environment variable into account
(which was set by dbus-run-session).  Maybe this had a negative
influence.

0001-Make-tramp-archive-autoload-file-name-handler-an-ali.patch
Description: Patch with changes that result in a recursive load

> Felix Dietrich <felix.dietrich@sperrhaken.name> writes:

>> Now, why is it a problem to add
>> ‘tramp-archive-autoload-file-name-handler’ to ‘file-name-handler-alist’
>> if ‘tramp-archive-file-name-handler’ is already there?  Why does the
>> following snipped still fail even though
>> ‘tramp-archive-file-name-handler’ comes first in the handler alist?

> With my previous patch, this shouldn't happen
> anymore. Both tramp-archive-autoload-file-name-handler and
> tramp-archive-file-name-handler shouldn't coexist in
> file-name-handler-alist. Do you still see this after your patch has been
> applied?

I havenʼt looked particular hard, but no, I do not see both the autoload
and the normal handler in the ‘file-name-handler-alist’ at the same time
after a normal start and load of tramp – well, if I donʼt put them there
myself, that is.  My intention with this part was to show the issue I
described was connected to and indeed the cause for the problem Michael
Heerdegen had encountered, and also just to provide further details (I
was really confused about the example in that part for quite a while).

-- 
Felix Dietrich