From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Making Emacs more friendly to newcomers Date: Mon, 20 Apr 2020 17:22:25 +0300 Message-ID: <83zhb6grtq.fsf@gnu.org> References: <863691n4xl.wl-me@enzu.ru> <87imhw431x.fsf@yahoo.com> <87mu78huhx.fsf_-_@yahoo.com> <87k12bdgx7.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="91500"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?utf-8?Q?S=C3=A9bastien?= Gendre Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 20 16:23:14 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 1jQXKM-000Ngw-7u for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Apr 2020 16:23:14 +0200 Original-Received: from localhost ([::1]:36766 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQXKL-0005cK-Ag for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Apr 2020 10:23:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45326 helo=eggs1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQXJi-0005BR-99 for emacs-devel@gnu.org; Mon, 20 Apr 2020 10:22:35 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48047) by eggs1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQXJh-0003FX-IN; Mon, 20 Apr 2020 10:22:33 -0400 Original-Received: from [176.228.60.248] (port=2062 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jQXJd-0004U9-H0; Mon, 20 Apr 2020 10:22:33 -0400 In-Reply-To: (message from =?utf-8?Q?S=C3=A9bastien?= Gendre on Mon, 20 Apr 2020 00:44:40 +0200) 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:247387 Archived-At: > From: Sébastien Gendre > Date: Mon, 20 Apr 2020 00:44:40 +0200 > > - Alice: A long time user. She got a personal Emacs configuration she > had perfected over the years. She chose herself what system is used > to show function completion, which code parser is used for her daily > used languages. She add some packages to integrate with special > tools used at her work. Emacs is her home and office: She use it as > much for her personal project than for her work. She also made a > personal workflow with org-mode and write some personal Elisp > functions and advices. She forge the tools to her need. She do not > want to have an update of Emacs who break her configuration, her > workflow or her muscle memory. There's a flaw in this description of how long-time Emacs users concoct their configurations. What's in their configuration depends _heavily_ on the defaults: the features whose defaults satisfy such users are never touched in the init file. Any "vanilla" Emacs that turns off many features will run a high risk of breaking such configurations, because it violates the assumptions on which those configurations rely. At least, that's how I maintain my init files. > For these 4 use-cases, we can simply provide 2 flavors of Emacs: > - Emacs: With all the 2020 features, a modern interface, all needed > modern features to start coding with most popular languages and easy > to use for basic usages The first and the most important problem with this is to identify what you informally call "all the 2020 features, a modern interface, all needed modern features to start coding with most popular languages and easy to use for basic usages". If you review past discussions on this and related subjects, you will see that opinions on what should be part of that set of features vary widely, so much so that I don't believe any significant agreement is practical. It _might_ be possible to come up with a relatively short list of features that could "modernize" Emacs, about which enough people will agree that they should be part of "2020 features". However, I'm not sure even this limited goal is possible, and will continue to be unsure unless and until someone comes up with such a list, and we see what's in it and how many people agree on the list. On top of that, the list (and the dispute to go with it) will need to be updated with each major release. Suppose we do have such a list -- will that be enough to make Emacs sufficiently more attractive to Bob and his friends? I don't know. One problem is that we don't have many such Bob's on our team or even reading this list, and those few who are very quickly become Alice's. So their voice is never heard. We don't have any HFE experts on board, who could pretend to be a Bob. So who will be able to represent them and make sure the list of said features will be to their liking? > - Emacs Vanilla: All the new features are still there, but deactivate > to not break anything I'm guessing that by "new" you mean all those "modern" features that we don't currently turn on by default. Otherwise, I don't see any useful purpose for such a "vanilla" Emacs. > And if Emacs detect, after an update or a first start, an already > existing configuration that it could break because of some features: > Emacs simply activate `vanilla-mode` automatically. I don't see how Emacs can do that, when many dozens of optional features are involved. How do you write code that detects whether a given feature can break something? Ideally, we will have already considered that, and make every effort not to break any existing feature or muscle memory. And who will write and maintain such code, and update it with each release? Are you aware of any other project that does anything similar? > It's just a starting point, but I think this could be a simple but > very useful solution. This assumes that someone does all the research and design and implementation needed for that, and that we as a project commit to maintaining these very non-trivial facilities for the years to come. You may not realize it, but this is a very far cry from what we do now. For example, it is a long and frustrating uphill battle just to make sure that NEWS provides information for how to get back old behavior, for every one of those new features that do change behavior. Please try to imagine (and describe to us, if possible) what kind of development procedures will have to be put in place to support what you propose, which is much more complex and problematic.