Re: Propagating local variables?

[Shea Levy <shea@shealevy.com>]

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

To provide some more context, the hackiness is two-fold:

1. How do we decide which buffers should inherit the relevant variables?
   Currently in most cases I'm using a "if it starts with a space it's
   probably morally a child" heuristic, plus a few extras hard-coded,
   but it's not great.
2. How do we actually ensure the variables are propagated? I wrote the
   inherit-local package to do the propagation, but there's no obvious
   hook point to call it (thus the advice around generate-new-buffer)

"John Wiegley" <johnw@gnu.org> writes:

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]