Re: Emacs Lisp container

["Phillip Lord" <phillip.lord@russet.org.uk>]

On Tue, June 27, 2017 3:03 am, Etienne Prud’homme wrote:
> Hi,
>
>
> I’ve tried to find a library or some tool to execute Elisp in a running
> session while keeping the same environment, but found none.  Some call it a
> container or sandbox or even jail.
>
> What I mean by that, is that I would like to execute a body of code and
> get the result without actually modifying the variables, functions, loaded
> features, etc. of the current session.
>
> I’m fully aware that starting a new session seem to do the same thing,
> but I want to execute the piece of code in the *current running
> environment*.
>
>
> I finally came up with a small library I named _container_[1].  There
> are many ways to escape the container (like using `funcall` & `apply` and
> also using `eval` on a quoted `eval` form).  It’s more of a proof a
> concept than a working library right now.
>
> e.g.
>
>> (let ((container-ignore-error t)
>> (container
>> (add-to-list 'load-path "~/Documents/")
>> (require 'foo)
>> (setq emacs-version "0.0.0")
>> emacs-version)) ; => "0.0.0" emacs-version ; => 26.0.50
>
> The above snippet doesn’t (seem to) have side-effects.
>
>
> What it does is the following:
>
>
> * Saves the window configuration and opens a new buffer.
>
>
> * Overrides the `require` & `load` functions to unload after the
> container finished executing.
>
> * Overrides the `load-theme` function to restore the original theme
> configuration after.
>
> * Overrides the `set`, `setq` & `set-default` functions to make the
> variable buffer local.
>
> * Overrides the `eval` function to apply the above.  This one is
> particularly tricky since we could escape it using a quoted form.  I’m
> considering disabling it altogheter and signal an error.
>
> * (Work in Progress) Overrides the `funcall` & `apply` functions to
> apply the rules above.  This is also tricky since the evaluation process
> doesn’t make much sense to me.  I’m probably not used enough with
> evalutation.  I can’t figure out why:
>
>> (funcall #'setq test 1)
>>
>
> works while:
>
>> (funcall #'setq 'test 1)
>>
>
> doesn’t work.
>
> Of course, I may be totally wrong in my approach and would appreciate
> being corrected.  Help and comments are welcomed!


It's a nice idea, but I think that C-level calls to setq will just ignore
your changes. Likewise for all your other alterations.

So, this will get you some of the way there, but not all of the way.
Besides which you still allow buffer changes which is, of course, a major
issue with statelessness.

Phil