[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Propagating local variables?
From: |
Stefan Monnier |
Subject: |
Re: Propagating local variables? |
Date: |
Thu, 17 May 2018 10:45:50 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
> 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
Re: Propagating local variables?, Richard Stallman, 2018/05/16
Re: Propagating local variables?, Shea Levy, 2018/05/17