-- Jerry James <james(a)eecs.ukans.edu&gt; spake thusly: It probably wouldn't hurt to add this stuff, but XEmacs already supports links in "Hyper Help" buffers, which are accessed by the hyper-* functions (for instance, try doing M-x hyper-apropos). I do the following in startup.el: ;; Hyper-apropos bindings (define-key global-map [(control h) a] 'hyper-apropos) (define-key global-map [(control h) c] 'hyper-describe-key-briefly) (define-key global-map [(control h) f] 'hyper-describe-function) (define-key global-map [(control h) k] 'hyper-describe-key) (define-key global-map [(control h) v] 'hyper-describe-variable) (define-key global-map [(control h) w] 'hyper-where-is) (define-key global-map [(control h) A] 'apropos) (define-key global-map [(control h) C] 'describe-key-briefly) (define-key global-map [(control h) F] 'describe-function) (define-key global-map [(control h) K] 'describe-key) (define-key global-map [(control h) V] 'describe-variable) (define-key global-map [(control h) W] 'where-is) Perhaps it would be a good idea to make something like this the default (or is there a way to easily get something similar?).

BTW Hrvoje, as part of getting this to work i implemented a more general concept of "activation" and "activation strokes". for example, clicking on a hyperlink in a text buffer is an activation, where what should be activated is determined by properties on the objects underneath the mouse [extent properties, glyph properties, buffer-local variables, etc]. the idea is to separate out the *concept* of activation from the particular mouse strokes that enable the activation. For example, button2 to activate is kind of weird, so I might want to allow button1 to activate as well. With the activation framework, I can simply do this by configuring a variable, provided that all modes that have "action on button2" or whatever rewrite things to use the activation mechanism instead of directly binding button2 to something in a keymap. [one side effect of this is that button2 by default is bound to mouse-track, as well as button1. Eventually, so should button3 and all button keystrokes -- the keymap model is simply not the right model for mouse buttons. We want a way to bind different commands [and possibly more than one, to be run in sequence], to various button operations, such as down, up, click, double-click, begin drag, end drag, begin double drag [double click merging into a drag], etc. currently i do this with hooks. i have some more work on planning on doing on this, including allowing for different activation "styles" that would allow more or fewer mouse strokes to activate -- e.g. in Info, About-Page, and similar "pure hypertext" modes, we pick the most permissive style, so that button1-click always activates. in Completion modes and others, we pick a mid-permissive style, where button1-click can activate or can not, depending on user prefrence. in Grep modes and such where the entire buffer is a hot link, we pick a non-permissive style, where button1-click will never activate. Hrvoje Niksic wrote: -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through.

-- Ben Wing <ben(a)666.com&gt; spake thusly: Again, isn't this what "Hyper Help" is for? Am I confused? If not, would it make more sense to just merge them, instead of adding the functionality to help in a (probably) different way?