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" 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