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: Tue, 21 Apr 2020 17:38:00 +0300 Message-ID: <83ftcwgb07.fsf@gnu.org> 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: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="78200"; 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 Tue Apr 21 16:38:56 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 1jQu35-000KE8-VB for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Apr 2020 16:38:55 +0200 Original-Received: from localhost ([::1]:59226 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQu34-0007WX-Vk for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Apr 2020 10:38:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36112) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQu2Y-0006nN-0U for emacs-devel@gnu.org; Tue, 21 Apr 2020 10:38:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42558) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQu2X-0001Mo-Ao; Tue, 21 Apr 2020 10:38:21 -0400 Original-Received: from [176.228.60.248] (port=3130 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jQu2W-0008GB-HK; Tue, 21 Apr 2020 10:38:21 -0400 In-Reply-To: (message from =?utf-8?Q?S=C3=A9bastien?= Gendre on Tue, 21 Apr 2020 14:43:47 +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:247469 Archived-At: > From: Sébastien Gendre > Date: Tue, 21 Apr 2020 14:43:47 +0200 > > 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) As was already said in this thread, the main problem with this is to come up with the list of features to turn on. Did you ask yourself why there's Spacemacs and Doom Emacs (and a few more variants), and not just one? It tells us something about the commonality of preferences. > 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 Does this mean users who download this "shiny Emacs" will be unable to upgrade to a newer version? > Of course, the pre-configuration can be updated automatically with > Emacs. As the files of this pre-configuration are separated from user > specific configuration. So you propose to have config files that users shall never touch? How likely is this going to hold, what with Emacs users being very inquisitive folks? > [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. This is the main problem to solve, so its place is hardly in the footnotes ;-)