Re: Finding packages to enable by default

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Just to keep you happy here is the table.

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

> | column-number-mode                               |      70 |

Since it's so popular, I think it makes sense to enable it by default.

> | show-paren-mode                                  |      65 |

In 24.4, we changed the blink-open-paren feature so it doesn't move the
cursor but instead highlights the open-paren with the same face as
show-paren-mode, so it brings the default a bit closer to show-paren-mode.

But given the popularity, we could consider enabling it by default.

> | ido-mode                                         |      60 |

I like several of IDO's features, but we can't just enable it by default
for various reasons:
- it does not support completion-styles.
- some use cases are very poorly supported (handled by escaping back to
  the "old" completion mechanism), which means that the UI ends up too
  complex for a default setting.
I don't see how to solve the first problem without spending serious
efforts re-writing important parts of ido.el.  And the second will/would
require changing the UI in ways which might not please IDO users (for
whom the extra UI complexity is a good tradeoff).

So as explained elsewhere already I think the way to move forward on
this front is by adding IDO-ish features to the default completion code.
`icomplete-mode' is one such feature and in 24.4 it has been extended to
get closer.
So if you use IDO, please try icomplete-mode instead (and add
`substring' to the `completion-styles').  If you then miss an IDO
feature, please M-x report-emacs-bug (and ideally provide a patch that
implements the feature).

> | ibuffer                                          |      45 |

I have the impression that it was decided at some point that the default
buffer-list be switched to Ibuffer.  I must have dreamt it, tho.
In any case, we can't perform such a switch right now, because Ibuffer
does not offer all the features of list-buffers.  The most glaring is
the header-line.
If someone could try and bring Ibuffer's default behavior closer to
list-buffers, then I think we could switch.

> | recentf-mode                                     |      43 |

I don't see any reason not to enable this by default.

> | flyspell-mode                                    |      41 |

I'd be happy to enable this by default, but we currently don't have
a `global-flyspell-mode', so we need someone to write one for us.
Such a global mode should be careful to only enable flyspell where it
"makes sense".  E.g. I think that by default in prog-mode buffers, only
strings and comments should be flyspell'd.

> | eldoc-mode                                       |      36 |

This is my pet missing feature when I run "emacs -Q", so yes, I want
this enabled by default.  Here also, tho, we first need
a global-eldoc-mode.

> | winner-mode                                      |      35 |

If we can come up with good keybindings, then we can indeed enable it
by default.

> | dired-x                                          |      33 |

Fine by me.

> | ido-everywhere                                   |      31 |

Hmm... the IDO discussion above was actually talking about
ido-everywhere.  I don't really like the idea of using completely
different completion UIs for files&buffers.

> | auto-fill-mode                                   |      30 |

In which modes?

> | abbrev-mode                                      |      30 |

Not sure what I think about this one.

> | windmove                                         |      30 |

I like this as well.  I'm a little worried about occupying the
S-<left/right/up/down> bindings, tho: it's pretty easy to keep the shift
modifier pressed inadvertently.

> | delete-selection-mode                            |      25 |

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.

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.

I think I'll stop here for now,


        Stefan