Glad to see your face again, Karl! psu25682(a)odin.cc.pdx.edu (Karl M. Hegbloom) writes: I thought about this some time ago, and I must say I don't like this solution. While it's true that Emacs Lisp is already divergent from any other Lisp, adding extent-local variables would add new meaning to the notion of divergence. In Lisp, the value of a variable should be just that. In Emacs Lisp, we have these things called "buffer-local variables", which are an abomination from the lispy point of view, but awfully useful in practice. Horrible kludges exist to implement such things, and upgrading that mechanism to be extent-specific is IMHO not a good idea. Note that extent-local keymaps are perfectly fine because "keymap" is already an Emacs-only notion which carries all kinds of magic with it. If that magic is extent-local, that's just fine. Not so with variables. We already have that, sort of. In XEmacs, font-lock regexps are a property of the major mode symbol. This means that in the future, an intelligent font-locker can just look at the major mode in an extent and apply its font-lock regexps there. That works, but then you have to use narrowing -- there's no way to create an indirect buffer out of a *part* of a buffer's contents. And ultimately, the indirect buffer solution is suboptimal because it entails using a separate buffer in a separate window, which is not what the user wants. In this case, indirect buffers are merely a kludge to work around implementation deficiencies. Good luck!