unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Charles Choi <kickingvegas@gmail.com>
To: emacs-devel@gnu.org
Cc: Stefan Kangas <stefankangas@gmail.com>,
	Philip Kaludercic <philipk@posteo.net>
Subject: Re: Request to distribute Casual packages on NonGNU ELPA
Date: Thu, 26 Sep 2024 10:01:22 -0700	[thread overview]
Message-ID: <6366C9F7-06A7-44FB-B212-24A9F937A7F4@gmail.com> (raw)
In-Reply-To: <CADwFkmkqyZtppTwaCQDL3yWSKy5KycPcnN20_7=Yi=MjoAjtGw@mail.gmail.com>

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





  reply	other threads:[~2024-09-26 17:01 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-24 21:35 Request to distribute Casual packages on NonGNU ELPA Charles Choi
2024-09-25 17:30 ` Stefan Kangas
2024-09-25 18:30   ` Philip Kaludercic
2024-09-25 20:05     ` Charles Choi
2024-09-25 20:15       ` Philip Kaludercic
2024-09-26 18:06         ` Charles Choi
2024-09-28  3:08         ` Richard Stallman
2024-09-28  8:52           ` Charles Choi
2024-09-28  3:08         ` Richard Stallman
2024-09-27 15:52       ` Philip Kaludercic
2024-09-27 16:04         ` Philip Kaludercic
2024-09-27 18:12         ` Charles Choi
2024-09-27 18:58           ` Stefan Monnier
2024-09-27 20:05           ` Philip Kaludercic
2024-09-28 14:02       ` Philip Kaludercic
2024-09-26 19:08   ` Charles Choi
2024-09-27  4:40     ` Stefan Kangas
2024-09-27 15:34       ` Philip Kaludercic
2024-09-27 16:13         ` Charles Choi
2024-09-27 16:03     ` Stefan Monnier
2024-09-27 19:20       ` Charles Choi
2024-09-30  3:26         ` Richard Stallman
2024-09-30  3:57           ` Emanuel Berg
2024-10-03  3:33             ` Richard Stallman
2024-09-25 23:44 ` Stefan Kangas
2024-09-26 17:01   ` Charles Choi [this message]
2024-09-26 18:05     ` Adam Porter
2024-09-27 15:18       ` Philip Kaludercic
2024-09-27  5:43     ` Stefan Kangas

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=6366C9F7-06A7-44FB-B212-24A9F937A7F4@gmail.com \
    --to=kickingvegas@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=philipk@posteo.net \
    --cc=stefankangas@gmail.com \
    /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).