[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: server-local variables

From: Michael Albinus
Subject: Re: server-local variables
Date: Mon, 31 Oct 2016 21:47:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Ted Zlatanov <address@hidden> writes:

> MA> (server-locals-set-class
> MA>  "address@hidden" 'remote-bash)
> MA> (server-locals-set-class
> MA>  "address@hidden" 'remote-nullfile)
> That seems awkward compared to (server-locals-set-classes CRITERIA CLASSES...)
> (in other words, I expect mixing classes to be the common case, so it
> should be easy).

Makes sense. Noted.

>>> * can classes be assigned by other means besides regexp?
> MA> No, not foreseen yet.
> I'd make it a regexp or a callable thing, that will cover 99% of the
> cases I can imagine.

Possible. Noted.

>>> * a macro `with-process-classes' would be nice
> MA> How shall it look like?
> I'd use it in a process to widen or narrow permissions and environment:
> ...connect to a host, then...
> (with-process-classes temporary-sudo-override temporary-shell-override
> ansible-host-environment
>   ...do something)
> It would take care of setting the connection-local variables inside the
> scope and unwinding them afterwards.

I see. The problem is unwinding the local variables; they could exist
already as local variables when entering the macro. But in general it
shall be possible, when implementing proper book-keeping.

Btw, I wouldn't call it with-*process*-classes. server-local (or
connection-local) variables could be applied to any buffer with a remote

> MA> Process buffers are the first, obvious use case for this. But I don't
> MA> want to restrict it to them. People could use it also for setting other
> MA> local variables in any remote buffer, maybe even for specific modes.
> ...
> MA> But I still believe there will be non-Tramp use cases. As already said,
> MA> ange-ftp comes to mind.
> OK, please take a look at the GnuTLS glue code in gnutls.el and you'll
> see what I need from this facility. I'm happy to start using it there as
> soon as the API is solidified. I have a TODO item (discussed with Lars a
> few months ago) to implement something like this facility so it's great
> to see it's not an isolated need :)

I've looked shortly on this. Seems like you need a mechanism for

> Ted

Best regards, Michael.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]