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: Adding use-package to core Date: Tue, 15 Nov 2022 17:25:16 +0000 Message-ID: <87sfik6sg3.fsf@posteo.net> References: <87lep4jeeb.fsf@gmail.com> <87y1ssugaf.fsf@posteo.net> <875yfw6kbx.fsf@gmail.com> <87r0ykufh8.fsf@posteo.net> <87sfiyl6nb.fsf@posteo.net> <87pme1ddsn.fsf@gmail.com> <871qqhby2k.fsf@posteo.net> <87leopdbsw.fsf@gmail.com> <87tu3dagj5.fsf@posteo.net> <87eduhd7m7.fsf@gmail.com> <87iljk1voy.fsf@posteo.net> <874jv4z2th.fsf@posteo.net> <87mt8wxjjf.fsf@posteo.net> <877d009n8a.fsf@gmail.com> <87o7tbwcvw.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="11740"; mail-complaints-to="usenet@ciao.gmane.io" Cc: John Wiegley , Payas Relekar , Stefan Monnier , emacs-devel To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 15 18:26:48 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 1ouzhv-0002n6-1I for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Nov 2022 18:26:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ouzh1-0000qs-GA; Tue, 15 Nov 2022 12:25:52 -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 1ouzgi-0000p3-7m for emacs-devel@gnu.org; Tue, 15 Nov 2022 12:25:42 -0500 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 1ouzgf-0001fc-Qu for emacs-devel@gnu.org; Tue, 15 Nov 2022 12:25:31 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id D0441240026 for ; Tue, 15 Nov 2022 18:25:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1668533126; bh=w5tqjfMch+F/kjEVjUrtgf2fNn66xwghup0Ssp+idfY=; h=From:To:Cc:Subject:Date:From; b=LYTmOCRDW5ggAG3UDkUfelmOiLJgRlChiW2710+SUVIdMHm+iJmxCZDeY+FPV5mSy tRIP50sn3PfA0CAqN6Xk033BT7MxwWtIfAnmFEKFrul66cfUrVwG3n7LpyTeGHq0CZ qb92IlYEKt0rznUb97Q1z+kvrvIXrobrP/Z+b86JYv2UaV4xAJQAzyL5pkx7Pmptlm Yg1xPR671O5PxZhgNbT/cm91cg6y7Zor/n/Ea9BEaMArC2QD3J0Efy0+Flck1J6dBd W91mkUoMVHHBiX2DT9jon0hwHZ8qrHsDKq4FswPti/PVbA8ok5fqwSjAcEaHUlVztT drQj94INwXqjQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NBY3P4G2Vz9rxG; Tue, 15 Nov 2022 18:25:21 +0100 (CET) In-Reply-To: <87o7tbwcvw.fsf@posteo.net> (Philip Kaludercic's message of "Sun, 13 Nov 2022 07:07:47 +0000") Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@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, RCVD_IN_DNSWL_NONE=-0.0001, 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:299859 Archived-At: Philip Kaludercic writes: > Stefan Kangas writes: > >> John Wiegley writes: >> >>>>>>>> Payas Relekar writes: >>> >>>> I would personally like to see the package in core if at all possible, and >>>> John has also expressed interest in that. Personally I'd prefer if >>>> development continues in core after upstreaming, but it is upto John to >>>> decide. I know that Modus-themes and Org both are developed out of tree, and >>>> only merged in when the package version is bumped. Which means history is >>>> lost, but clearly that hasn't been a problem and maintainers of those >>>> packages prefer it. >>> >>> I'm entirely in support of the code and its development moving directly into >>> core. Whichever best supports the Emacs developers and the needs of the >>> community, since it is more than likely that future work will be carried out >>> by others. I'm ready to hand it off in whatever way is desired by the team >>> here. >> >> IMHO, for that to make sense, someone capable would have to volunteer to >> maintain it on our side. If we don't have such a volunteer, it makes >> more sense to me to keep development external for now. >> >> If we see a need to move development fully into core in the future, we >> can always do that, but the reverse is harder. > > I agree, a transitory stage where use-package is still maintained > externally sounds like the safer bet for now. > >> (If we want to preserve history when making such a move at a later date, >> we could just delete our existing copy of the file from emacs.git and >> then merge the full git history, just as we did with eglot.el.) > > In that case, what is left is completing the .texi manual, or am I > mistaken? After that, I suppose that placing the right files in the > right places in emacs.git will be less that a days work. One thing I have noticed since use-package has appeared on ELPA, that could also be tackled in time is that the package description (C-h P) is very messy. It starts like this: --8<---------------cut here---------------start------------->8--- # `use-package` [![Join the chat at https://gitter.im/use-package/Lobby](https://badges.gitter.im/use-package/Lobby.svg)](https://gitter.im/use-package/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) [![Build Status](https://github.com/jwiegley/use-package/actions/workflows/test.yml/badge.svg)](https://github.com/jwiegley/use-package/actions) [![MELPA](https://melpa.org/packages/use-package-badge.svg)](https://melpa.org/#/use-package) [![MELPA Stable](https://stable.melpa.org/packages/use-package-badge.svg)](https://stable.melpa.org/#/use-package) The `use-package` macro allows you to isolate package configuration in your `.emacs` file in a way that is both performance-oriented and, well, tidy. I created it because I have over 80 packages that I use in Emacs, and things were getting difficult to manage. Yet with this utility my total load time is around 2 seconds, with no loss of functionality! **NOTE**: `use-package` is **not** a package manager! Although `use-package` does have the useful capability to interface with package managers (see [below](#package-installation)), its primary purpose is for the configuration and loading of packages. Notes for users upgrading to 2.x are located [at the bottom](#upgrading-to-2x). - [Installing use-package](#installing-use-package) - [Getting started](#getting-started) - [Key-binding](#key-binding) + [Binding to keymaps](#binding-to-keymaps) + [Binding within local keymaps](#binding-within-local-keymaps) - [Modes and interpreters](#modes-and-interpreters) - [Magic handlers](#magic-handlers) - [Hooks](#hooks) - [Package customization](#package-customization) + [Customizing variables](#customizing-variables) + [Customizing faces](#customizing-faces) - [Notes about lazy loading](#notes-about-lazy-loading) - [Information about package loads](#information-about-package-loads) --8<---------------cut here---------------end--------------->8--- And is followed by the entire manual (from the README file). I wonder if it would be better to set :redeem in the package specification to ignore, and instead just display the shorter commentary section: --8<---------------cut here---------------start------------->8--- ;; The `use-package' declaration macro allows you to isolate package ;; configuration in your ".emacs" in a way that is performance-oriented and, ;; well, just tidy. I created it because I have over 80 packages that I use ;; in Emacs, and things were getting difficult to manage. Yet with this ;; utility my total load time is just under 1 second, with no loss of ;; functionality! ;; ;; Please see README.md from the same repository for documentation. --8<---------------cut here---------------end--------------->8--- Perhaps just with the reference to the README.md replaced with a reference to the forthcoming manual.