Re: Propagating local variables?

[Stefan Monnier <monnier@iro.umontreal.ca>]

> SM> I only mentioned it as a mechanism to share a variable among various
> SM> buffers. We could decide that shell.el obeys a `parent-buffer` variable
> SM> (presumably set by some other package) when non-nil by fetching the
> SM> buffer-local `process-environment' of that buffer.
> There are too many other cases where this is needed.  Expecting it to happen
> "by convention" means it won't happen in many cases where it should, simply
> because the idea of referencing a parent buffer was omitted.

Agreed.

Maybe this is remotely related to the idea of major-mode variables.

We could imagine introducing a new notion of "setting", with operations like:

    (setting-set NAME VALUE CONTEXT)
    (setting-get NAME)

where `setting-get` returns the "nearest" setting of NAME.
CONTEXT could be:
- a window
- a frame
- a major-mode
- a buffer
- a directory
- a file
- a terminal
- ...

and the notion of proximity would impose some ordering between these
different CONTEXT values.  Of course, the current-buffer would be
"nearer" than the current frame, but what about the parent of the
current-buffer?
[ This is relevant to your use-case since in some situations we
  currently look at frame-parameters to decide how to build subprocess's
  environment variables (more specifically for the DISPLAY env-var).
  So a process-environment would actually want to be a combination of
  the environment specified from the frame and that specified by your
  parent's buffer.  ]

Of course, like all other proposals it doesn't solve the problem of
making sure this new mechanism is used everywhere.


        Stefan