From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Amy Grinn Newsgroups: gmane.emacs.devel Subject: Re: Objed maintenance Date: Sat, 04 May 2024 09:59:52 -0400 Message-ID: References: <85ttjyp9xh.fsf@gmail.com> <87cyqhvp3k.fsf@posteo.net> <87v843qfvf.fsf@posteo.net> <87v843owbj.fsf@posteo.net> <87ttjhpfue.fsf@posteo.net> <8734qz8k2f.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="14240"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: clemera@posteo.net, emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 04 16:00:39 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 1s3FwM-0003TP-IG for ged-emacs-devel@m.gmane-mx.org; Sat, 04 May 2024 16:00:38 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s3Fvi-0003wS-Ot; Sat, 04 May 2024 09:59:58 -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 1s3Fvg-0003w7-HB for emacs-devel@gnu.org; Sat, 04 May 2024 09:59:56 -0400 Original-Received: from mail-qv1-xf2d.google.com ([2607:f8b0:4864:20::f2d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s3Fve-00067M-Ii for emacs-devel@gnu.org; Sat, 04 May 2024 09:59:56 -0400 Original-Received: by mail-qv1-xf2d.google.com with SMTP id 6a1803df08f44-6a077a861e7so4275436d6.2 for ; Sat, 04 May 2024 06:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714831193; x=1715435993; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=Tvm1QUIi17CeVyhZBdo+dVY+NvzPkPdn/heLMjjvPuA=; b=LA8wYvo8lrTZW/d2yFBhQoDxG2dpsM9L7V/pmmT9SZ5Nc60AofkNHTi7Ud2hbu0aT+ 24TeQUDTVQ02Brt/zlZNJhuJ/WY4t14eyJ4uzHNfY5CJbEHUZoM5OYNoZaYHoBOf93ZZ rx++AMhKg1UTM4WQnIASHPX4vCj5Cg+9atuFfr4gOB6T2EYX9vs84mruDjoFKBUdCr9V 2aCaQ+6jb2FNoIEYh07vWHx0mTJCBw3+rKEbN69bJll44waIB2ZRW3juhvfXysl1ZwqJ Jz0henu2F69f3eXSij0KKZVhdZ/qmmBtoSceuCUAN/IQvBbnUcmaNto67ob2o0iRpG0i kESA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714831193; x=1715435993; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Tvm1QUIi17CeVyhZBdo+dVY+NvzPkPdn/heLMjjvPuA=; b=xSw2lNn2ffrWxsCou7fQTJWjvxjY9Aa2nVKxkLicrEcRXYwLi71NLm8mEV0CDbXms/ qh90cPjZFc0GYa1h08IG8zXAvnXgf+KvrYbyN9t4ksFkFg0iV+4xz6FHbXXC7EVoxXcg H151d1QsBnue5+hHU3SxgBBGzRQzkAqE6k0CXQ8E2fdk4lZ6Zlo9Kggi/2oeXuRvwriP 8wa0JOKmAZpdbwb7C6+g0MaDKGe2iV58GeKFm+y70EnYeHgW2gUwnhlELNr1nQDaYydd wMp0i1WaCuTLb8go8jA3hXCop7N4JAPtvybJhq5lmCqBvXqFyj1z4W6+kY36+TaNtmbi BRvg== X-Forwarded-Encrypted: i=1; AJvYcCUvmpA+9X5QLBjJpyO5aKneIen4BAFHf2YnCMEQJpQw5p9d5rt/gtLu2SqEYwMblgUMr5Ic3Lo59gJpPsrLo5ycxPdm X-Gm-Message-State: AOJu0YxaFMfKB90u36m4nYwoTK6fHvFmH1G8w0eNlEv0g5Y3WD1Rz3H4 H5QIwYQ9thT3HjxVWjvjpD27Bk5xWg3cTI9nNHPtt9ZOM6SLjjZA9oNEUAUo X-Google-Smtp-Source: AGHT+IGHIWPoLMwCju9FpCUxxNlamf8031p3P/ZnEFEAoWH4/a+7maXoKGf+Xc1QxNybCVV4maWJyQ== X-Received: by 2002:a05:6214:f07:b0:6a0:f144:f22 with SMTP id gw7-20020a0562140f0700b006a0f1440f22mr7318565qvb.15.1714831192977; Sat, 04 May 2024 06:59:52 -0700 (PDT) Original-Received: from localhost (syn-024-236-139-114.res.spectrum.com. [24.236.139.114]) by smtp.gmail.com with ESMTPSA id lg18-20020a056214549200b0069b4cc9780fsm2175836qvb.2.2024.05.04.06.59.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 May 2024 06:59:52 -0700 (PDT) In-Reply-To: <8734qz8k2f.fsf@posteo.net> (Philip Kaludercic's message of "Fri, 03 May 2024 06:51:20 +0000") Received-SPF: pass client-ip=2607:f8b0:4864:20::f2d; envelope-from=grinn.amy@gmail.com; helo=mail-qv1-xf2d.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, 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:318745 Archived-At: Philip Kaludercic writes: > Amy Grinn writes: > >> Philip Kaludercic writes: >> >>> 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. >> >> That's an interesting idea, kind of like man pages except for >> tutorial >> games. Centralizing the entrypoint for all key games is not exactly >> the >> direction I took though, in the current implementation each package >> is >> responsible for creating a separate entrypoint. > > Right, I recall there was a discussion on creating a configuration > wizard a few years back, and I'd imagine that it might look something > like that as well. > >> I'll have to give it some more thought but I have a few concerns >> already. It probably doesn't address the boilerplate code issue I >> brought up but more importantly it seems like a dual dependency: >> objed-game requires key-game for its implementation and key-game >> requires objed-game to register itself as a valid game. If only one >> of >> the packages is loaded it would necessarily load the other I think? >> Currently, the command objed-game resides in a separate file which >> is >> autoloaded (along with key-game) IFF a user invokes it. > > Why not just wrap it in a with-eval-after-load inside of objed-game? That is a possibility, but wouldn't that make the key-game command very slow the first time? If a dozen packages implement key-games, they will all be loaded at the same time. > I am not familiar with the boiler-plate code (have you sent me the > code and did I just miss it?) To circle back, the discussion was about making key-game an optional dependency. So each package which implements a key game must have the same boilerplate code that asks the user to install key-game and then loads the full implementation. > but if your input is just data, then you could add it to a list that > key-game queries. But key-game may not have been installed, so this would need to be a with-eval-after-load situation as well. And in order to make objed-game visible to key-game even in the situation where objed hasn't been loaded, the form must also be autoloaded. >> When you have the time, I would like to know if you have a specific >> autoload/dependency scheme in mind and if there are any similar >> packages >> already in ELPA which act as a centralized interface for interacting >> with other packages. > > Perhaps the built-in VC package? My autocrypt package is also built > up > in a way that would support this kind of usage, but these tackle > different issues. VC can always just be required by its dependents without installing anything, so I don't think that is a particularly helpful example to me. With autocrypt I see it has the ability to be extended but I couldn't find any actual extension packages. Nevertheless, if an autocrypt extension was submitted to GNU ELPA, would you also suggest the author not rely directly on autocrypt? ... I understand and share your concern about packages like ement. Particularly having a dependency like taxy-magit-section, which has no real semantic meaning and has dependencies of its own which have their OWN dependencies. Since key-game will be the first dependency of objed, has no dependencies of its own, and it's clear what the package does, I don't think this is a directly comparable situation. My overarching concern with your suggestions so far is that it would complicate the dependency structure and make it more difficult to develop and maintain key-game implementations. That is the exact opposite of the purpose of key-game, which is meant to simplify the development of key based tutorial games. I appreciate your time and thoughts but I think I'm going to keep the dependency scheme as it is now: key-game will have no knowledge of where it is being used and each implementation will depend directly on it. -- Best, Amy