> Capture the value of $EDITOR (actually you are supposed to look at
> $VISUAL first, and if it is undefined then look at $EDITOR) in a
> variable of  the (ed) library.  Then just use that variable henceforth.
> You can expose a set-editor! procedure to change it.

Then (get-environment-variable "EDITOR") and (get-editor) would
needlessly produce different results if the editor has been changed. And
any subprocess would get the old EDITOR again unless you use a
:environment alist as a third mechanism for changing the same thing.

> The above ideas avoid this.  If your program doesn't change any
> environment variables, use get-environment-variable freely.  If it does,
> capture the whole environment early in a global variable as an alist,
> search it with assoc, push things on the alist as you will, and pass it
> to all calls to spawn-process.

There are pros and cons to that approach.

> (I have updated ProcessesCowan to make it
> clear that if the same key appears more than once, the first value is
> put into the environment by spawn-process.)

This is good to specify.

> Not just that, but because putenv() can be used for dynamic binding
> without leaks, as I explained.

I wonder how many people understand that. That API is not for the faint
of heart.

>     We could also write a separate SRFI as a follow-up to SFI 98 with just
>     set-environment-variable! and delete-environment-variable! :) As was
>     done with the timespec SRFI.
>
> They are Posix but not C, so if they belong anywhere at all (and I think
> they don't), it's in the Posix SRFI.

WinAPI also has procedures to get and set them, as do most other OSes
probably.