David Kastrup <[EMAIL PROTECTED]> writes: > 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
I looked at grep and gnus group buffers which have been presented as examples of the problems with the follow-link property. In both cases, the follow-link property is set to "mouse-face" meaning that only areas which have the mouse-face property in those buffers will map mouse-1 to mouse-2. In gnus group buffer, the mouse-face is put on the group name only, so it is easy to set point on a group line without entering that group. In grep buffers, it seems that (almost) full lines are highlighted with the mouse-face -- so practically the whole buffer is "mouse-1" aware. As I suggested earlier, one simple solution would be to only put mouse-face on the file:line: part, but this was rejected by some of you (who wants to have his cake and eat it too :-) To me it would be hard to explain to novice users why following a mouse-face highlighted link in an info or help buffer is "opened" with a single click, but a similarly highlighted group name in a gnus buffer need a double 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, If those large areas have mouse-face, it seems appropriate to me. At least it could be a different mouse-face if they require a double click. -- 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
