From: Amy Grinn <grinn.amy@gmail.com>
To: Philip Kaludercic <philipk@posteo.net>
Cc: clemera@posteo.net, emacs-devel@gnu.org
Subject: Re: Objed maintenance
Date: Sat, 27 Apr 2024 17:51:31 -0400 [thread overview]
Message-ID: <s31wmoijwyk.fsf@gmail.com> (raw)
In-Reply-To: <87v843owbj.fsf@posteo.net> (Philip Kaludercic's message of "Sat, 27 Apr 2024 11:54:08 +0000")
Philip Kaludercic <philipk@posteo.net> writes:
> Amy Grinn <grinn.amy@gmail.com> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Amy Grinn <grinn.amy@gmail.com> 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.
next prev parent reply other threads:[~2024-04-27 21:51 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-18 22:45 Objed maintenance Amy Grinn
2024-04-22 7:22 ` Philip Kaludercic
2024-04-25 12:38 ` Amy Grinn
2024-04-27 10:06 ` Philip Kaludercic
2024-04-27 11:32 ` Amy Grinn
2024-04-27 11:54 ` Philip Kaludercic
2024-04-27 21:51 ` Amy Grinn [this message]
2024-05-01 18:06 ` Philip Kaludercic
2024-05-02 1:39 ` Adam Porter
2024-05-02 6:02 ` Philip Kaludercic
2024-05-02 9:43 ` Adam Porter
2024-05-02 17:09 ` Philip Kaludercic
2024-05-03 4:06 ` Adam Porter
2024-05-03 5:49 ` Philip Kaludercic
2024-05-02 13:13 ` Amy Grinn
2024-05-03 6:51 ` Philip Kaludercic
2024-05-04 13:59 ` Amy Grinn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s31wmoijwyk.fsf@gmail.com \
--to=grinn.amy@gmail.com \
--cc=clemera@posteo.net \
--cc=emacs-devel@gnu.org \
--cc=philipk@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).