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: Wed, 04 Dec 2013 15:18:39 -0500 Message-ID: References: <8761ra7uq3.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1386188336 17396 80.91.229.3 (4 Dec 2013 20:18:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Dec 2013 20:18:56 +0000 (UTC) Cc: Andrew Hyatt , Tom , emacs-devel To: Bozhidar Batsov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 04 21:19:00 2013 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 1VoIuS-0006qE-99 for ged-emacs-devel@m.gmane.org; Wed, 04 Dec 2013 21:19:00 +0100 Original-Received: from localhost ([::1]:50206 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VoIuR-0005Ql-PP for ged-emacs-devel@m.gmane.org; Wed, 04 Dec 2013 15:18:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VoIuH-0005PD-0E for emacs-devel@gnu.org; Wed, 04 Dec 2013 15:18:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VoIu9-0004q5-79 for emacs-devel@gnu.org; Wed, 04 Dec 2013 15:18:48 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:42481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VoIu9-0004pz-1p for emacs-devel@gnu.org; Wed, 04 Dec 2013 15:18:41 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFxL6g/2dsb2JhbABEvw4Xc4IeAQEEAR05IxALNBIUGA0kiB4GwS2NDYN9A4hhnBmBXoMVgUg X-IPAS-Result: Av4EABK/CFFFxL6g/2dsb2JhbABEvw4Xc4IeAQEEAR05IxALNBIUGA0kiB4GwS2NDYN9A4hhnBmBXoMVgUg X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="41148733" Original-Received: from 69-196-190-160.dsl.teksavvy.com (HELO pastel.home) ([69.196.190.160]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 04 Dec 2013 15:18:40 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 08A2260045; Wed, 4 Dec 2013 15:18:39 -0500 (EST) In-Reply-To: (Bozhidar Batsov's message of "Wed, 4 Dec 2013 18:08:57 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.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:166088 Archived-At: >> cua-mode I don't think this can be default in the foreseeable future. We can (and do try to) make it super-easy to enable it, but it's hard to go much further than that, given the inherent difficulties and associated occasional quirks. >> cua-selection-mode IIRC this is basically delete-selection-mode, so I'll disregard it. >> column-number-mode We could enable this. I hadn't noticed it as a popular choice, but if people like it, I have no particular objection and AFAIK the code is ready for it. [ I don't use it myself, but I probably wouldn't bother disabling it either. ] >> delete-selection-mode I do not want to enable delete-selection-mode in its current state. I would welcome a new interactive-form element (along the lines of "^") which would cause deletion of the region if active, and which could be added to self-insert-command, yank, and a few others. Maybe under the control of a new value of `delete-active-region'. Once this is done, I'd have no technical objection to enabling it by default, tho I don't know if that's really the desire of the majority. [ I don't use it myself, and I'd probably disable it for my own use. ] >> desktop-save-mode IIUC there's no technical hurdle either. I dislike the functionality (the whole point of restarting Emacs, for me, is to get rid of the umpteen frames and buffers ;-). But if most people like it... >> dired-x No opinion on this one (I basically don't use dired). >> global-linum-mode linum is buggy, so it's not an option. nlinum-mode would be a better choice, but the potential performance issues, together with the extra screen real-estate used up... I have a hard time believing that most people would want it enabled everywhere. >> global-subword-mode Hmm... never thought about it, but I guess I could see why that could be popular. I haven't looked much at the implementation, but other than that I could go along with it. >> icomplete-mode I see icomplete as "the way to add ido/iswitchb functionality to the default completion", so I like it in this sense, but I'm not sure about enabling it by default. I had it enabled in my .emacs but got rid of it at some point, can't remember why. >> iswitchb-mode Obsolete. >> recentf-mode I see no reason not to enable it, indeed. >> savehist-mode >> saveplace Actually, for these (as for recentf-mode), I do remember one reason: when multiple Emacsen as running at the same time, they all want to change the same file(s) and end up stepping on each others's toes. So if we want to enable these, we'd first need to address this technical issue. >> show-paren-mode Too much in your face for me. It doesn't seem to be that popular. >> size-indication-mode Uses up too much mode-line estate, IMO. I instead use the relative size of the scrollbar thumb as an indicator of the total file size. >> uniquify Already enabled by default now. >> which-function-mode It can be a bit unreliable, but enabling it might be an opportunity to fix those issues. It does seem to call for a improvement on mode-line length (probably by auto-contracting some of its elements, such as the buffer name, the mode names, ...). >> winner-mode I could go along with that. Tho I'd also like to see more generally improved handling of window-state handling (ability to save&restore window-states. We can do that via window-configurations in registers, but it only works in a single frame, and can't be saved, and I feel like registers are "too hard to find"). Stefan