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: Objed maintenance Date: Wed, 01 May 2024 18:06:01 +0000 Message-ID: <87ttjhpfue.fsf@posteo.net> References: <85ttjyp9xh.fsf@gmail.com> <87cyqhvp3k.fsf@posteo.net> <87v843qfvf.fsf@posteo.net> <87v843owbj.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="38244"; mail-complaints-to="usenet@ciao.gmane.io" Cc: clemera@posteo.net, emacs-devel@gnu.org To: Amy Grinn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 01 20:06:40 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 1s2ELn-0009i5-K3 for ged-emacs-devel@m.gmane-mx.org; Wed, 01 May 2024 20:06:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2ELK-0005J0-35; Wed, 01 May 2024 14:06:10 -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 1s2ELH-0005IM-VZ for emacs-devel@gnu.org; Wed, 01 May 2024 14:06:08 -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 1s2ELF-0007wG-SI for emacs-devel@gnu.org; Wed, 01 May 2024 14:06:07 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id D2499240028 for ; Wed, 1 May 2024 20:06:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1714586762; bh=z+IqBMK6SypnjWa2MhOTNWUc1oi0nm57hrcrQTJyHPs=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=SNf25vrZzjuEdjt5WjyJBrmLOnebzP+Q+T1kkeP9x0wBSgK+sEpJ2sR4iQBpcFcB6 szHu5iB/LYrR3StzM73U7MaT3Ek1C7lXdSFi8M/J+75XWDTLCh2ygivMFSoiS+OaJJ DiP+8Xe35v2H/d/ZAydKruNFGRMQ8L7d8N+Vs/rX205sg/T7WAh5CvZY76cHcAJUp3 3PX5NxTnmPnT86wuZvgDFJMmR/tYnmotRYmx+qs9i5uo7oZHNSh+mWKFJQSUPFcKQ5 3gwRrHeHBuBcvN90Dtk+wIIjEni2bivqlXT5J5DnVEzaVQsbbFC1ar78iqgBgQnYu8 Hq4C2anByKcSw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VV4kL2GyWz9rxG; Wed, 1 May 2024 20:06:02 +0200 (CEST) In-Reply-To: (Amy Grinn's message of "Sat, 27 Apr 2024 17:51:31 -0400") OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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:318507 Archived-At: Amy Grinn writes: > Philip Kaludercic writes: > >> Amy Grinn writes: >> >>> Philip Kaludercic writes: >>> >>>> Amy Grinn writes: >>>> >>>>> Philip, I am using an unpublished dependency called key-game, >>>>> which >>>>> I >>>>> wrote, which I thought might be useful for other modal editing >>>>> packages, >>>>> or for large packages like gnus. Anyways I will try to submit >>>>> that >>>>> package for publishing on GNU ELPA before objed is updated. >>>> >>>> That sounds good, just inferring from the name it sounds like >>>> wizard >>>> or >>>> training program? Is this going to be a hard dependency or a weak >>>> one? >>> >>> Yes, it's a utility package to help create key-based or >>> command-based >>> tutorial games. It's not a user-facing package, similar to boxy; I >>> wouldn't want users to have to install it explicitly. To answer a >>> potential followup, I also wouldn't want to split up the objed >>> tutorial >>> game into a separate package. That would hinder discoverability and >>> make the installation of objed more complex. All that to say I >>> believe >>> key-game will be a hard dependency. >> >> That is a pity. I try to advocate for minimising dependencies, >> especially if these aren't required for the core functionality of a >> package. I don't know how your package is designed, but couldn't you >> have a command like M-x objed-tutorial that reports an error if the >> package is not installed (or proposes to install it)? FWIW I don't >> think having a separate package is a good idea either -- too much >> noise >> in the package list. > > Practically, the entrypoint for the objed tutorial game is a key-game > macro call, so it would be difficult to rewire. Moreover, this would > cause a similar issue in all other packages which might use key-game. > This implies much more boilerplate which must be maintained separately > in all those packages. > > I see your point that the tutorial is not *the* core feature of objed, > but in my opinion it is *a* core part, and one that is more likely to be > invoked by new users. I don't want to put up roadblocks for them. I > think peer dependencies can be useful for extending a package, and objed > already has such a dependency with avy, but this seems like an > unnecessary installation step instead. > > I'm not as experienced with ELPA, so I would like to know more about the > thought process behind discouraging direct dependencies. But again, I > don't think key-game has any intrinsic features which an end user may > want separate and apart from its use in other packages, and I would find > it odd to suggest users add it to their selected packages. Abstractly: My advice is my advice, it is inherently biased. I take that position, because of my experience, which is why I refuse to install packages with more than 1-~2 transitive dependencies (I was recently once again shocked by "ement"). As everything I say that isn't part of the ELPA rules, you can ignore it if you think you know better. My motivation to help with ELPA is rooted in my own interest to have good packages, given my own understanding of what makes packages good. Concretely: I don't know how key-game looks like, so I cannot really say if it makes sense or not. I had something in mind like a generic wizard framework, where you'd M-x key-game, then get prompted what game to play (as defined by whatever package provides a game) and then it would play that game. -- Philip Kaludercic on peregrine