all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Michael Albinus <michael.albinus@gmx.de>
To: Christopher Cooper <christopher.c.cooper@gmail.com>
Cc: 32090@debbugs.gnu.org
Subject: bug#32090: 26.1; connection-local-variables do not match as described
Date: Sun, 08 Jul 2018 11:46:55 +0200	[thread overview]
Message-ID: <87tvpaawkw.fsf@gmx.de> (raw)
In-Reply-To: <CAHorFcif8V6puMuOrNkdGoFS0SV13yHfhBv-3KOHtrA2WRtGTw@mail.gmail.com> (Christopher Cooper's message of "Sun, 8 Jul 2018 00:10:48 -0400")

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

Hi Christopher,

> According to the docstring for 'connection-local-criteria-alist',
> "CRITERIA is a plist identifying a connection and the application
> using this connection. ... All properties are optional; if
> CRITERIA is nil, it always applies."
>
> This does not appear to be true. In fact, this is plainly evident by
> simple visual inspection of 'connection-local-get-profiles'. Only
> :application seems to be optional.
>
> Reproduction is quite simple. Run emacs -Q and eval the following elisp:
>
> (defvar test--var nil)
> (setf enable-connection-local-variables t)
> (connection-local-set-profile-variables 'test-profile '((test--var . t)))
> (connection-local-set-profiles nil 'test-profile)
>
> Now open any TRAMP connection. Switch to the TRAMP buffer (where
> connection-local-variables should have taken effect) and do
> M-: test--var. The result is nil.
>
> If you conduct the same test, but specify the :protocol, :user, and
> :machine as part of the criteria in the 'connection-local-set-profiles'
> call, test--var will evaluate to t, which is correct.
>
> At best this is a case of misleading documentation, and at worst it is a
> feature that never got implemented. Connection-local variables would be
> very useful to me if they worked as described. I am glad to provide more
> info or help in any capacity.

It is not misleading documentation. It is the Tramp implementation, how
connection-local variables are set. In
tramp-set-connection-local-variables, you'll see

--8<---------------cut here---------------start------------->8---
(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.

Connection-lcal variables in general work as expected. Eval in the
*scratch* buffer:

--8<---------------cut here---------------start------------->8---
(defvar test--var nil)
(setf enable-connection-local-variables t)
(connection-local-set-profile-variables 'test-profile '((test--var . t)))
(connection-local-set-profiles nil 'test-profile)

;; Check initial value.
(describe-variable 'test--var)

;; Set connection local variables for a random criteria.
(hack-connection-local-variables-apply '(:application foo))

;; Check the value, again.
(describe-variable 'test--var)
--8<---------------cut here---------------end--------------->8---

In fact, properties in criteria are optional only in case the
application allows this in its `hack-connection-local-variables-apply'
call, except for :application. This must either match, or be nil.

The Tramp manual gives you an example how to use connection-local
variables fo Tramp itself, see (info "(tramp) Remote processes") . I
agree, it should be more verbose to explain, how a criteria for Tramp
must look like. Will add it.

Best regards, Michael.





  reply	other threads:[~2018-07-08  9:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-08  4:10 bug#32090: 26.1; connection-local-variables do not match as described Christopher Cooper
2018-07-08  9:46 ` Michael Albinus [this message]
2018-07-08 13:09   ` Christopher Cooper
2018-07-09 14:15     ` Michael Albinus
2018-09-05  9:02       ` Michael Albinus
2018-09-05 18:08         ` Glenn Morris
2018-09-06  7:07           ` Michael Albinus
2018-11-08  9:27         ` Michael Albinus
2018-07-08 18:23 ` bug#32090: Fwd: " Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tvpaawkw.fsf@gmx.de \
    --to=michael.albinus@gmx.de \
    --cc=32090@debbugs.gnu.org \
    --cc=christopher.c.cooper@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.