bug#32090: Fwd: bug#32090: 26.1; connection-local-variables do not match as described

[Michael Albinus <michael.albinus@gmx.de>]

-------------------- Start of forwarded message --------------------
From: Michael Albinus <michael.albinus@gmx.de>
Subject: Re: bug#32090: 26.1; connection-local-variables do not match as described
Date: Sun, 08 Jul 2018 17:16:42 +0200

Christopher Cooper <christopher.c.cooper@gmail.com> writes:

Hi Christoph,

>>> (tramp-compat-funcall
>>>  'hack-connection-local-variables-apply
>>>  `(:application tramp
>>>    :protocol    ,(tramp-file-name-method vec)
>>>    :user        ,(tramp-file-name-user-domain vec)
>>>    :machine     ,(tramp-file-name-host-port vec)))))
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> That means, the Tramp implementation requires :application to be 'tramp
>>> or nil, *and* it requires setting of :protocol, :user and :machine in
>>> your criteria, which match the respective remote file name.
>>
>> This makes sense, except that I'm still confused on why :application
>> can be nil but :protocol, :user, and :machine cannot be.

Well, being also the Tramp maintainer, I have designed connection-local
variables with Tramp in mind :-)

Other packages have shown interest to use connection-local variables as
well (nnimap, gnutls, if I'm not mistaken), but they haven't implemented
it yet. And so there are no further feature requests.

>> The Tramp info page seems pretty fine to me. The real issue is in two places:
>>
>> (info "(elisp) Connection Local Variables"):
>>> -- Function: connection-local-set-profiles criteria &rest profiles
>>>     ...
>>>     All properties are optional; if
>>>     CRITERIA is ‘nil’, it always applies.
>>
>> But as determined above, if CRITERIA is 'nil', it does not always
>> apply. It is up to the application to provide this feature, and Tramp
>> does not.
>> In fact, there is even an example showing this feature, which appears
>> be plain wrong:
>>
>>>     If CRITERIA is ‘nil’, it applies for all remote connections.
>>>     Therefore, the example above would be equivalent to
>>>
>>>          (connection-local-set-profiles
>>>            '(:application 'tramp :protocol "ssh" :machine "localhost")
>>>            'remote-bash)
>>>
>>>          (connection-local-set-profiles
>>>            '(:application 'tramp :protocol "sudo"
>>>              :user "root" :machine "localhost")
>>>            'remote-ksh)
>>>
>>>          (connection-local-set-profiles
>>>            nil 'remote-null-device)
>>
>> At least with current Tramp, the 'remote-null-device profile will
>> never apply, since it does not provide the properties needed by Tramp.
>> This also means that this example is not equivalent to the above
>> example as stated.

Yes, that's an error. Will fix the documentation.

>> The other place of confusion was the docstring for
>> 'connection-local-criteria-alist' that I mentioned initially.
>>
>> I think ultimately, it comes down to a confusion over what "optional"
>> means. I took it to mean: "It this property is provided, it will be
>> checked when matching. If not, we don't care about the value of this
>> property." And, as I stated earlier, I don't understand how the
>> sentence "If CRITERIA is 'nil', it always applies." is try in any
>> sense of those words. If the feature is working as intended, those are
>> the worst offenders as far as confusing documentation.
>>
>> Once again, I appreciate this feature and your explanation here. I
>> hope this is helpful in clarifying the documentation.

Well, I'm also open to extend connection-local variables to other
application's need but Tramp. Proposals welcome!

The downside is, that such changes must go to the master branch (which
will become Emacs 27.1). The emacs-26 branch is open for bug fixing only.

>> Christopher

Best regards, Michael.
-------------------- End of forwarded message --------------------