From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rusi Newsgroups: gmane.emacs.help Subject: Re: use-package Date: Sat, 14 May 2016 00:37:43 -0700 (PDT) Message-ID: <9a592c77-4531-414a-a644-988800cdbeb6@googlegroups.com> References: <874magv15u.fsf@mat.ucm.es> <87d1p38ll6.fsf@mat.ucm.es> <87y47pg5da.fsf@russet.org.uk> <87shxwzkzg.fsf@russet.org.uk> <87d1outgo2.fsf@russet.org.uk> <87y47f7zt1.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1464882603 1464 80.91.229.3 (2 Jun 2016 15:50:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Jun 2016 15:50:03 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jun 02 17:50:02 2016 Return-path: Envelope-to: geh-help-gnu-emacs@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 1b8Usd-0000Qn-HP for geh-help-gnu-emacs@m.gmane.org; Thu, 02 Jun 2016 17:49:55 +0200 Original-Received: from localhost ([::1]:48134 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8Usc-0003Db-It for geh-help-gnu-emacs@m.gmane.org; Thu, 02 Jun 2016 11:49:54 -0400 X-Received: by 10.140.27.135 with SMTP id 7mr13342309qgx.9.1463211463898; Sat, 14 May 2016 00:37:43 -0700 (PDT) X-Received: by 10.36.50.129 with SMTP id j123mr96384ita.2.1463211463719; Sat, 14 May 2016 00:37:43 -0700 (PDT) Original-Path: usenet.stanford.edu!11no4258281qgt.0!news-out.google.com!k10ni26igv.0!nntp.google.com!i5no8344448ige.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=59.88.164.37; posting-account=mBpa7woAAAAGLEWUUKpmbxm-Quu5D8ui Original-NNTP-Posting-Host: 59.88.164.37 User-Agent: G2/1.0 Injection-Date: Sat, 14 May 2016 07:37:43 +0000 Original-Xref: usenet.stanford.edu gnu.emacs.help:217688 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:110212 Archived-At: On Friday, May 13, 2016 at 9:09:09 PM UTC+5:30, Drew Adams wrote: > Making a blanket, one-size-fits-all judgment for everyone > takes choice away from users. : : > I'm all for such a possibility. What I am not for is > Emacs imposing or recommending this or that look & feel > in some blanket way. > > Let a hundred flowers bloom. Vive the mode line. etc Just consider me in the opposite camp. Everything else being equal too much choice is a bad thing: https://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice One could go further and DEFINE freedom as choicelessness. While I wont do that I will say that emacs is progressing from the best software category to suxware category by offering too much bogus choices - .emacs.d/init.el or .emacs - custom-file or let customize mess your init - setq or customize - half a dozen options to specify keybindings - eval-after-load or add-hook or simple-setq (+prayer that the mode author followed norms) I could go on But I think you get the idea -- Choice is undesirable if there is any choice about making the choice Most recent example of bogus choices haskell mode has been upgraded to some new fancy beyond-comint stuff But the old comint is still there -- if you like -- Choice after all is wonderful. Result: What used to work OTB now needs to have explicit define-keys to make sure user chooses old or new interface