Re: server-local variables

[Michael Albinus]

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
default-directory. 

> 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
`gnutls-boot-parameters'.

> Ted

Best regards, Michael.