bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6174: 23.2; mouse-sel-mode doc is misleading


From: Drew Adams
Subject: bug#6174: 23.2; mouse-sel-mode doc is misleading
Date: Tue, 11 May 2010 13:05:18 -0700

emacs -Q
 
Admittedly, I don't know what I'm talking about when it comes to
mouse-sel-mode.  I don't think I even knew it existed, but perhaps I
looked at it years ago - I see that it has been around a long time.
 
Reading the doc, both doc strings and source-file comments, my
impression is that the doc is very misleading.
 
>From what I could gather by experimenting, 99.99% of the behavior that
is documented is already the mouse behavior in Emacs, that is, with
mouse-sel-mode turned off.
 
AFAICT, the only real difference is that when the mode is turned on the
selection is not copied to the kill-ring.  The kill-ring is unaffected,
except if you do some specific extra things.
 
I'm probably missing something here, so please clue me in.  It seems
unlikely that that would be the only, or even the main, difference,
given that so much of the doc speaks about selecting.  But when I try
the things it says about selection (double-clicking, mouse-1 mouse-3,
etc.) they all seem to be the vanilla behavior with emacs -Q.
 
Anyway, if I'm at all on target here, then I suggest that the doc should
be cleaned up - and possibly the mode renamed, to reflect the fact that
it does *not* change how things are selected (very much, if at all), but
rather it changes what happens to the selection (not copied to the
kill-ring).
 
If I had to guess, I'd guess that this doc has never been updated since
Emacs itself adopted the same selection behavior.  And that was eons
ago.  IOW, maybe mouse-sel-mode was just the first code to provide such
behavior - dunno.
 
In GNU Emacs 23.2.1 (i386-mingw-nt5.1.2600)
 of 2010-05-08 on G41R2F1
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/xpm/include'
 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]