Re: Request to distribute Casual packages on NonGNU ELPA

[Stefan Kangas <stefankangas@gmail.com>]

Charles Choi <kickingvegas@gmail.com> 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.