>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes:
Hrvoje> Glad to see your face again, Karl!
:) And your's too, Hrvoje.
Hrvoje> psu25682(a)odin.cc.pdx.edu (Karl M. Hegbloom) writes:
>> I've thought about that a little bit... Someone else posted
>> about something like this a while ago also. You'd have to have
>> "extent local" modes to do that, he thought, with different
>> sets of extent-local variables for font-locking and suchlike to
>> work inside those tags. Extents already have their own keymap,
>> so you can bind, for instance, a different indenter function to
>> TAB, only inside that extent.
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".
>> You could then make a mode for your .jsp files that wrapped an
>> extent around the Java part, giving that it's own set of
>> keybindings. Over the whole buffer then, you'd need your own
>> set of font-lock-keywords, that can handle both the HTML part
>> and the Java part.
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?)
>> There is also a thing called an indirect buffer... You can make
>> an indirect buffer of a buffer, and put that into a different
>> mode.
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.
>> I need to go eat then do my math.
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. :-)
