[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
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.
Re: server-local variables, Ted Zlatanov, 2016/10/31