From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?ISO-8859-1?Q?S=E9bastien?= Gendre Newsgroups: gmane.emacs.devel Subject: Re: Making Emacs more friendly to newcomers Date: Tue, 21 Apr 2020 14:43:47 +0200 Message-ID: References: <863691n4xl.wl-me@enzu.ru> <87imhw431x.fsf@yahoo.com> <87mu78huhx.fsf_-_@yahoo.com> <87k12bdgx7.fsf@yahoo.com> <83zhb6grtq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="80036"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.36.1 (3.36.1-1.fc32) To: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 21 14:44:35 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 1jQsGQ-000Kjz-If for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Apr 2020 14:44:34 +0200 Original-Received: from localhost ([::1]:57458 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQsGP-0005V3-KV for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Apr 2020 08:44:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37078) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQsFo-00055Q-Tu for emacs-devel@gnu.org; Tue, 21 Apr 2020 08:43:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jQsFo-0001GH-2E for emacs-devel@gnu.org; Tue, 21 Apr 2020 08:43:56 -0400 Original-Received: from 50-102-31-185.ftth.cust.kwaoo.net ([185.31.102.50]:43376 helo=gandalf.k-7.ch) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jQsFn-0001B2-G6 for emacs-devel@gnu.org; Tue, 21 Apr 2020 08:43:55 -0400 Original-Received: from escaflown.lan (Alfred.lan [192.168.1.1]) (Authenticated sender: seb) by gandalf.k-7.ch (Postfix) with ESMTPSA id 5D76EE8100; Tue, 21 Apr 2020 14:43:48 +0200 (CEST) In-Reply-To: <83zhb6grtq.fsf@gnu.org> Received-SPF: none client-ip=185.31.102.50; envelope-from=seb@k-7.ch; helo=gandalf.k-7.ch X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/21 08:43:48 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 185.31.102.50 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:247462 Archived-At: Having a Vanilla-mode are maybe wore difficult than it seems. So, let's forget Vanilla-mode and see another solution who can be more feasible. Maybe we can take inspiration from the work of Spacemacs and Doom Emacs: Offer an official pre-configuration of Emacs, on the side of Emacs itself. This pre-configuration will be more focused on new users and new features when Emacs itself would be more focused on stability. Here is, in more detail, what I have in mind. On one side, continue to develop Emacs as today : - Keep same defaults - If a new features is proposed, check if it break any compatibility or defaults - If no, include it in Emacs - If yes, try to modify this feature to not break any compatibility or defaults and if its a success, include this feature in Emacs - If it's not possible, include the feature but deactivate it by default or make a package on ELPA I don't think this side is different from what development on Emacs is today. We can call this side Emacs vanilla, or Emacs core, or Emacs base. Anything that reflect that this is the common base for everyone. On another side, we can create a pre-configuration (like what Spacemacs or Doom Emacs do) : - All this pre-configuration is a set of files to be put inside the .emacs.d to start using it (like Spacemacs) - Main goal is to have a pre-configuration that provide what is commonly expected from a modern text editor [1], out of the box - Easy to use for the common tasks - Enable some features that are not enabled by default - Modify some defaults behaviours of Emacs to reflect more what new users search in a text editor - Can include some packages from ELPA (if no legal or licence issue) - This pre-configuration can be done by a dedicated team who collaborate with who work directly on Emacs - The structure of this pre-configuration need to be made to not conflict with user personal configuration (ex: avoid to put anything in the init.el, use separate sub-directory inside .emacs.d, etc) The actual Emacs show that the first side is possible. And projects like Spacemacs and Doom Emacs show that the second side is also possible. So I think this solution is feasible. And a direct collaboration of the both side can make the process more easy. A remaining problem is: How provide the pre-configuration easily and out of the box for new users, without breaking long time Emacs users configuration? A possibility would be: - When Emacs start, it check if a configuration already exist on the user directory (~/.emacs.d or ~/.emacs) - If yes, Emacs start - If no, Emacs restore the pre-configuration inside ~/.emacs.d then start With this, new user can use the "modern, shiny, OOTB Emacs", out of the box, by simply download and run it. And the long time user can have a stable Emacs who don't break their configuration. For someone who want to use Spacemacs, simply extract it as ~/.emacs.d before start Emacs. And for someone who want to start Emacs without a pre-configuration, simply create an empty directory for ~/.emacs.d. Of course, the pre-configuration can be updated automatically with Emacs. As the files of this pre-configuration are separated from user specific configuration. Open questions remain: - Does the pre-configuration release cycle are synchronised with Emacs or completely independent? - Does the user can block the pre-configuration update, to avoid breaking its configuration based on a specific version of the pre-configuration? But I think this can be a realisable solution. [1] List of features to be defined, but I imagine some out of the box auto-completion, code navigation, functions documentation + functions signatures + errors showing automatically, strong integration with git (Magit?) and debuger, major containers engines (docker, kubernetes) integration, etc. With a great support of the most populare programming languages. And maybe have a special attention to integrate with web technologies and tools for web developer. PS: Or maybe we think to much about this problem. And making an LTS versions of Emacs, like Ubuntu does, is the solution.