From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "T.V Raman" Newsgroups: gmane.emacs.devel Subject: Custom Et Al: Build-Up The Underlying Platform was Re: A new user perspective about "Changes for emacs 28" Date: Tue, 08 Sep 2020 09:37:24 -0700 Message-ID: References: <1ca462fa-0f9e-3c18-6386-f43f49388b2f@gmail.com> <20200907180812.5tfylspp7i6vl4o3@Ergus> <94fda087-a61b-356d-4bb4-791907593246@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=gb18030 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34244"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Ergus , Nicola Manca , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 08 18:38: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 1kFgdJ-0008nd-0L for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Sep 2020 18:38:13 +0200 Original-Received: from localhost ([::1]:41878 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kFgdI-0004nT-0J for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Sep 2020 12:38:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48032) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kFgce-0003u2-CK for emacs-devel@gnu.org; Tue, 08 Sep 2020 12:37:32 -0400 Original-Received: from mail-pj1-x102a.google.com ([2607:f8b0:4864:20::102a]:55806) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kFgcc-0001XM-IJ for emacs-devel@gnu.org; Tue, 08 Sep 2020 12:37:32 -0400 Original-Received: by mail-pj1-x102a.google.com with SMTP id q4so2373677pjh.5 for ; Tue, 08 Sep 2020 09:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=V2D3VKGjqg5E8KygOicQ0bh2w7agNl3YQguHJKuhRhk=; b=C3z3DwC53wiItJ2SVnWi2gNbJgDA4BzJKs+gVKvkqHa33HPH/5ZbbLseH10F33ZEEO /jGn1uUWvsl4U9zposaoZRsxj1rMrY1DQ+czpNe9zLdkvQiOPvomDaPOTW+oONq/Ijjn pKAV1RBhetdcBFbSUIdb1ksmSdaCkSGU9r0ZWVTg2sQs3cebyKHUOyZVJ6GacwI//nVy Sl+vVXTMkvIbu1bxS2yALTCaAwkXSNKOabWW1A7s4C/80601WgNbMXeXWHqImdHRtXog tX9aeANCxJ3uXIqUSUD1mLH89EMhWjXFqgEodizxou+ebfqQ8nEc/Pwo+pzrtn46h1a7 8c8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=V2D3VKGjqg5E8KygOicQ0bh2w7agNl3YQguHJKuhRhk=; b=VYFQob3eFTSkDGMurPvYRBrvfgJj4DZlQPybq4bbSNOtiKwWtONB9IN2dCpCimw78i G3rNbHpcjeB8NO5x47xvdlGl+B/UsEJ2qQtsKb4ui+4cpqJ4V10QmJKhmG9TBO+s6M+H TKKQLcq90RDqQK/dNojI4zLEpcZH476B4qJCUWM4IS0JHhBbbxkCUk3w1hUHmvWFxvaG GWHp7VzlkVN1qT+0ocK62v9655gAuOBgNoPwvh70v+Q5UqIrbMp4XrnsKXtkOa4D32HK BCuaVEiTcgP4fL/EeQiMoT2lbmyr2wUNvzVk1ynLZJj40Hn3DHL34NGwcEVjdMXlkSth LPEA== X-Gm-Message-State: AOAM530SuHZCaDZqGX69VLczvidWANFvMpzPY9hbP0EtYjdG0iJ7NBvb zweaWDU1foF6c7BH48CWItT0zQ== X-Google-Smtp-Source: ABdhPJz/sl/uie10APVI7bYwNcq5PRHqbW2q57Cz+H9T/j4FMfCFsRnJXw5J4yVvwT9HwzdQ2cPDDA== X-Received: by 2002:a17:90a:6701:: with SMTP id n1mr4863017pjj.87.1599583047187; Tue, 08 Sep 2020 09:37:27 -0700 (PDT) Original-Received: from raman-glaptop.localdomain (c-24-4-174-65.hsd1.ca.comcast.net. [24.4.174.65]) by smtp.gmail.com with ESMTPSA id s129sm18921757pfb.39.2020.09.08.09.37.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2020 09:37:26 -0700 (PDT) Original-Received: by raman-glaptop.localdomain (Postfix, from userid 13930) id F037FC21DF7; Tue, 8 Sep 2020 09:37:24 -0700 (PDT) In-Reply-To: <94fda087-a61b-356d-4bb4-791907593246@yandex.ru> (Dmitry Gutov's message of "Mon, 7 Sep 2020 23:05:05 +0300") Received-SPF: pass client-ip=2607:f8b0:4864:20::102a; envelope-from=raman@google.com; helo=mail-pj1-x102a.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -175 X-Spam_score: -17.6 X-Spam_bar: ----------------- X-Spam_report: (-17.6 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5 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:254771 Archived-At: The discussion around how to bring in new users etc is healthy as long as it moves the ball forward. Experience tells us that there are multiple directions in which we can move, some that will bear fruit, some that will wither and go away. But independent of which of those branches/offshoots survive, making the underlying platform, AKA Emacs' extension/configuration layer more robust and flexible is work that will stand us in good stead over the long term. >From that perspective, I hope we can put some energy into making the underlying M-x custom more robust --- see below for what I mean: 20+ years ago, M-x custom came to Emacs, initially disliked by all those of us who prefered writing elisp in our init files. Over time though it has definitely landed well and made Emacs easier to configure --- to the extent that even folks who are happy to write elisp by hand in their setup use it to varying degrees. that's the good half of Custom. Custom however is also showing its age, here are some personal opinions about its shortcomings: A. It has the disadvantage of dumping all settings into a single file, feels like the Windows Registry and can be fragile. B. Tends to accumulate cruft, eg customizations for packages that dont exist linger in the customization file C. Custom scares you away from touching its setup --- especially "the only one of these forms can appear" bit that forces all settings into a single file. D. I think custom themes are a great idea but it feels like it was "started but never finished". E. A dual to custom is use-package that has the virtue of isolating package-specific setup to a package-specific form in your setup, so you stop using the package and there is no cruft left behind (except ... that custom can still grab some of those settings and dump it into your custom file). So while we debate the pros/cons of various features, it might be a good investment of time to rethink and evolve custom to become more robust along various axies, since any user-friendly layers of preferences/customizations we would add could all use the underlying infrastructure to advantage. Dmitry Gutov writes: > On 07.09.2020 21:08, Ergus wrote: > >>> - undo-tree-mode >> Undo tree had some problems in the past. But if you want the basic >> undo/redo behavior there is something already in vanilla (as usual a bit >> hidden): >> (global-set-key [remap undo] 'undo-only) >> (global-set-key (kbd "C-M-_") 'undo-redo) >> which I discovered after asking here and fighting with undo tree for >> almost a year. > > Good point. > > undo-tree has been stable for me lately, but it might be overkill for > a lot of users, and the default undo behavior is... exotic. > > So I think ideally we'd switch to the above key mappings by > default. But since this is going to be a hard sell, at least this > option should be better documented/advertised, maybe even on the new > splash screen people have imagined/mentioned. > --=20 =817=A94 Id: kg:/m/0285kf1 =950=DC8