From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: emacs-29 acd462b0306: ; Improve the use-package manual Date: Mon, 12 Dec 2022 20:06:54 +0000 Message-ID: <87wn6ws7xd.fsf@posteo.net> References: <167059642832.4265.15913417645926264658@vcs2.savannah.gnu.org> <20221209143348.961DEC0E4CA@vcs2.savannah.gnu.org> <87cz8rgr0h.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1214"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Kangas , emacs-devel@gnu.org, Eli Zaretskii To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 12 21:07:45 2022 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 1p4p5U-00007l-TK for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Dec 2022 21:07:44 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4p4n-0003NF-4n; Mon, 12 Dec 2022 15:07:01 -0500 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 1p4p4l-0003Mq-1A for emacs-devel@gnu.org; Mon, 12 Dec 2022 15:06:59 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p4p4i-0008Ja-3n for emacs-devel@gnu.org; Mon, 12 Dec 2022 15:06:58 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 9F14B240105 for ; Mon, 12 Dec 2022 21:06:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1670875613; bh=vN4Zj7PdqE5phqCTeNxC0t6t4qz0rrMjVXokKCw+zLM=; h=From:To:Cc:Subject:Date:From; b=OrLtRp8wQEgUajVIOnEKgHpwkJdABZnI0LZNuCr3Dn+DlhyjkMs/sPxZuuhhRxVFl tmUf/nFfkQWodY9GKRhc46aXmKdpjtWVUFNqLcuKQbVXnyLkkAfQzT3C3dyRNBimoI 1NajuzqrCxkDxi2TlTfJ3yP8ICrdiJ5qcV1JWRXJ2tmjg3rEyjR+v7tP+a0L32U7hc l+d+aHyhzPZx0mkAeKUTdGEPeXelSBhg5EPMi/fulH6yj/FTCBDh3UgWaOM/Nidafm 1JR0kHKAVY5qZZSDwaRDwmYgYT5QlCSymi6pNd36X09AFioXpQAWubxGLvKnzOPWJc TfsFyjnvC/yMQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NWCMJ4pQRz9rxD; Mon, 12 Dec 2022 21:06:51 +0100 (CET) In-Reply-To: (John Wiegley's message of "Mon, 12 Dec 2022 11:37:01 -0800") Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:301278 Archived-At: John Wiegley writes: >>>>>> Stefan Monnier writes: > >>> It would also be nice to have user options like >>> 'use-package-always-defer' enabled by default, but that will certainly >>> break a number of configurations. > >> Those users can always (setq use-package-always-defer nil) to >> recover the >> old behavior. > > This should *not* be enabled by default. > > Basically, `:demand` and `:defer` are considered overrides, which > basically short-circuit the intelligent in use-package that figures > out when a deferred load would offer the most benefit. The `-always-` > variables cause these overrides to be applied globally, but this is > almost always a bad choice, since it means giving up one of the > reasons why use-package exists in the first place: to figure out when > things should be deferred, but not deferring them when it's unhelpful. Most configurations I see online do use `use-package-always-defer' by setting it to t, so it might be worth considering what use-package was meant to do, and how it is being used. It has been mentioned elsewhere that use-package has a number of implicit assumptions that stem from before the wide-spread usage of package.el and reliable autoloads. Or at least that is how I make sense of keywords like :mode, :magit, :interpreter, etc. which almost all package should set on their own (and if they don't, they should. It doesn't make sense to make every user configure these things manually when it is well known that ".foo" is the conventional file extension of foo-mode). (It is by relying on the above assumptions that setup.el is under 800 lines long, without size ever having had been a priority (including documentation and docstrings).) I think it would be nice to see some space for use-package to evolve along with the changing circumstances, requirements and expectations, especially given how it is part of the core now, so the audience will only grow.