From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Is Elisp really that slow? Date: Thu, 16 May 2019 20:46:42 +0300 Message-ID: <838sv6cmwt.fsf@gnu.org> References: <20190514235412.kncazq45szlum2gr@Ergus> <83v9yb92c7.fsf@gnu.org> <878sv7sp3r.fsf@telefonica.net> <83r28z8zl9.fsf@gnu.org> <20190515210924.sijzy6mnpgzkt4gm@Ergus> <83ftpecwu1.fsf@gnu.org> <20190516161408.4dov3dwk5h4yoizn@Ergus> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="86204"; mail-complaints-to="usenet@blaine.gmane.org" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu May 16 19:47:06 2019 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hRKTA-000MGB-Kt for geh-help-gnu-emacs@m.gmane.org; Thu, 16 May 2019 19:47:04 +0200 Original-Received: from localhost ([127.0.0.1]:33361 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRKT9-0001Ya-43 for geh-help-gnu-emacs@m.gmane.org; Thu, 16 May 2019 13:47:03 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34421) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRKSz-0001YP-AE for help-gnu-emacs@gnu.org; Thu, 16 May 2019 13:46:54 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:56065) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRKSz-0007mR-7f for help-gnu-emacs@gnu.org; Thu, 16 May 2019 13:46:53 -0400 Original-Received: from [176.228.60.248] (port=1702 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hRKSy-0001gL-30 for help-gnu-emacs@gnu.org; Thu, 16 May 2019 13:46:52 -0400 In-reply-to: <20190516161408.4dov3dwk5h4yoizn@Ergus> (message from Ergus on Thu, 16 May 2019 18:14:08 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:120445 Archived-At: > Date: Thu, 16 May 2019 18:14:08 +0200 > From: Ergus > Cc: help-gnu-emacs@gnu.org > > >> We are far from becoming a toxic community, but new/different ideas are > >> not really very welcome and sometimes the arguments are like "it has > >> always been like that", "old users don't want that change". > > > >Really? You've just went through a process of proposing and > >implementing a new feature -- did you feel your idea was "not really > >welcome"? > > > Actually fill-column-indicator was something that many people were using > (with the package) but it doesn't affect the global behavior at > all. It's a reimplementation in core of a popular feature. I think you are wrong: I'm sure quite a few people will be happy to see it alive and much faster than the Lisp implementation that is no longer maintained. > But when we mention (propose, suggest) to do any change in the defaults > or remove obsolete functionalities to promote new ones, or change old > features to add more modern ones... the mailing list starts becoming > crazy. Emacs is an old program, with users who stay with it for 25 and more years. Changing old defaults or making other incompatible changes definitely annoys at least some of those users, especially since quite a few people don't track the development, and don't see the changes until years later, sometimes even after skipping several releases in-between. This isn't theory, this is our (and my personal) actual experience from watching Emacs development. When someone comes up and asks why we made a certain change in how Emacs worked for decades, we should have a good reason, and if we don't, we shouldn't make the change "just because we can". That's the price of maintaining and developing an old and stable program. Personally, I wish people would invest much more time and efforts in adding new features, and would stop futzing with existing features. For starters, the former is much more useful for our users than the latter. Also, I see many times how a change in existing code to make some minor improvement introduces bugs, which sometimes are more significant than the "fixed" problem -- this is expected in a complex stable program, and is a clear sign that changes of existing code long since entered the area which engineers call "the limit cycle" -- oscillations that don't converge, i.e. the overall code quality is quasi-constant. IOW, we are wasting our own resources for little or no gain. > Just give a look how many good packages are in melpa, but not in elpa If you are saying that those packages are in MELPA because they were rejected to be included in Emacs or ELPA, then I'd be very surprised to learn that this is true. I think the vast majority of those packages started up with MELPA and their developers never tried to submit the packages to be included in Emacs.