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

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

[Drew Adams]

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'
 

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

[Lars Magne Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> 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.

[...]

> 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.

Yes, looking at the documentation, I think that's right.

Perhaps mouse-sel-mode should be marked as deprecated?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Stefan Monnier]

>> 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.

> [...]

>> 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.

> Yes, looking at the documentation, I think that's right.

> Perhaps mouse-sel-mode should be marked as deprecated?

Probably.  Let's do that for Emacs-24.2.


        Stefan

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

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Probably.  Let's do that for Emacs-24.2.

Is there a tag in debbugs for "wait until later"?  It seems it might be
handy, especially since we're going into a feature freeze...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> Is there a tag in debbugs for "wait until later"?  It seems it might be
> handy, especially since we're going into a feature freeze...

You can add whatever "usertags" you like; see admin/notes/bugtracker.

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

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> Lars Magne Ingebrigtsen wrote:
>
>> Is there a tag in debbugs for "wait until later"?  It seems it might be
>> handy, especially since we're going into a feature freeze...
>
> You can add whatever "usertags" you like; see admin/notes/bugtracker.

Right.  If we want to have such a tag (that would mean "this will have
to wait until the next release"), we should probably standardise on a
single flag, though.

What about "pending"?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> Right.  If we want to have such a tag (that would mean "this will have
> to wait until the next release"), we should probably standardise on a
> single flag, though.
>
> What about "pending"?

I was thinking of something more specific like:

user emacs24.2
usertags fixme

but since "pending" is sufficiently general to be applicable to other
debbugs packages (and since bugs.debian.org supports it), you can have
that as a "normal" tag, if "the Emacs community" would like such a tag.

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

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> I was thinking of something more specific like:
>
> user emacs24.2
> usertags fixme
>
> but since "pending" is sufficiently general to be applicable to other
> debbugs packages (and since bugs.debian.org supports it), you can have
> that as a "normal" tag, if "the Emacs community" would like such a tag.

What do the rest of you think?

The suggestion is to add the flag "pending" for stuff that should be
done (and we know how to do; like with a patch or the like), but that
has to wait until after Emacs is opened up for new features the next
cycle.

This is not for "wishlist" stuff, but concrete fixes that should be
applied, but not right now.

The idea is that once the next cycle starts (in this case, Emacs 24),
one could then go through all the "pending" bug reports pretty speedily
and apply the stuff then.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Michael Welsh Duggan]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Glenn Morris <rgm@gnu.org> writes:
>
>> I was thinking of something more specific like:
>>
>> user emacs24.2
>> usertags fixme
>>
>> but since "pending" is sufficiently general to be applicable to other
>> debbugs packages (and since bugs.debian.org supports it), you can have
>> that as a "normal" tag, if "the Emacs community" would like such a tag.
>
> What do the rest of you think?
>
> The suggestion is to add the flag "pending" for stuff that should be
> done (and we know how to do; like with a patch or the like), but that
> has to wait until after Emacs is opened up for new features the next
> cycle.
>
> This is not for "wishlist" stuff, but concrete fixes that should be
> applied, but not right now.
>
> The idea is that once the next cycle starts (in this case, Emacs 24),
> one could then go through all the "pending" bug reports pretty speedily
> and apply the stuff then.

Glen Morris's suggestion above attaches a specific version to the tag
(possibly in a non-standard fashion).  I think a pending flags is just
fine, but it needs to be attached to a version number somehow.
Otherwise it is inevitable that a report with the pending tag will
remain "pending" at the time of the next release, with no one possibly
realizing that it was meant for that release, and not the one
succeeding.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

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

[Stefan Monnier]

>> The suggestion is to add the flag "pending" for stuff that should be
>> done (and we know how to do; like with a patch or the like), but that
>> has to wait until after Emacs is opened up for new features the next
>> cycle.

Sounds good, tho IIUC debbugs already has a notion of "pending" as a bug
state, so maybe we should use another word, such as "postpone".

> Glen Morris's suggestion above attaches a specific version to the tag
> (possibly in a non-standard fashion).  I think a pending flags is just
> fine, but it needs to be attached to a version number somehow.
> Otherwise it is inevitable that a report with the pending tag will
> remain "pending" at the time of the next release, with no one possibly
> realizing that it was meant for that release, and not the one
> succeeding.

That's a risk, indeed.  We could use a script to un-postpone all bugs
whenever the new branch is opened.

OTOH, we've used a different approach in the past: create a new branch
`pending' and install patches there.


        Stefan

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

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Perhaps mouse-sel-mode should be marked as deprecated?
>
> Probably.  Let's do that for Emacs-24.2.

I've now marked it as obsolete.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Chong Yidong]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> Perhaps mouse-sel-mode should be marked as deprecated?
>>
>> Probably.  Let's do that for Emacs-24.2.
>
> I've now marked it as obsolete.

Thanks.  In the future, please remember to add a note to NEWS when you
make packages obsolete (done in trunk).