james(a)eecs.ukans.edu (Jerry James) writes: I just did. I like it, except for one annoyance: when I get a help screen, the frame is normally split in two windows, the original buffer in the upper window, the help contents in the window below. But when I middle-click on the hyperlink, the new help window shows up *above*! This is not only visually disconcerting, but also inconvenient because I now lost the buffer contents. One may argue that it's nice to have the room for two help windows, but this can be achieved in other ways. FSF Emacs also behaves the way I'd like XEmacs to behave, i.e. clicking doesn't pop up the hyperlink in a separate window.

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.

no, you're very right. i didn't realize this already existed, and yes, they should be merged. Matt Tucker 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.