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: RE: [External] : [FR] Provide a way to activate packages automatically for side effect Date: Wed, 01 May 2024 16:11:04 +0000 Message-ID: <87bk5pseav.fsf@localhost> References: <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="32120"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "emacs-devel@gnu.org" , Max Nikulin To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 01 18:10:39 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 1s2CXX-00086I-0W for ged-emacs-devel@m.gmane-mx.org; Wed, 01 May 2024 18:10:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2CXB-0003L1-2Z; Wed, 01 May 2024 12:10:17 -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 1s2CX6-0003KR-6A for emacs-devel@gnu.org; Wed, 01 May 2024 12:10:13 -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 1s2CWx-0005D4-JC for emacs-devel@gnu.org; Wed, 01 May 2024 12:10:11 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id A8FC5240028 for ; Wed, 1 May 2024 18:09:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1714579799; bh=rsV5XEL4U3r8O8kX1FbmTi9cYHIGeIS4WafY+621+PM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=HZMx0sC25F5RRGhj67TDQjlp07R8elbXcEa5+yDNtvmAR6g7oV2WBgF260lIwYpul 1B8FMFJiNqmfF7Cda8aFPqNKx3ti1jK2njUFhlTOCtpf7T5zrTv1qVF0WsMOsgDrJO V/Y8Ogg6V9p04W598MHDnB7iuOKvvYu74jwbx47ffcrKzayGva/uHBr/qc+MVIZxcA dK/RXpa9o9BZsj6Auz1UIm8awGbgbxW3cYjWl5dG6Eta8FZ7OzMeSdHakRe1W/QZ3l 3+UPitaQazZKdn2DjO/lfBIUcXzYh4c04fAQMAY3UIP1jaym9a1WNBTUpFrKHljcHn TPMdg7sVdI6Zg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VV28Q5xrvz6tvx; Wed, 1 May 2024 18:09:58 +0200 (CEST) In-Reply-To: Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, 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:318494 Archived-At: Drew Adams writes: >> For example, when a package defines a new major mode, it is common to >> modify `auto-mode-alist' by merely having such package installed. > > That's common? It shouldn't be. Loading/installing > code shouldn't do that, even for a "new major mode". Sorry, but the manual itself contradicts your assertion: 24.2.1 Major Mode Conventions =E2=80=A2 If you want to make the new mode the default for files with ce= rtain recognizable names, add an element to =E2=80=98auto-mode-alist=E2=80= =99 to select the mode for those file names (*note Auto Major Mode::). If you define the mode command to autoload, you should add this element in the same file that calls =E2=80=98autoload=E2=80=99. If you use an au= toload cookie for the mode command, you can also use an autoload cookie for the form that adds the element (*note autoload cookie::). If you do not autoload the mode command, it is sufficient to add the element in the file that contains the mode definition. So, I am 100% sure that modifying auto-mode-alist in particular is a side effect that is perfectly fine, even recommended. >> On the other hand, it is very clear that autoloading a major mode is >> justified because otherwise why would user install the relevant package? > > Not for the package to guess why. Up to the user. > >> Similar argument=20 > > What's the argument? Is it just "otherwise why would > a user install..."? That's not an argument. This is an argument. Installing the package implies that the user wants to use that package. Asking to add Elisp incantations other than the usual require/use-package (limited, well-known set of callables) just embraces the culture of copy-paste without understanding and annoys users. >> 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. > > It's not clear that that's clear to the user, or that > (more importantly) the user wants those changes made. I can see this kind of argument, although do note that what I propose - a way to "enable" package with all the side effects - will _reduce_ side effects of autoloading because there will be less pressure on package authors to produce such side effects for user convenience. I thus read your argument as "-1" for automatically enabling packages that are installed explicitly - by clicking "install" in package menu or M-x package-install. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at