Discussion:
Propagating local variables?
(too old to reply)
John Wiegley
2018-05-15 19:37:30 UTC
Permalink
I'd like to create a module, propagate.el, which defines a new class of buffer
local variables: buffer local variables that propagate to any buffers or
processes (in the case of exec-path and process-environment) created on behalf
of the parent.

For example, in certain language modes I have `exec-path' customized to pick
up specific versions of the compiler and debugger. If I run M-x gdb, I'd like
the debugger used to be the one associated with _that_ buffer -- without
making that debugger global to all other buffers (or even available at all).

Right now this idea lies at the heart of Shea Levy's nix-buffer package,
allowing you to have the equivalent of a "nix-shell" within Emacs, so that a
given buffer (and its related child buffers and processes) all see a
consistent set of dependencies as defined by some dir-locals.nix file.

A next step for this project is to abstract out the concept of "propagating
locals" to its own module. However, some of the aspects of implementing it
have proven very hacky, so I'm wondering if we need more low-level support for
this idea. For example, at the moment we do it with advice around
generate-new-buffer. What would be better is to have a general hook for
altering what happens when new buffers and processes are created, something
that could "provide an environment" upon creation of these.

All thoughts welcome,
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
Roland Winkler
2018-05-16 03:42:04 UTC
Permalink
Post by John Wiegley
I'd like to create a module, propagate.el, which defines a new class
of buffer local variables: buffer local variables that propagate to
any buffers or processes (in the case of exec-path and
process-environment) created on behalf of the parent.
This is an interesting idea. I am not sure whether the following is
related to your thoughts. I'll mention it anyway:

In GNU Elpa is djvu.el for editing djvu documents. These documents come
with multiple layers for text, annotations, bookmarks, etc. (kind of
similar to pdf documents). So when you visit such a document with
djvu.el it creates a buffer for each of these layers (plus a few extra
ones for "viewing these layers"). Conventional buffer-local variables
do not work in this case because the buffer-local variables need to be
shared across the buffers that refer to the same document, but buffers
for different documents should peacefully coexist. Hence to make this
work djvu.el uses a conventional buffer-local variable whose value is a
vector which is the same object for all buffers belonging to one djvu
document (one vector for each djvu document). The elements of this
vector are then the "document-local" variables where setting such an
element in one buffer is seen in all other buffers for the same
document, while buffers for different djvu documents do not interfere
with each other. Another advantage is that temp buffers can easily
inherit these document-local variables.

I have always considered this a hack. But I could not think of a better
solution. Suggestions are welcome.

Roland
Stefan Monnier
2018-05-16 17:34:41 UTC
Permalink
Post by Roland Winkler
I have always considered this a hack. But I could not think of a better
solution. Suggestions are welcome.
I think most other "multi-buffer" packages tend to treat one of their
buffers as a kind of "master" and have all others point to it, so they
can lookup shared local variables via something like
(buffer-local-value my-parent-buffer 'varname).


Stefan
John Wiegley
2018-05-16 18:59:06 UTC
Permalink
SM> I think most other "multi-buffer" packages tend to treat one of their
SM> buffers as a kind of "master" and have all others point to it, so they can
SM> lookup shared local variables via something like (buffer-local-value
SM> my-parent-buffer 'varname).

If you're the author of all the code that relates to that buffer, sure. But I
can't expect shell.el to reference the buffer-local `process-environment' of
my Coq buffer in order to setup the right PATH for that project-specific
sub-shell.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
Loading...