From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: xristos Newsgroups: gmane.emacs.devel Subject: Re: GNU Emacs raison d'etre Date: Thu, 21 May 2020 12:20:54 -0400 Message-ID: References: <871rnnvmdx.fsf@red-bean.com> <87pnb7sira.fsf@red-bean.com> <06bcddd4-6991-e4f7-e944-93de14af263d@yandex.ru> <87h7wjsd8o.fsf@red-bean.com> <20897f01-122d-7f91-eac2-70f5ad75796f@yandex.ru> <87d077qfmm.fsf@red-bean.com> <87y2pmw9ld.fsf@red-bean.com> <6e4190a4-765d-6abd-1ae2-8c1432c29d65@yandex.ru> <20200521080349.GC26656@tuxteam.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="43583"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tomas@tuxteam.de, emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 21 18:33:39 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jbo8X-000B6c-Lf for ged-emacs-devel@m.gmane-mx.org; Thu, 21 May 2020 18:33:37 +0200 Original-Received: from localhost ([::1]:42874 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbo8W-0000PU-N7 for ged-emacs-devel@m.gmane-mx.org; Thu, 21 May 2020 12:33:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47506) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbnyP-00086S-VW for emacs-devel@gnu.org; Thu, 21 May 2020 12:23:09 -0400 Original-Received: from mx.sdf.org ([205.166.94.20]:54876) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbnyO-000249-OU for emacs-devel@gnu.org; Thu, 21 May 2020 12:23:09 -0400 Original-Received: from samadhi.lan (ma.sdf.org [205.166.94.33]) (authenticated (0 bits)) by mx.sdf.org (8.15.2/8.14.5) with ESMTPSA id 04LGKtEW028932 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Thu, 21 May 2020 16:20:56 GMT In-Reply-To: (Arthur Miller's message of "Thu, 21 May 2020 11:33:25 +0200") Received-SPF: pass client-ip=205.166.94.20; envelope-from=xristos@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/21 12:20:57 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-Mailman-Approved-At: Thu, 21 May 2020 12:32:36 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:251176 Archived-At: On Thu, 21 May 2020 11:33:25 +0200,=20 Arthur Miller wrote: > Indeed. But for anything to live long, it needs to adapt to changs, and > software/IT community changes rapidly. That seems to be basic law of > evolution. Emacs does not seem to adapt despite being super adaptable > software package so well. Is community big enough to be sustainable in > long term? Emacs has lived long, hasn't it? It is certainly one of the longest-living pieces of software that I use daily. This could mean that Emacs has adapted well to changes in the field or that said changes were fads, not worth adapting to. Either way, it seems the model that lies at the core of Emacs has stood the test of time.=20 >> In my eyes, Emacs is doing an outstanding job on that. > Personally I don't think Emacs will go extinct any time soon, neither, > but what will happen in next 40 years?=20 No one can tell what will happen in the next 10 years, never mind 40. It is a mistake to make decisions by working backwards from a hypothetical projection rather than looking at the past and recognizing what has made Emacs truly unique: Its capacity to symbiotically [1] mold with the user and give raise to a metasystem [2] that is much more than the sum of its parts. If Emacs has a superpower, that is it. > Is it important though? But I would like to see bigger community now so > we get even more developers and even better Emacs :-) That would be nice, but Emacs should not compromise on its core values in order to achieve it. Emacs can not win going toe-to-toe with VSCode but it can certainly shift the arena from not-quite feature parity with fad-editor-of-the-decade [3] to doubling down on user-empowerment: A lot of Emacs users, even old users, don't see Emacs as anything more than an editor and haven't been exposed to the "moldable information processing tool" way of thinking. This should be addressed by us doing everything we can to shorten the time needed for a new user to first be fully exposed to this paradigm and subsequently ignite the molding process. I see Jo=C3=A3o admit that he's not familiar with a lot of the C-h commands. This is a problem that should be easy to fix. I've long seen the Emacs tutorial as unnecessarily narrow-minded in its focus on text editing. Richard mentioned a robot game but I suggest the tutorial be reworked instead to be much more extensive. It should first lay out the models that make Emacs powerful and then through exercises expose the user to said models and reinforce the central paradigm. That should include familiarization with all introspective commands, configuration and customization, how buffers and processes work, and a practical introduction to Emacs Lisp, including showing IELM and what one can do inside it (e.g. Set working buffer). I think this would go a long way towards letting users have a glimpse of the possibilities on offer. Emacs has great manuals but either very few newcomers read them or if they do, still don't get the big picture. An interactive, hand-on approach would surely work better. [1] https://groups.csail.mit.edu/medg/people/psz/Licklider.html [2] https://xristos.sdf.org/why-emacs.txt [3] That's not to say that Emacs should not provide VSCode features where it makes sense to do so. But the moment you start compromising on core values (e.g. providing a singular model that everyone should adopt and making alternatives hard or impossible to do) is when things start to go wrong since you're fighting the essence of what makes you great. I haven't so far seen anything here that makes me believe this will be the case but it's something to think about.