David Kastrup <[EMAIL PROTECTED]> writes: >> My preferences remained unchanged but I also think it must be >> confusing for a novice user. Before I was aware of the time limit, I >> didn't understand why clicking mouse-1 sometimes popped to a new >> buffer and other times didn't. > > I am afraid that the same is the case here. I have > focus-follows-mouse set here by default in the window manager, so I > don't expect clicks that don't do anything. The current behavior > (where a window change does not follow links at all) is more confusing > than the previous one.
This really hasn't anything to do with focus-follows-mouse. What if you set mouse-autoselect-window ? In any case, I agree that last modification isn't perfect, and I'll think about what to do. > > Kim, I am aware that you hate double clicks. However, for the > I-hate-something proponents there is always the possibility of using > customize to change the default. > > 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. This > property would only be present in clearly "clickable" situations such > as buttons or Info references, but not where there is basically normal > text with clickable properties (like in a grep buffer or in the > headers of gnus buffers). IMO, this has nothing to do with the default of mouse-1-click-follows-link. It is a problem of those modes which basically make large parts of a buffer mouse-2 click-able and then uses a too primitive form of the `follow-link' functionality. So grep and gnus should not just say that mouse-1 blindly maps to mouse-2. > The current scheme also steals the potential to double-click, anyway, > since the first short click already follows the link, and a > double-click by click and hold long, then leave the button very short > and click again, this time short... that's not something you manage > if you are not a piano player, anyway. If so, it is a bug. The code specifically tests to see if there is a second click within double-click-time and generates a double click rather than two separate clicks. > > It's nice if everything else we have tried out is available as a > customizable option, but by default, I think we should remap only the > double click when not asked for, and the normal single click (of _any_ > duration) when asked for. So change grep and gnus... -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
