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
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:
james(a)eecs.ukans.edu (Jerry James) writes:
> Attached is the result of my effort. I've used it for awhile today
> and it hasn't exploded yet. Give it a whirl.
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.
I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.
for the hell I've been