RE: Finding packages to enable by default

[Drew Adams]

FWIW -

> > | abbrev-mode                                      |      30 |
> > | auto-fill-mode                                   |      30 |
> > | column-number-mode                               |      70 |
> > | delete-selection-mode                            |      25 |
> > | dired-x                                          |      33 |
> > | eldoc-mode                                       |      36 |
> > | flyspell-mode                                    |      41 |
> > | show-paren-mode                                  |      65 |
> > | ibuffer                                          |      45 |
> > | ido-everywhere                                   |      31 |
> > | ido-mode                                         |      60 |
> > | recentf-mode                                     |      43 |
> > | windmove                                         |      30 |
> > | winner-mode                                      |      35 |

> I edited the table to remove the modes that are already enabled by
> default in 24.4 (as well as removing the major modes which aren't
> really applicable to this discussion anyway).

You edited the table where?  The table is on Emacs Wiki:
http://www.emacswiki.org/emacs/FrequentlyEnabledPackages_Emacs244_Survey
It was last updated yesteday by Brian Kavanagh.  140 users have now
recorded their use data there.  The figures you cite are apparently
from Jambuhathan's mail of 2013-12-17 (when 120 users were reported).

For the same libraries you cite, for example, the wiki page now shows:

| abbrev-mode                                         |      41 |
| auto-fill-mode                                      |      44 |
| column-number-mode                                  |      92 |
| delete-selection-mode                               |      33 |
| dired-x                                             |      47 |
| eldoc-mode                                          |      52 |
| flyspell-mode                                       |      56 |
| show-paren-mode                                     |      87 |
| ibuffer                                             |      61 |
| ido-everywhere                                      |      45 |
| ido-mode                                            |      84 |
| recentf-mode                                        |      59 |
| windmove                                            |      39 |
| winner-mode                                         |       8 |

(I have no explanation for why or how winner-mode went down.  I
suspect that someone introduced a typo when editing it, but that
part of the history is not available AFAIK.  I and others have been
keeping an eye out for mistakes, but this checking was done manually,
and was clearly error-prone.)

[delete-selection-mode]
> We've been getting closer to this one over time, so we may get there at
> some point.  I'm not completely sure we're ready for it yet.  But in any
> case, I don't like the current implementation, so before we can switch
> someone will have to re-implement it along the same lines as what was
> done for the shift-select-mode, i.e. have the affected command call the
> delete-selection code themselves, rather than use a pre-command-hook.

Please write a new library for that (like you did for linum.el etc.).
Please leave the design of delsel.el and `delete-selection-mode' alone.

> If you look at delsel.el, you'll see that few commands are affected,
> and changing self-insert-command would be sufficient to cover a few
> of the other ones as well, so the changes should really be pretty small.

Each time this has been talked about, the interface for programmers
of what you have proposed has not been at all like that of delsel.el,
which is simple to use and flexible: just set a property on a command.

I know the downside to that design (your objections), but I also
appreciate the upside (just mentioned).  I hope you will not simply
jettison the longstanding design for something less lispy.

Or rather, that would be welcome, as long as it is a separate (new)
library.  I don't even mind if you deprecate the old design (i.e.,
delsel.el) as far as GNU Emacs is concerned, as long as users can
still find and use it.

I would object to its wholesale replacement by another design under
the same names: delsel.el and `delete-selection-mode'.  Instead,
please do what you did for nlinum.el vs linum.el and your new advice
thingy vs defadvice, if you want to try a new design.

Just one opinion.