Re: server-local variables

[Ted Zlatanov <tzz@lifelogs.com>]

On Mon, 31 Oct 2016 17:26:07 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:
>> That's very interesting. Some questions:
>> 
>> * how are multiple classes merged?

MA> (server-locals-set-class
MA>  "my-user@my-remote-host" 'remote-bash)
MA> (server-locals-set-class
MA>  "my-user@my-remote-host" '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).

Otherwise the API looks reasonable to me :)

>> * 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.

>> * why not an obarray?

MA> See Stefan

OK, it seemed like you were basically designing a scoped symbol table
per connection, so an obarray seemed sensible. I haven't worked with
them so it was just a question for my education. But if they are
actively discouraged for most usage, the ELisp manual section on
Creating Symbols should mention that. I was not aware.

>> * 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.

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 :)

Ted