Hrvoje> Glad to see your face again, Karl! :) And your's too, Hrvoje. Hrvoje> psu25682(a)odin.cc.pdx.edu (Karl M. Hegbloom) writes: Hrvoje> I thought about this some time ago, and I must say I don't Hrvoje> like this solution. While it's true that Emacs Lisp is Hrvoje> already divergent from any other Lisp, adding extent-local Hrvoje> variables would add new meaning to the notion of Hrvoje> divergence. Did I miss anything while I was gone regarding lexical scoping, packages, or lisp object systems for XEmacs? Hrvoje> In Lisp, the value of a variable should be just that. In Hrvoje> Emacs Lisp, we have these things called "buffer-local Hrvoje> variables", which are an abomination from the lispy point Hrvoje> of view, but awfully useful in practice. Horrible kludges Hrvoje> exist to implement such things, and upgrading that Hrvoje> mechanism to be extent-specific is IMHO not a good idea. I will keep these things in mind when I begin reading the XEmacs code. I've got a few chapters to go in several books before I'll feel fully prepared to do so... And lots to do at the same time. I'm antsy for it. One namespace thing that I think XEmacs is in dire need of is a thing like Common Lisp's `defpackage' or `in-package'. Even if it's faked by just interning the symbols that are logically part of a pseudo-package into the global obarray by prefixing them with the package name and a :: or something... Like (intern (concat pkg-name "::" sym-name)). Some might call it kludgey, but it would logically be it's own namespace, sort of. And inside an .el module, you wouldn't need to prefix all your symbols by hand. There must be advantages to real namespace packages though. Wouldn't that require then another field in the symbol's C structure, a pointer to the package's obarray it belongs to? Then the lookup routines would need to look at that to see which obarray to search in. I'll research this stuff also, BEFORE I even peek at the XEmacs Lisp engine again. (no promises about not peeking at all...) Hrvoje> Note that extent-local keymaps are perfectly fine because Hrvoje> "keymap" is already an Emacs-only notion which carries all Hrvoje> kinds of magic with it. If that magic is extent-local, Hrvoje> that's just fine. Not so with variables. Hmmm... but there are extent properties, which could be used like variables; they are part of that extent's "environment". Hrvoje> We already have that, sort of. In XEmacs, font-lock Hrvoje> regexps are a property of the major mode symbol. This Hrvoje> means that in the future, an intelligent font-locker can Hrvoje> just look at the major mode in an extent and apply its Hrvoje> font-lock regexps there. Ahhh! Yes, so the font locker could... hmmm... Look and see if there's a certain type of extent extant (ah, one with a `major-mode' property set), and look on that extent's `:major-mode' property, using that information to determine how to font lock there, amoung other things. (and again, here's another area I need to research. I want to get back into XEmacs stuff again.) An infrastructure and API for this ought to be planned and built, I suppose. I'd like to see :keywords used more, I think... (The minor mode stuff too, right?) Hrvoje> That works, but then you have to use narrowing -- there's Hrvoje> no way to create an indirect buffer out of a *part* of a Hrvoje> buffer's contents. Perhaps if there was a thing that made that other buffer appear in another window when you moved your cursor into the region and hit the kludge pedal... I think it would be annoying to use. And perhaps once you've gone through the trouble of setting that up, you may as well have implemented the better solution above, though that will be more planning and work to do properly. Hrvoje> And ultimately, the indirect buffer solution is suboptimal Hrvoje> because it entails using a separate buffer in a separate Hrvoje> window, which is not what the user wants. In this case, Hrvoje> indirect buffers are merely a kludge to work around Hrvoje> implementation deficiencies. Yes. What are indirect buffers good for? What is their reason for existing? How are they used? Hmmm... I guess you could use them to provide multiple views on data in some way or another... Raw CSV in one, and formatted in another, perhaps? Or the same data interpretted in two different ways? YTMAWBK. Hrvoje> Good luck! Yes, thanks... in light of my monitor glowing all this email at me, it's a good thing there's LaTeX to do math with or it would be no fun and I'd never get my assignments completed. :-)