From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: [FR] Provide a way to activate packages automatically for side effect Date: Wed, 01 May 2024 10:20:09 +0000 Message-ID: <87zft9esva.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20413"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Max Nikulin To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 01 12:20:03 2024 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 1s274E-00054A-TO for ged-emacs-devel@m.gmane-mx.org; Wed, 01 May 2024 12:20:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s273S-0005DD-AQ; Wed, 01 May 2024 06:19:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s273Q-0005Cu-A9 for emacs-devel@gnu.org; Wed, 01 May 2024 06:19:12 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s273N-0002yq-NW for emacs-devel@gnu.org; Wed, 01 May 2024 06:19:12 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 9BB1A240029 for ; Wed, 1 May 2024 12:19:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1714558746; bh=sXNYVoGZLYsSvi1BBRqXpVs9lCCdKOlVUDHG7Q0ce+8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=ipmo6zlS9ycAq9D8XqQertUw7dnw+//hY693dpW0JTJPvzWAmnzsvHmABZY2gC3RF Y9ibgkUqLXhCM0GInUAud4BKwWYgG1yYYdYpxz3M9a5UWnD1pbJv0MdhAwybxYA+vG iBsAgXNrRhb5PCR0z5wgdio3+lHZGrUb4d40ssHcj0ZSJ1GxR2kwI64z/0I0mUTkdz D2ncBPD4bWL/PwSycVMJoMo0PunxBoF8jyJNN+ZYfZmfzYsSUGk2IudwmlLPgqejm1 5wvMZD5wXPjiSZ5HbDKhy/FK9XM4rH78r7Wc+RcnR1e05wtiEe1lOSD9MJLrq2V0j4 1nDncc5W4UAQg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VTtMY4N2Dz9rxW; Wed, 1 May 2024 12:19:04 +0200 (CEST) Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:318461 Archived-At: Hello, The very first suggestion in D.1 Emacs Lisp Coding Conventions is to avoid side effects when loading a library: =E2=80=A2 Simply loading a package should not change Emacs's editing behavior. Include a command or commands to enable and disable the feature, or to invoke it. The request not to change editing experience is reasonable, but it is sometimes hard to draw a line when side effects of the loading should be separated into an explicit command/function users have to run/add to the config. For example, when a package defines a new major mode, it is common to modify `auto-mode-alist' by merely having such package installed. This is technically a change in Emacs's editing behavior. Another example is when a package adds new features to an existing functionality, like ert.el where mere (require 'ert) changes fontification in emacs-lisp-mode buffers: (add-hook 'emacs-lisp-mode-hook #'ert--activate-font-lock-keywords) If one follows "Lisp Coding Conventions" explicitly, the above examples can be seen as breaking the conventions. On the other hand, it is very clear that autoloading a major mode is justified because otherwise why would user install the relevant package? Similar argument can be made for changing the fontification rules in ert.el - if ert library is loaded _by the user_, it is very clear that the erc.el features, including fontification, are going to be useful. The situation is not so clear when a library is autoloaded by the means of building completion list (`help-enable-completion-autoload') - side effects in such case may be surprising to the user who merely wanted to read some obscure docstring. May it be possible to introduce an alternative way to load packages/libraries other than `require' with an intention to be used as a part of user config? What I have in mind is something like (enable-package 'name) that will (1) load the package without side effects; (2) "enable" the package, producing useful side effects intended for interactive use. Further, (use-package name) can be modified to automatically run (enable-package 'name); and package.el can be modified to mark packages installed explicitly (via M-x package-install or other interactive means) to be automatically "enabled" after loading (add (eval-after-load 'name (enable-package 'name). --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at