From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: Request to distribute Casual packages on NonGNU ELPA Date: Thu, 26 Sep 2024 22:43:06 -0700 Message-ID: References: <8B0830CA-6995-454C-BC5A-E4247E259CE9@gmail.com> <6366C9F7-06A7-44FB-B212-24A9F937A7F4@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37381"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Philip Kaludercic To: Charles Choi , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 27 07:43:36 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 1su3lO-0009cU-AJ for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Sep 2024 07:43:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1su3l3-00011m-OM; Fri, 27 Sep 2024 01:43:13 -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 1su3l2-00011c-8K for emacs-devel@gnu.org; Fri, 27 Sep 2024 01:43:12 -0400 Original-Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1su3l0-00005Y-BV for emacs-devel@gnu.org; Fri, 27 Sep 2024 01:43:12 -0400 Original-Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-5367ae52a01so2143950e87.3 for ; Thu, 26 Sep 2024 22:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727415788; x=1728020588; darn=gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=O0GADZsYvc+0hPp9JcnGtUluBl86gqtFDooFcyDQCUI=; b=dCvrcb2eDBBHQbn1TdAptCPDl7v3CPQ14cbfVNRk6MmXC2HperXU8mPcBOCt2Yns7t fv/X5+MgOGPrJLtmsTvkF2J5x8hQ6KqbH5OuCbWVE6Uw9Aa74+lIUhLYBmcV9GHV6/qr zsWfCWD/UZ3bDTCjxj8+np7HeQlGfo2lnNzU6STqBSIPH2qjXo3yOo4ix2wQ3FGqGn9i jraYJIswLaOy+LDlOd0feLDuE9va2cBf3TvLthU3SThuFszZsGps//YSwjno0Ffo5Hdd UnXDz4qTSTLsCvFcol3U0oH6Sd2JKhzVC+x0aUobxsJCgER6l2x8SoamhtE2t8H5pdEc waow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727415788; x=1728020588; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=O0GADZsYvc+0hPp9JcnGtUluBl86gqtFDooFcyDQCUI=; b=MoO/HTh5kgSiANn6Zqd7rydLbFxYhKFN/eHCuFvmOedk/GT+HThQG14/pnrCS8Rd13 rF1IIah2sva9vLXXMEwOI3scKxb6Kbm9X4vhzkwDHMMgMufjNSw8ZJttPJfY0/0fpMZv YIz1OHAIaWl/mLLXLiJIHBU6S2UkO8w1j18NU3if2BGn53iJIsrLdX1rtj/LUe9iXcpF Qn5L3LV+6cshChu452XdCJXjBOuwKN5EJMSXBAbtFI1bktpBEJhI5PWfhXgh5mlO4zkT 3q4n8t4yOlSTWhPyWe1j9pLiO7kuFrwE7Pi/IdiVp8vVSqRqktU5BUz+vq2xigzrzwev 7DKw== X-Forwarded-Encrypted: i=1; AJvYcCUH247lN9pUmDM8z4qVBpiC3aT/vijGAP4BMhV0Wbwz+CXm9m5XGyruLMdaeep/+VJ89EwDcU/WYG65+Q==@gnu.org X-Gm-Message-State: AOJu0YypwQ464Qh6d+eUMeN5/pn73fyNr0qN47FxBuCW3q8dGKyRxWmL eoy0B/Qxi3Uvf0uEW70c22ATKnq1JsZrictP/3r1W2SSE27BBxuwxxGAi0mjWT759uKmztHgzpB IpjG66ZmRpNUBiOhZ/cnrsZ+AJWQ= X-Google-Smtp-Source: AGHT+IHifjnKRnKVm0ASI7Spx4KdKPhVnFlENkDcaJZDRI5ZyX63XYvkblLvtlk4SLHGSNakkEOJd7UTEnell/7NUq4= X-Received: by 2002:a05:6512:3ca4:b0:536:7a24:8e89 with SMTP id 2adb3069b0e04-5389fc6b191mr1034258e87.49.1727415787626; Thu, 26 Sep 2024 22:43:07 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 26 Sep 2024 22:43:06 -0700 In-Reply-To: <6366C9F7-06A7-44FB-B212-24A9F937A7F4@gmail.com> Received-SPF: pass client-ip=2a00:1450:4864:20::133; envelope-from=stefankangas@gmail.com; helo=mail-lf1-x133.google.com 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, FREEMAIL_FROM=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:324126 Archived-At: Charles Choi writes: >> - Why so many packages? They could easily be bundled into just one >> package. This is also strongly suggested by the fact that there is >> a need for a `consult-bundle` package. There is little to no >> benefit to split it up, it just makes dealing with it more fiddly. > > The multitude of packages was to address user desire for granular > installation. As modes are different in their concerns, so are the > different Casual packages. For users unconcerned with granular > installation, the `casual-suite` package is designed to install all > Casual packages. Future Casual package releases are captured by > `casual-suite`. Do you understand what is the problem they are trying to solve? AFAIK, the only benefits that it might bring are: - Marginally faster install and upgrade, if you only want some very small number of individual components. On the other hand, it will be slower for all users of the `casual-suite` package. - Lower disk usage and network traffic, on the order of a couple of dozen kilobytes or so. I have a suspicion that their desire for granularity on this level is misguided, and that their use case would be very well served by having just a single package. > Is the multitude of Casual packages a block to distribution on NonGNU > ELPA? It is not a blocker from where I stand, no. In general, I offer all of these suggestions for your consideration only. What you choose to do with them is up to you. > While I am a strong advocate for good documentation, it is not clear > to me what the content requirements for a Casual Suite Info manual > would be. That said, I am open to pursuing this. This is open ended and not well defined: how to write the documentation is up to you. For inspiration, you could consider looking at some of the many well-written manuals that are distributed with Emacs. > Is having a Casual Suite Info manual a requirement for distribution on > NonGNU ELPA? There is no such requirement, no. > As I have stated before to Philip and have documented as a non-goal > for Casual packages, I am not concerned with maintaining strict > conformance to existing default command bindings. In documenting > Casual, I have tried to make clear that the binding choices I've made > are opinionated. I am happy to rationalize this but before doing so, Yes, the documentation is quite clear on this point. That seems orthogonal to what I suggested, however. If you are not open to changing things here, may I suggest at least adding an option to disable the new bindings? > if it is celebrated that Emacs allows for arbitrary binding of > commands, then are my binding choices a block for review? > > More directly, if it is a requirement for Casual to maintain strict > conformance to existing default command bindings to be published on > NonGNU ELPA, then please retract my request for review. This is also not a blocker, as above. >> - I would put Casual on GNU ELPA, if possible. > > My reason for keeping copyright of the Casual packages is to maintain > editorial control of its design, particularly with regards to binding > assignment and menu layout. It is not clear to me that assigning > copyright to GNU ELPA will assure this. You would still be the maintainer of your package if we added it to GNU ELPA, with all that entails. This would of course also mean that you would still be making the design decisions. There is no practical difference between NonGNU ELPA and GNU ELPA in this regard. >> The `bookmark-jump` key binding is generally useful, and should >> preferably be sent as a patch to Emacs itself. > > For several Casual packages I have suggested different bindings to > make a mode's keymap align with the binding choices made by the Casual > Transient menu for that mode. It is not my intention to push these > binding decisions to Emacs core. OK, that's fine. I did it myself, so it will be there in Emacs 31. See commit bdfeb45bfcf. >> This should say which version of Emacs needs to have transient >> upgraded. If it is Emacs 29.4, then say that. > > Will amend the documentation to reflect this guidance. On this matter, > for Emacs 30 what version of Transient is packaged with it? It seems to be 0.7.2.2. > Thanks again for the initial feedback. You're welcome, and thanks for considering it.