[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: server-local variables
From: |
Ted Zlatanov |
Subject: |
Re: server-local variables |
Date: |
Tue, 01 Nov 2016 09:22:37 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) |
On Mon, 31 Oct 2016 21:47:32 +0100 Michael Albinus <address@hidden> wrote:
MA> Ted Zlatanov <address@hidden> writes:
>> (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.
MA> I see. The problem is unwinding the local variables; they could exist
MA> already as local variables when entering the macro. But in general it
MA> shall be possible, when implementing proper book-keeping.
That would be great, thank you for considering it.
MA> Btw, I wouldn't call it with-*process*-classes. server-local (or
MA> connection-local) variables could be applied to any buffer with a remote
MA> default-directory.
Any name is fine with me. It's really a pattern match against some
buffer characteristics and has a lot in common with file-and-dir-local
variables (which pattern match against the file location).
>> 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 :)
MA> I've looked shortly on this. Seems like you need a mechanism for
MA> `gnutls-boot-parameters'.
Yes, exactly. It needs to be flexible and augmentable to allow layering
of GnuTLS options; currently it's pretty much the opposite.
The GnuTLS priority strings, which are on the C side, have interesting
parallels with your concept of classes that represent sets of parameters.
Thanks
Ted