From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Finding packages to enable by default Date: Thu, 19 Jun 2014 11:26:40 -0400 Message-ID: References: <87ob4fg3zp.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1403191657 26790 80.91.229.3 (19 Jun 2014 15:27:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Jun 2014 15:27:37 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 19 17:27:30 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WxeFO-0006On-9M for ged-emacs-devel@m.gmane.org; Thu, 19 Jun 2014 17:27:30 +0200 Original-Received: from localhost ([::1]:36303 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxeFN-0007zv-RL for ged-emacs-devel@m.gmane.org; Thu, 19 Jun 2014 11:27:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxeEm-0007F4-HL for emacs-devel@gnu.org; Thu, 19 Jun 2014 11:27:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WxeEc-0004Y1-Af for emacs-devel@gnu.org; Thu, 19 Jun 2014 11:26:52 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:58659) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxeEc-0004Xw-5X for emacs-devel@gnu.org; Thu, 19 Jun 2014 11:26:42 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNLd+D9/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBVigLCzQSFBgNiCgI0hkXjwGEOASpGYFqg0wh X-IPAS-Result: ArUGAIDvNVNLd+D9/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBVigLCzQSFBgNiCgI0hkXjwGEOASpGYFqg0wh X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="68267422" Original-Received: from 75-119-224-253.dsl.teksavvy.com (HELO pastel.home) ([75.119.224.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 19 Jun 2014 11:26:41 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id EEC1E60D16; Thu, 19 Jun 2014 11:26:40 -0400 (EDT) In-Reply-To: <87ob4fg3zp.fsf@gmail.com> (Jambunathan K.'s message of "Tue, 17 Dec 2013 16:04:50 +0530") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172533 Archived-At: > 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- 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