Richard Stallman <[EMAIL PROTECTED]> writes: > In order not to confuse people too much, I really would want to > suggest strongly that we remap double-click to mouse-2 unconditionally > by default (where a "stronger" mouse-2 binding exists), and also map > mouse-1 to the same when the special "link" property is present. > > I do not see any sense in this proposal. That idea for double-click > seems completely inconsistent with the overall scheme that we have > adopted.
The "overall scheme" that we have adopted historically is that any hyperlink or action is done with mouse-2. That is perfectly consistent and nobody has argued that it should be removed, The problem that we are trying to address here is that a) it is also completely unexpected to new users, b) mouse-2 is inconvenient on a _lot_ of touch pads and mice and often has to be done by chording. Outside of the world of Emacs, triggering actions has traditionally been done by double-clicking mouse-1. Remapping this double click will give new users _one_ sort of behavior they are accustomed to from both MacIntosh and Windows applications, as well as a lot of X11 dialogs (where double clicking usually means select and take a choice directly, like in a file dialog). It will also give experienced users with a two-button device a more convenient way to trigger an action. One common action triggered nowadays is following links. In browsers and increasingly also on desktop objects, the trend has been going to do this action with a single mouse-1 click. Since mouse-1 is rather commonly used for setting point in Emacs, having large areas behave like that in Emacs does not seem appropriate, even while Customize buttons and similarly sharply confined objects are likely to be recognized as something where one would not want to place point. Using a special link property on them could achieve the remapping of mouse-1 only on those areas. Something that looks like a button is a candidate for single click, and so is a hyperlink marked as a cross reference. That's two simple additional rules: a mouse-triggerable action can be additionally to the old mouse-2 binding also be triggered with a double-click on mouse-1, and on specially marked links, the same action can be done with even a single mouse-1 click. That is all. If you take a look at the complexity of the other approaches that have been suggested, like making a single click follow links, and a double click set point (in strict violation to the Emacs Lisp guidelines for double clicks), and with half a dozen exceptions like "don't follow link if pressed for longer than this" and "don't follow link if we have the first click in a frame" and "don't follow link if we have the first click in the window", the recipe I propose does a) need no special treatment of the first click into a window: if one explicitly aims at a small button, the guess "follow link" is reasonable. If one aims at a larger actionable area, the default action of "set point" does no harm. b) is consistent with the double-click action policy set out in the Elisp manual: the double-click action must work sensibly even if the single-click action has already been triggered. c) does not need special treatment of a double-click into a window: if the double-click is passed by the window-manager, then it is reasonable to take the action even when the frame or window did not have selection and/or focus previously. The additional possibilities for triggering actions on areas with doubleclicking mouse-1, and actions on specially marked, narrowly confined buttons/linked with singleclicking mouse-1, are just two additional possibilities/rules in addition to the old "mouse-2 for triggering anything" rule that is already violated, say, in Customize. My proposal is consistent with the double-click guidelines, it consists of just two rules that are easily accessible to a novice, it requires no special hold-longer times (for which we have no suitable descriptive keyboard events anyway, so you could not use C-h k or C-h w to find out about them), it requires no special treatment of first-click-to-frame/windoe and it provides functionality in a manner way more common in the world outside of Emacs than our current consistent but unusual and often inconvenient mouse-2. That you can't see _any_ sense in this proposal, in contrast to the complex, timing-dependent, rule-intensive, trick-requiring (like drag-if-you-don't-want-to-trigger-action) policy-violating, delayed-action-requiring other schemes that have both been proposed as well as implemented, I find somewhat surprising. I was of the opinion that at least _some_ sense might have been detectable in my proposal. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
