Re: Request to distribute Casual packages on NonGNU ELPA

[Charles Choi]

Stefan -

Thanks for sharing your thoughts on Casual. My responses to your input.

> - 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`.

Is the multitude of Casual packages a block to distribution on NonGNU ELPA?

> - The Casual suite would benefit from having an Info manual.  This is
>  related to the above point; there is a lot of duplicated information
>  in the various README files.

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. 

Is having a Casual Suite Info manual a requirement for distribution on NonGNU 
ELPA? 

> - `casual-dired` changes some of the default Dired keybindings.  I think
>  this is confusing, and reduces the value of `casual-dired` as a
>  learning and/or help tool.  It should be possible to use the transient
>  menu for Dired without being forced to use the new keybindings.
> 
>  This suggests to me that there should be a completely separate mode,
>  perhaps not even part of Casual, to enable the "new and improved"
>  keybindings everywhere: in Dired, in the Casual transient menu, etc.
>  This would broaden its applicability to more use cases; for example, I
>  might want to use the transient menu, but I have little to no interest
>  in non-default Dired keybindings.
>

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, 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.

> - 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.

> Using `require` is redundant, and not best practice: it slows down

Disclosure: I am quite new to Elisp development and am not fully conversant 
with its programming conventions and implementation details. Guidance on 
recommended Elisp programming convention is appreciated.

I will make changes to omit the `require` statement in the documentation and 
decorate all Transient menus to be autoloaded.

> AFAICT, this form does nothing and can be removed.

Disclosure: I am not conversant with `use-package` and do not personally use it.

A perhaps misguided thing I've done is to try to accommodate `use-package` 
users with install instructions tailored for it. 

I can remove all `use-package` instructions for the Casual packages.

> 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.

> 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?

Thanks again for the initial feedback. 

All my best -

Charles

—
Charles Y. Choi, Ph.D.
kickingvegas@gmail.com