Nick Roberts <[EMAIL PROTECTED]> writes: > > The grep buffer is an example. If I try to place the cursor anywhere on > > a line before the end of a match, the associated file pops up in > > another buffer. However I might just want to select that window to > > resize it. > > > > When you found this not to your taste, were you aware about the aspect > > that Mouse-1 does not follow links if you move the mouse at all? > > No. I wasn't aware of that. With the default setting, the user would have to > move the mouse and release it within 350 milliseconds for it to have any > effect. I think must be quite hard to do. > > > Is that method of avoiding the problem adequate? > > 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. 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). A double click can never be confused with a "click just to shift point/focus". It is conveniently available on even single-key mouses and its behavior does not need 5 sentences to explain. The confusion potential is just with mark-word, and that is tolerable in clickable situations. 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. 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. Secret timing differences and stuff like that are much too subtle _unless_ the user configured them himself, in which case he'd know about them. That is the default behavior of most applications, and I don't see that the alternatives we have tried so far would be so much better as to warrant getting people used to them instead. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
