l...@gnu.org (Ludovic Courtès) writes:
> Hello,
>
> Peter Brett <pe...@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 <pe...@peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre
