From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexander Adolf Newsgroups: gmane.emacs.devel Subject: Re: A proposal for a friendlier Emacs Date: Mon, 21 Sep 2020 22:00:21 +0200 Message-ID: <1e340d941b6fd0b21a477f39fc935468@condition-alpha.com> References: <4be18b5f-dc07-2703-a2de-1ed08916ebdf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16453"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 21 22:06:59 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 1kKS5R-0004AD-JR for ged-emacs-devel@m.gmane-mx.org; Mon, 21 Sep 2020 22:06:57 +0200 Original-Received: from localhost ([::1]:58334 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kKS5Q-0007Ip-Hh for ged-emacs-devel@m.gmane-mx.org; Mon, 21 Sep 2020 16:06:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57008) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKRzE-0004fp-SL for emacs-devel@gnu.org; Mon, 21 Sep 2020 16:00:39 -0400 Original-Received: from smtprelay01.ispgateway.de ([80.67.18.13]:50967) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKRzA-0002Ii-Lf for emacs-devel@gnu.org; Mon, 21 Sep 2020 16:00:32 -0400 Original-Received: from [46.244.201.10] (helo=condition-alpha.com) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1kKRxL-0007Bp-7s for emacs-devel@gnu.org; Mon, 21 Sep 2020 21:58:35 +0200 In-Reply-To: X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Received-SPF: pass client-ip=80.67.18.13; envelope-from=alexander.adolf@condition-alpha.com; helo=smtprelay01.ispgateway.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/21 16:00:22 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:256301 Archived-At: Hello, I started using Emacs when I first installed Lucid Emacs on a SPARCstation LX, must have been early 1990s, and I have gone through quite a couple of Emacs configs since then (SunOS, Solaris, and now macOS). Since one of the topics on the Emacs 28/modern threads here was "on-boarding" of new users, I thought I'd share a few experiences of what some hard parts were while developing my configs. ---------------------------------------------------------------------- The first hurdle is that when developing a config (yes, its a development task), is that you're essentially pulling yourself out if the swamp by your own hair. I.e. you are using Emacs to edit its own configuration files. Many settings have immediate effect, and that's super cool. Some don't, however, (or maybe you forgot to eval-region) and seem to be evaluated only once at start-up time. Another aspect of this is that not every change I make is one I will want to keep (I'm trying things out). So this is about "backing out" changes and restoring state. Whatever I want to achieve, in order to be able to revert things later, I'll have to make note of the values of variables and hooks before I change them, so I'll be able to restore the previous value. Lest I forgot to make note... Both things together result in me restarting Emacs every now and then when developing a config, so as to be able to start from a clean slate, and make sure that all config changes have been applied. Restarting brings with it a couple of inconveniences. Apart from the wait, it also means that I will need to re-open all the files, custom buffers, documentation, and what not I had open before. Thus, in my ideal world I would like to be able to start a new Emacs instance, that loads the new config, has debug-on-error set, verbose logging, and perhaps some more things to help me debug my new config. In the new Emacs instance, I can take my new config for a spin, and terminate it when I'm done (or even kill it if I messed up badly). Then I drop back into the initial Emacs instance (still all buffers open), refine the config, and give it another round. ---------------------------------------------------------------------- As your config evolves, the next question everyone will be asking themselves is "custom.el or init file?" While there is no one answer to this, of course, but it hints to a wider issue. With flexibility (of init files architecture), comes responsibility (to choose the right architecture for my case). Here is what I observed: when I start adding a new class of use-cases (example: email), I start out with a single package, that does most of what I want/need. In that phase, I tend to name the config file after the package (because the use-case and the package are one and the same in my mental model). As I keep refining, and adding features, other packages will likely come into play. At this point I realise that the config file name no longer fits, and rename it to reflect the use-case class. Within this config file, I keep the setting for each package in a different section (separated by comments). Again, in my ideal world, each package would be classified into exactly one main category (email, content completion, etc.). When I install (package-list-packages) the first package from a category I haven't had before, Emacs would create a new file in the init directory, named after the category (example: email.el), with a (provide 'setup-category) at the end, and a section for the new package that has a copy of the init code proposed by the package's documentation, and would eval-region on the init code. When I install the next package from that category, Emacs would just drop a new section into the respective init file, and eval-region that section. Oh, and of course a (require 'setup-category) would also need to be automatically dropped into init.el. Of course this will not make every experienced user happy, and people with existing, sophisticated configs will want to switch this off. So there should be a variable to turn the whole mechanism off. Maybe in early-init.el? But I think it could be a subtle way of guiding new users to starting with a structured approach to init files (searching for "emacs.d" on GitHub as of this writing lists 10,521 repositories). In the long run, this could also be a tool for doing away with custom.el. Just have Custom insert a custom-set-variables with the settings for that package in the section for that package in the respective category config file. And the settings for Emacs itself would live in init.el. ---------------------------------------------------------------------- The third area I'd like to touch on are faces. This is what certainly everybody will want to customise at some point. The reality of customising faces is: it's hard. Faces can inherit from one another, so sometimes I end up changing a couple of faces, when it would have been sufficient to customise one (the "parent"). An "inheritance tree" would help here. Also, 'C-u C-x =' (what-cursor-position; 10 points for choosing a calling name, btw.) is your friend to find out which of the many many faces to change (provided you discovered it). But then you'll have to strike the key chord time again to discover the faces and overlays here and there. Why couldn't what-cursor-position just split the window, display its information in the other window, and let me move around in my buffer, updating the face/overlay information in the other window as I move the cursor around? And as most of us are on graphical desktops these days, where's the option to hover with the mouse and get face/overlay information for what's under the mouse? One more thing on what-cursor-position: in the info buffer, there's a link for the face that takes me to another info screen, which in turn describes the face's attributes, and gives me a "you can configure this" link. IMO, this is redundant. Just give me a direct link to the face's customisation from the initial what-cursor-position infp screen. The customisation buffer will also show me the current attributes, so the "intermediate" face attributes info screen has no added value to me. ---------------------------------------------------------------------- Finally, a few thoughts on packages and curation. As of this writing, the combined list of ELPA, MELPA, and builtin packages of my current emacs lists 5,065 packages. Chances are, whatever topic you're looking at, there's more than one package. Which one is the best for my purposes? The Comprehensive Perl Archive Network (CPAN), which as of this writing offers 196,156 Perl modules, faces similar issues. It has a simple mechanism, which I find very helpful for quickly narrowing down my selection. Users can do "add to favourites" for a module. When one browses the modules, the number of users who faved it is shown. Not perfect, but a rule-of-thumb estimate for a module's popularity. In my ideal world, such a favourite mechanism would be added to ELPA and MELPA, too, and the favourite count be displayed in the package details screen of package-list-packages. ---------------------------------------------------------------------- Looking forward to your thoughts, --alexander