From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matthew Carter Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: Adding use-package to core Date: Sun, 13 Nov 2022 18:13:34 -0500 Organization: Ahungry (http://ahungry.com) Message-ID: <87o7tacush.fsf@ahungry.com> References: <838rkels13.fsf@gnu.org-NGltIw7----9> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19732"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: John Wiegley , "xenodasein@tutanota.de" , xenodasein--- viaEmacs development discussions. , Eli Zaretskii , "stefankangas@gmail.com" To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 14 00:13:13 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 1ouMA4-0004wJ-38 for ged-emacs-devel@m.gmane-mx.org; Mon, 14 Nov 2022 00:13:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ouM97-0004IM-Kh; Sun, 13 Nov 2022 18:12:13 -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 1ouM96-0004I2-Dz for emacs-devel@gnu.org; Sun, 13 Nov 2022 18:12:12 -0500 Original-Received: from mail.ahungry.com ([69.164.215.200]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ouM94-0004jo-Ht; Sun, 13 Nov 2022 18:12:12 -0500 Original-Received: from localhost (ahu.ahungry.com [127.0.0.1]) by mail.ahungry.com (Postfix) with ESMTP id A1B251F6FD8; Sun, 13 Nov 2022 23:12:02 +0000 (UTC) Original-Received: from mail.ahungry.com ([127.0.0.1]) by localhost (ahu.ahungry.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9_4B-ZYl76NZ; Sun, 13 Nov 2022 23:12:02 +0000 (UTC) Original-Received: from blub (c-68-51-134-46.hsd1.mi.comcast.net [68.51.134.46]) by mail.ahungry.com (Postfix) with ESMTPSA id 13A601F6EBD; Sun, 13 Nov 2022 23:12:02 +0000 (UTC) In-Reply-To: (Drew Adams's message of "Sun, 13 Nov 2022 22:03:03 +0000") Received-SPF: pass client-ip=69.164.215.200; envelope-from=m@ahungry.com; helo=mail.ahungry.com 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, 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:299763 Archived-At: Drew Adams writes: >> To me, use-package and package.el are mainly orthogonal: >> Package.el is for package management (installing, updating, >> removing), while use-package is for customization beyond >> what Customize provides -- or at least allows you to >> concentrate changes related to the same package in one place. > > Speaking/asking from ignorance here... > > 1. "Customization beyond what Customize provides" > > What kinds of such customization, besides the > one you call out next (#2)? > > 2. "allows you to concentrate changes related > to the same package in one place" > > Can you be more specific here? How does what > you have in mind differ from what customize > groups provide? > > _____ > > For #2, a package can even have a group with > subgroups. And a package has parent groups. > Seems to me that not only do Customize groups > let you concentrate changes in one place, but > they even let you do so in a hierarchical way > (a graph, i.e., hierarchies with sharing), > that is, change your focus of concentration. > This applies for both browsing/discovering > and changing settings. > > Examples at different ends of the grouping > spectrum: > > `M-x customize-group bookmark-plus' shows 114 > options and faces. Flat: no subgroups. > > On the other hand, group `Icicles' has nine > subgroups. `M-x customize-group Icicles' shows > the following, where each parent group and > subgroup name links to its `customize-group' > presentation: > ______ > > Parent groups: Matching Completion Apropos Dabbrev > Help Recentf Minibuffer Convenience > > Icicles group: > State : visible group members are all at standard values. > > Minibuffer input completion and cycling of completion candidates. > > See also Doc-Part1, Doc-Part2, Description, Download, Other > Libraries by Drew, and Send Bug Report. > > hexrgb-canonicalize-defined-colors-flag > Non-nil means remove duplicate color names. More > > icicle-completion-style-sets > Possible 'completion-styles' values for when 'TAB' completion > method is 'vanilla'. > > Subgroups: > Icicles-Buffers > Icicles preferences related to buffers. > Icicles-Completions-Display > Icicles preferences related to display of completion candidates. > Icicles-Files > Icicles preferences related to files. > Icicles-Key-Bindings > Icicles preferences related to key bindings. > Icicles-Key-Completion > Icicles preferences related to key completion > ('icicle-complete-keys'). > Icicles-Matching > Icicles preferences related to matching input for completion. > Icicles-Minibuffer-Display > Icicles preferences related to minibuffer display during > completion. > Icicles-Miscellaneous > Miscellaneous Icicles preferences. > Icicles-Searching > Icicles preferences related to searching. > _____ > > A guess is that you have in mind other _kinds_ > of customizations, beyond options and faces. > Is that it? > > Customize is limited, but it would be good to > set straight which of its limitations > `use-package' helps overcome. > > One guess would be key bindings. (The Emacs > manual has two completely separate sections, > `Easy Customization Interface' and `Customizing > Key Bindings', with eight and ten subsections, > respectively.) (`defcustom' now has :type > `key-sequence', but that's of course only for > customizing option values.) > _____ > > To be clear, I'm not making any statement about > either `use-package' or Customize. Certainly > the Customize UI could be improved, and there > are user customizations that Customize doesn't > help with at all, OOTB. > > It might be good to match some of its limitations > against what `use-package' offers to handle them. > Maybe that's the best solution for them, or maybe > it can serve as food for thought for improvement > to Customize. > I have always found M-x customize lacking, in that it expects to store my preferences in a machine readable way (albeit, still text, but ill formatted and automatically appended to my files) and be set up via a slow manual process (hopping through customize menus is much slower than just editing elisp). Conversely, use-package allows me to set up all the options I care about in one area, share them with others, and tweak them via the plain old text editing vs clunky menus (I use emacs in TTY mode, maybe in GUI mode these are less clunky). If all customs were equivalent to a setq, I could do the old way (organize on my own, with various (setq some-thing some-value)), however more and more packages seem to need actual M-x customize assignment (a simple setq won't make the change take proper effect). Thankfully use-package accommodates this, and I can set these up in a plain old lisp format in the :custom block the use-package provides. In close to 15 years of using Emacs, I've never opted for M-x customize when other alternatives would do as a user (although I aim to support it in the non-GNU packages I provide). -- Matthew Carter (m@ahungry.com) http://ahungry.com