Re: Multiple parallel environments

[Peter Brett <peter@peter-b.co.uk>]

ludo@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> Peter Brett <peter@peter-b.co.uk> writes:
>
>> What I'd like to do is something like the following:
>>
>>   * Load system config
>>   * Load user config
>>   * Save environment ==> [0]
>>
>>   * User opens /path/to/a/file
>>   * Load config from /path/to/a/editor.conf
>>   * Edit, edit, hack, hack.
>>
>>   * User opens /path/to/another/file
>>   * Save environment ==> [1]
>>   * Restore environment <== [0]
>>   * Load config from /path/to/another/editor.conf
>>   * Edit, edit, hack, hack.
>
> Before answering, I'd like to make sure I understand what you want to
> achieve.

Okay. Just to clarify, this is an instance where Guile is being used
as an extension language for an application written predominantly in C
and GTK+2.0.

> What do you mean by "environment"?  All the global variables associated
> with a given file in the editor?

Sort of.  The whole of Guile's top level bindings at that point.  (The
per-directory config is literally loaded as a Scheme script, so it
could define and redefine functions and variables at will).

> What do you mean by "save"?  Serialize to a file the "environment"
> associated with a file (or the difference compared to the initial
> environment)?

It doesn't need to be serialised -- I don't even need to be able to
get a C pointer to it! -- it just needs to be "stashed" somewhere so
that I can "rewind" Guile's toplevel bindings to that point at a later
time.

Essentially, I want each directory/"project" to be able to define its
own functions, include its own modules etc. without stomping over
another project that happens to be loaded into the application at the
same time.

I hope that makes the problem clear as mud. ;-)

[ One horrible idea was to abuse scm_from_locale_symbol() and
  scm_c_call_with_current_module() in some horrendous way. How likely
  would this be to break cataclysmically in Guile > 1.8.x? ]

Best wishes,

                              Peter

-- 
Peter Brett <peter@peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre