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: Tue, 22 Sep 2020 22:50:21 +0200 Message-ID: <62ff80b8ff943b698ef8c46849b8bc50@condition-alpha.com> References: <4be18b5f-dc07-2703-a2de-1ed08916ebdf@gmail.com> <1e340d941b6fd0b21a477f39fc935468@condition-alpha.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="13570"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 22 22:51:40 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 1kKpGF-0003Mq-0h for ged-emacs-devel@m.gmane-mx.org; Tue, 22 Sep 2020 22:51:39 +0200 Original-Received: from localhost ([::1]:52600 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kKpGD-0006LM-Rl for ged-emacs-devel@m.gmane-mx.org; Tue, 22 Sep 2020 16:51:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34698) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKpFC-0005r8-3a for emacs-devel@gnu.org; Tue, 22 Sep 2020 16:50:34 -0400 Original-Received: from smtprelay07.ispgateway.de ([134.119.228.99]:24333) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKpF4-0003Ai-SP; Tue, 22 Sep 2020 16:50:32 -0400 Original-Received: from [46.244.200.228] (helo=condition-alpha.com) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1kKpD0-0005oh-NB; Tue, 22 Sep 2020 22:48:18 +0200 In-Reply-To: X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Received-SPF: pass client-ip=134.119.228.99; envelope-from=alexander.adolf@condition-alpha.com; helo=smtprelay07.ispgateway.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/22 16:50: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_H2=-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:256339 Archived-At: Richard Stallman writes: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > As your config evolves, the next question everyone will be asking > > themselves is "custom.el or init file?" > > It is possible to use both -- so why do people believe they have > to choose one or the other? Apologies for not having been clear enough. The question is not either or, but whether any arbitrary, usually small, set of (setq X) or (face-spec-set Y) are better added to a hand-crafted init file, or done via Custom (so they end up in custom.el). The typical advice users get on Stackexchange and similar, is to choose either variant at will (or randomly), and to version control their emacs.d directory with git. What this shows is that (too much) freedom of choice early on in a new user's adoption journey can be perceived as an obstacle (by new users). > > 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. > > We use multiple definitions of "package" in connection with Emacs. > Would you please say what definition you're using here? > > For instance, does "package" include Rmail? Good point; 'package' is used in so many contexts, it's a fuzzy term. Yes, I would refer to Rmail as a 'package', too. > > Within this config file, I keep the setting for each package in a > > different section (separated by comments). > > Could Configure do this automatically? That was precisely my idea. > Would that require additional data about relationships between various > things? I haven't done any experiments, but in my manually crafted configs, I never had an issue with the ordering of sections. Sure, not everything is autoloaded, and there's lazy loading. What about wrapping a package's config in a with-eval-after-load, or making use-package a builtin? > > Again, in my ideal world, each package would be classified into exactly > > one main category (email, content completion, etc.). > > In principle, I think this is a good idea. However, think it should > NOT be limited to ELPA packages. Fully agree. > Also, I have a feeling that users won't all agree how to classify > packages. I expect there will be overlapping categories that make sense. > So I think we need to make provision for having one package > that fits into multiple categories. Perhaps by asking the user > which category to think of this package in. > [...] Let the package author choose and, and only one category, and any number of tags he/she wants to use to describe the package. When a user installs a package from a package archive, the category chosen by the author is presented as the default choice, and can be overridden by the user. Just my two cents anyway. Looking forward to your thoughts, --alexander