Request to distribute Casual packages on NonGNU ELPA

Request to distribute Casual packages on NonGNU ELPA

[Charles Choi]

Greetings Emacs Devel -

Over the course of this past year, I have published a number of Emacs packages that offer Transient-based user interfaces for different modes with the moniker of "Casual" on MELPA. I wish to pursue publishing them on NonGNU ELPA and seek guidance on how to move forward with this. I have read the README at https://git.savannah.gnu.org/cgit/emacs/nongnu.git/plain/README.org and believe that these packages all comply with the guidance for package acceptance into NonGNU ELPA.

A current listing of the packages that I wish to distribute on NonGNU ELPA can be found at the link https://melpa.org/#/?q=kickingvegas%20casual

Thanks and best regards -

Charles

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

Re: Request to distribute Casual packages on NonGNU ELPA

[Stefan Kangas]

Charles Choi <kickingvegas@gmail.com> writes:

> Greetings Emacs Devel -
>
> Over the course of this past year, I have published a number of Emacs packages that offer Transient-based user interfaces for different modes with the moniker of "Casual" on MELPA. I wish to pursue publishing them on NonGNU ELPA and seek guidance on how to move forward with this. I have read the README at https://git.savannah.gnu.org/cgit/emacs/nongnu.git/plain/README.org and believe that these packages all comply with the guidance for package acceptance into NonGNU ELPA.
>
> A current listing of the packages that I wish to distribute on NonGNU ELPA can be found at the link https://melpa.org/#/?q=kickingvegas%20casual
>
> Thanks and best regards -
>
> Charles

I'm copying in Philip and Stefan Monnier.

Re: Request to distribute Casual packages on NonGNU ELPA

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Charles Choi <kickingvegas@gmail.com> writes:
>
>> Greetings Emacs Devel -
>>
>> Over the course of this past year, I have published a number of
>> Emacs packages that offer Transient-based user interfaces for
>> different modes with the moniker of "Casual" on MELPA. I wish to
>> pursue publishing them on NonGNU ELPA and seek guidance on how to
>> move forward with this. I have read the README at
>> https://git.savannah.gnu.org/cgit/emacs/nongnu.git/plain/README.org
>> and believe that these packages all comply with the guidance for
>> package acceptance into NonGNU ELPA.
>>
>> A current listing of the packages that I wish to distribute on NonGNU
>> ELPA can be found at the link
>> https://melpa.org/#/?q=kickingvegas%20casual

For the record, are you proposing for all these packages to be added?

https://github.com/kickingvegas/casual-symbol-overlay/
https://github.com/kickingvegas/casual-suite/
https://github.com/kickingvegas/casual-re-builder/
https://github.com/kickingvegas/casual-lib/
https://github.com/kickingvegas/casual-isearch/
https://github.com/kickingvegas/casual-info/
https://github.com/kickingvegas/casual-ibuffer/
https://github.com/kickingvegas/casual-editkit/
https://github.com/kickingvegas/casual-dired/
https://github.com/kickingvegas/casual-calc/
https://github.com/kickingvegas/casual-bookmarks/
https://github.com/kickingvegas/casual-avy/
https://github.com/kickingvegas/casual-agenda/

I haven't tried the code yet, and reviewing these will take some time,
but my understanding that this is reinventing a lot of Emacs
functionality using Transient, right?

[ General comment: It would be nice if bug#52058 could be resolved,
  because for my personal taste Transient is not really ready for
  general usage, as it tries to implement its own event loop, instead of
  hooking into Emacs own, which inevitably fails to do.  For example,
  there is a custom binding for isearch, but nothing for occur or other
  search functionality, shadowing all other functionality -- you can't
  even do M-x!  For those of us who dislike frames from popping up I
  would have though that setting `transient-show-popup' to nil would be
  a nice fix, but for some reason you have to toggle the popup with C-t
  instead of C-h.  Perhaps I am just doing something wrong, and there is
  a good explanation for everything...  Sorry for the rant. ]

Do you have any preferred or recommended order in which you think that I
should review the code?  From the names I am guessing that casual-lib is
a dependency that the others share?

Another question that I can only raise now as I haven't looked at the
code in greater detail yet is how deep the transient dependency goes.
Would it be possible to re-use quick-help instead?  I had sketched
something along those lines a few months back, where a map could bind a
pseudo-key to return a `help-quick-sections' like structure.  The
advantage is that you only have to list commands and descriptions,
without trying to bind key again inside of Transient, as I understand it
being the case right now.

>> Thanks and best regards -
>>
>> Charles
>
> I'm copying in Philip and Stefan Monnier.

Thanks, I missed the message.

-- 
	Philip Kaludercic on siskin

Re: Request to distribute Casual packages on NonGNU ELPA

[Charles Choi]

Philip - 

Thanks for responding. My answers to your questions as follows:

> I haven't tried the code yet, and reviewing these will take some time,
> but my understanding that this is reinventing a lot of Emacs
> functionality using Transient, right?

The Casual packages should be viewed as user interface porcelains to existing Emacs functionality and takes great effort to not "reinvent" nor re-implement existing commands and their associated variables. No functions are advised by Casual. The Casual packages do however re-imagine the interactive user interfaces to said commands and variables as keyboard-driven menus.

> Do you have any preferred or recommended order in which you think that I
> should review the code?  From the names I am guessing that casual-lib is
> a dependency that the others share?

casual-lib is a common library to all the Casual packages. It is recommended that this package be reviewed first. casual-suite is an umbrella package that includes all Casual packages and as such should be reviewed last.

At current there are 13 Casual packages to review. Here's a recommended order of review that skews toward the simpler packages to be reviewed earlier. That said the only strict guidance is to review casual-lib first and casual-suite last.

https://github.com/kickingvegas/casual-lib/

https://github.com/kickingvegas/casual-isearch/
https://github.com/kickingvegas/casual-symbol-overlay/
https://github.com/kickingvegas/casual-avy/
https://github.com/kickingvegas/casual-re-builder/
https://github.com/kickingvegas/casual-dired/
https://github.com/kickingvegas/casual-bookmarks/
https://github.com/kickingvegas/casual-calc/
https://github.com/kickingvegas/casual-ibuffer/
https://github.com/kickingvegas/casual-info/
https://github.com/kickingvegas/casual-agenda/
https://github.com/kickingvegas/casual-editkit/

https://github.com/kickingvegas/casual-suite/


> Another question that I can only raise now as I haven't looked at the
> code in greater detail yet is how deep the transient dependency goes.
> Would it be possible to re-use quick-help instead?  I had sketched
> something along those lines a few months back, where a map could bind a
> pseudo-key to return a `help-quick-sections' like structure.  The
> advantage is that you only have to list commands and descriptions,
> without trying to bind key again inside of Transient, as I understand it
> being the case right now.

The Casual packages use Transient to implement keyboard-driven menus with opinionated bindings. I consider these binding decisions to be core to the value of Casual in that they support a truly hand-crafted user experience. I have no interest in refactoring their behavior to use quick-help, nor in maintaining strict conformance to existing default command bindings. That said, many existing default command bindings are supported in Casual. If any of these positions are a block to publication on NonGNU ELPA, I will retract my request for review. Hopefully though this is not the case as I have the greatest enthusiasm to see these packages being reviewed and published on ELPA.


All my best -

Charles

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

Re: Request to distribute Casual packages on NonGNU ELPA

[Philip Kaludercic]

Charles Choi <kickingvegas@gmail.com> writes:

> Philip - 
>
> Thanks for responding. My answers to your questions as follows:
>
>> I haven't tried the code yet, and reviewing these will take some time,
>> but my understanding that this is reinventing a lot of Emacs
>> functionality using Transient, right?
>
> The Casual packages should be viewed as user interface porcelains to
> existing Emacs functionality and takes great effort to not "reinvent"
> nor re-implement existing commands and their associated variables. No
> functions are advised by Casual. The Casual packages do however
> re-imagine the interactive user interfaces to said commands and
> variables as keyboard-driven menus.

Sorry, I was not clear: Read the "Reinventing" as "Rebinding".  And IIUC
then this is the case.

>> Do you have any preferred or recommended order in which you think that I
>> should review the code?  From the names I am guessing that casual-lib is
>> a dependency that the others share?
>
> casual-lib is a common library to all the Casual packages. It is
> recommended that this package be reviewed first. casual-suite is an
> umbrella package that includes all Casual packages and as such should
> be reviewed last.
>
> At current there are 13 Casual packages to review. Here's a
> recommended order of review that skews toward the simpler packages to
> be reviewed earlier. That said the only strict guidance is to review
> casual-lib first and casual-suite last.
>
> https://github.com/kickingvegas/casual-lib/
>
> https://github.com/kickingvegas/casual-isearch/
> https://github.com/kickingvegas/casual-symbol-overlay/
> https://github.com/kickingvegas/casual-avy/
> https://github.com/kickingvegas/casual-re-builder/
> https://github.com/kickingvegas/casual-dired/
> https://github.com/kickingvegas/casual-bookmarks/
> https://github.com/kickingvegas/casual-calc/
> https://github.com/kickingvegas/casual-ibuffer/
> https://github.com/kickingvegas/casual-info/
> https://github.com/kickingvegas/casual-agenda/
> https://github.com/kickingvegas/casual-editkit/
>
> https://github.com/kickingvegas/casual-suite/

Thanks.

>> Another question that I can only raise now as I haven't looked at the
>> code in greater detail yet is how deep the transient dependency goes.
>> Would it be possible to re-use quick-help instead?  I had sketched
>> something along those lines a few months back, where a map could bind a
>> pseudo-key to return a `help-quick-sections' like structure.  The
>> advantage is that you only have to list commands and descriptions,
>> without trying to bind key again inside of Transient, as I understand it
>> being the case right now.
>
> The Casual packages use Transient to implement keyboard-driven menus
> with opinionated bindings. I consider these binding decisions to be
> core to the value of Casual in that they support a truly hand-crafted
> user experience. I have no interest in refactoring their behavior to
> use quick-help, nor in maintaining strict conformance to existing
> default command bindings. That said, many existing default command
> bindings are supported in Casual. If any of these positions are a
> block to publication on NonGNU ELPA, I will retract my request for
> review. Hopefully though this is not the case as I have the greatest
> enthusiasm to see these packages being reviewed and published on ELPA.

No, none of this is blocking.  I just find it worthwhile to discuss some
more foundational questions before adding a package to ELPA, as an
outsides perspective can sometimes help to uncover questions that an
author might not have considered until now.

>
> All my best -
>
> Charles
>
> —
> Charles Y. Choi, Ph.D.
> kickingvegas@gmail.com
>
>
>

-- 
	Philip Kaludercic on siskin

Re: Request to distribute Casual packages on NonGNU ELPA

[Charles Choi]

Philip -

Appreciate your clarifications. 

With regards to your comment on foundational questions, as best as I understand it, `quick-help` offers some level of control over display layout but is fundamentally a tool to provide informational help about a mode's bindings (typically default) to its commands. In contrast, Transient menus are designed to be a direct interface to the commands. Casual leverages the Transient library to create a keyboard-driven menu interface to this effect.

For Casual package users, a design intent of the Casual menus is to be the _primary_ means of accessing a mode's commands, as opposed to the current practice of using keybindings or the mini-buffer prompt as a primary interface. It is not a design intent of Casual to help on-board users to the existing default bindings of a mode, nor to cater to users who already know them for which Casual is not their intended audience.

In my view, tools such as `quick-help` and `which-key` reinforce keybindings and mini-buffer prompts as the primary user interface to a mode's commands. Casual is an attempt to offer an alternate primary interface, in this case, hand-crafted keyboard-driven menus. This said, Casual has no design intent to be a mutually exclusive user interface. All existing user interfaces to commands (keybinding, mini-buffer prompt, mouse menus) are still available. 



Regards -

Charles

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

Re: Request to distribute Casual packages on NonGNU ELPA

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > No, none of this is blocking.  I just find it worthwhile to discuss some
  > more foundational questions before adding a package to ELPA, as an
  > outsides perspective can sometimes help to uncover questions that an
  > author might not have considered until now.

That is a very useful practice -- we should always consider some of
these questions for every package.  Their answers show what kinds of
advantages and disadvantages incorporating the package could lead to.

In some cases, the answer is obvious.  If there is a popular
programming language called Bump and someone offers to contribute a
major mode for Bump code, we know what sort of good that can do.

But when it isn't obvious, it is good to raise the question.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Request to distribute Casual packages on NonGNU ELPA

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

A basic question that occurs to me is:
what sort of use is this package intended to serve?

For instance, is it meant as an alternative keyboard interface
that a user would adopt permanently>?

Is it meant as a transitional step for an Emacs beginner
who would (we hope) get used to the standard interface?

Is it meant to be used occasionally, for trying commands
that user is not accustomed to using?

Or something else?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Request to distribute Casual packages on NonGNU ELPA

[Charles Choi]

Dr. Stallman -

First off, my thanks and appreciation of your contributions to Emacs and to the GNU project. To answer your questions and then some:

1. The Casual project is an effort to build keyboard-driven menus as the primary interface to different modes offered in the Emacs ecosystem. These menus offer users discovery and recall of commands. These modes are either built-in or third party. 

2. It is not a design intent of Casual to help on-board users to the existing default bindings of a mode, nor to cater to users who already know them for which Casual is not their intended audience. That said, many existing default Emacs bindings are replicated in Casual. Such correspondence should be considered incidental.
   
3. Casual has no aims to be a mutually exclusive user interface. All existing user interfaces to commands (keybinding, mini-buffer prompt, mouse menus) are still available to the user.

4. Related to 3, Casual has no intent to exhaustively cover all modes available in Emacs with keyboard-driven menus.

5. The primary audience of these packages is me, Charles Y. Choi. The binding choices are solely my opinion. I have elected to share them in public as I believe others might wish to use a keyboard-driven interface in Emacs and are comfortable with my opinions.

6. I have submitted my packages for review for NonGNU ELPA publishing at the request of several users who feel that it would have value being distributed there. If my stated positions are not in alignment with ELPA's values and objectives, then please let me know immediately and I will not pursue this matter further.


Hopefully this clarifies my intent. 
   
Regards -

Charles


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

Re: Request to distribute Casual packages on NonGNU ELPA

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

Charles Choi <kickingvegas@gmail.com> writes:


[...]

> https://github.com/kickingvegas/casual-lib/

My first impression that the project seems a tad over-engineered for
what is basically just a single file, but that's your prerogative.  One
point in "developer.org", you write

- Menus must not exceed 80 characters in length.
  - Rationale: Casual Lib follows suit with current Elisp format to conform to the line width of an ADM-3A terminal.

but I don't know where you got that information from?
https://www.emacswiki.org/emacs/EightyColumnRule e.g. says this goes
back to punch cards (which is the story I had in my head).

Regarding casual-lib.el:  Do you actually need Emacs 29?  Package lint
seems to be fine with lowering the version to Emacs 25.  Other than
that, here are a few comments and suggestions:


[-- Attachment #2: Type: text/plain, Size: 3512 bytes --]

diff --git a/lisp/casual-lib.el b/lisp/casual-lib.el
index 52fbf16..93111ba 100644
--- a/lisp/casual-lib.el
+++ b/lisp/casual-lib.el
@@ -6,7 +6,7 @@
 ;; URL: https://github.com/kickingvegas/casual-lib
 ;; Keywords: tools
 ;; Version: 1.1.3
-;; Package-Requires: ((emacs "29.1") (transient "0.6.0"))
+;; Package-Requires: ((emacs "25.1") (transient "0.6.0"))
 
 ;; This program is free software; you can redistribute it and/or modify
 ;; it under the terms of the GNU General Public License as published by
@@ -25,11 +25,12 @@
 
 ;; Library routines for Casual user interfaces.
 
-;; INSTALLATION
-;; Casual Lib is intended to be implicitly installed as a dependency to the
-;; Casual suite of packages. If you are running Emacs 29.x, you will need to
-;; configure `package-install-upgrade-built-in' to t to support an update of the
-;; built-in package `transient'.
+;;;; Installation
+
+;; Casual Lib is intended to be implicitly installed as a dependency
+;; to the Casual suite of packages.  If you are running Emacs 29.x,
+;; you will need to configure `package-install-upgrade-built-in' to t
+;; to support an update of the built-in package `transient'.
 
 ;;; Code:
 (require 'transient)
@@ -41,7 +42,7 @@
 If non-nil, customize Casual user interfaces to hide navigation controls for
 `transient-quit-all' (control-q) and `transient-quit-one' (control-g)."
   :type 'boolean
-  :group 'casual)
+  :group 'casual)			;please add a `defgroup' before referring to it!  You don't need to specify the :group afterwards.
 
 (defun casual-lib-customize-casual-lib-hide-navigation ()
   "Customize `casual-lib-hide-navigation'.
@@ -75,14 +76,13 @@ plain ASCII-range string."
   (let* ((db db)
          (unicode casual-lib-use-unicode)
          (item (alist-get key db)))
-    (if unicode
-        (nth 0 (eval item))
-      (nth 1 (eval item)))))
+    (nth (if unicode 0 1) (eval item t))))
 
 ;; Predicates
-(defun casual-lib-display-line-numbers-mode-p ()
+(defun casual-lib-display-line-numbers-mode-p () ;why do you have this
+						 ;as a predicate?
   "Predicate to test if `display-line-numbers-mode' is enabled."
-  (if display-line-numbers t nil))
+  (bound-and-true-p display-line-numbers))
 
 (defun casual-lib-buffer-writeable-p ()
   "Predicate to test if buffer is writeable."
@@ -98,11 +98,8 @@ plain ASCII-range string."
 
 (defun casual-lib-quit-all-hide-navigation-p ()
   "Predicate for hiding navigation for the `transient-quit-all' command."
-  (if casual-lib-hide-navigation
-      t
-    (if transient--stack
-        nil
-      t)))
+  (or casual-lib-hide-navigation
+      (not transient--stack)))		;btw. are you allowed to use this internal variable?
 
 ;; Labels
 (defun casual-lib--variable-to-checkbox (v)
@@ -135,7 +132,7 @@ V is either nil or non-nil."
   "Casual suffix to call `transient-quit-all'."
   :transient nil
   :if-not #'casual-lib-quit-all-hide-navigation-p
-  :key "C-q"
+  :key "C-q"				;IIUC this is the binding that closes your transient buffer?  Could this be rebound to the more conventional "q"?
   :description "Dismiss"
   (interactive)
   (transient-quit-all))
@@ -179,7 +176,7 @@ Note that this variable affects all Casual user interfaces."
                   casual-lib-hide-navigation
                   "Hide Navigation Commands"))
   (interactive)
-  (casual-lib-customize-casual-lib-hide-navigation))
+  (casual-lib-customize-casual-lib-hide-navigation)) ;why not just inline the above definition?
 
 (provide 'casual-lib)
 ;;; casual-lib.el ends here

[-- Attachment #3: Type: text/plain, Size: 34 bytes --]


-- 
	Philip Kaludercic on siskin

Re: Request to distribute Casual packages on NonGNU ELPA

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 207 bytes --]

Philip Kaludercic <philipk@posteo.net> writes:

> Charles Choi <kickingvegas@gmail.com> writes:
>
>
> [...]
>
>> https://github.com/kickingvegas/casual-lib/
>

[...]

Another little tip in read-version.sh:


[-- Attachment #2: Type: text/plain, Size: 281 bytes --]

diff --git a/scripts/read-version.sh b/scripts/read-version.sh
index 95859b0..51e04a5 100755
--- a/scripts/read-version.sh
+++ b/scripts/read-version.sh
@@ -3,4 +3,4 @@
 # Copyright 2024 Charles Y. Choi
 #
 
-grep 'Version: ' $1 | awk '{print $3}'
+awk '/Version: / {print $3}' $1

[-- Attachment #3: Type: text/plain, Size: 66 bytes --]


ought to have the same effect.

-- 
	Philip Kaludercic on siskin

Re: Request to distribute Casual packages on NonGNU ELPA

[Charles Choi]

Philip -

Appreciate the input. My responses to your feedback below:

> My first impression that the project seems a tad over-engineered for

This was a deliberate decision on my part in undertaking the development of Casual. As I am new to developing Elisp, I wanted to understand better what it would be like to build a library of Elisp packages using contemporary software engineering practices.

> but I don't know where you got that information from?  (referencing ADM-3A)
> https://www.emacswiki.org/emacs/EightyColumnRule e.g. says this goes
> back to punch cards (which is the story I had in my head).

My reference to the ADM-3A was written "off the cuff", as that was one of the first terminals I had worked with. I will amend to reference the 80 column rule.

> Regarding casual-lib.el:  Do you actually need Emacs 29?  Package lint
> seems to be fine with lowering the version to Emacs 25.

In specifying requirements, I've taken a more conservative tack of listing a configuration that I am able to test, in this case, Emacs 29 running on macOS and Linux. I do not have the time nor resources to fully test older versions of Emacs and associated packages, much less test on different platforms.

As I am new to Elisp publishing, I was and still am reluctant to trust lint tools to verify behavior on older versions of Emacs and associated packages as it would commit me to supporting them. Is lint sufficient enough for verification of correct behavior on lower versions of Emacs? What happens when it isn't?

> + :group 'casual)			;please add a `defgroup' before referring to it!  You don't need to specify the :group afterwards.

Will amend.

> +(defun casual-lib-display-line-numbers-mode-p () ;why do you have this as a predicate?

For reasons I do not understand or have clear enough knowledge about, I could not write an expression to pass to a Transient macro, but instead has to pass a function symbol to get working code. Hence making a predicate here.

> +      (not transient--stack)))		;btw. are you allowed to use this internal variable?

This was guidance provided by Jonas Bernoulli, maintainer of Transient. https://github.com/magit/transient/discussions/290

> +  :key "C-q"				;IIUC this is the binding that closes your transient buffer?  Could this be rebound to the more conventional "q"?

Initially I did. Guidance from Jonas Bernoulli argued that Transient convention is to use C-q as detailed in https://magit.vc/manual/transient/FAQ.html#Why-does-q-not-quit-popups-anymore_003f-1

> +  (casual-lib-customize-casual-lib-hide-navigation)) ;why not just inline the above definition?

Likely over-modularization on my part. Will audit all Casual packages and if this usage is singular, will inline.

> +awk '/Version: / {print $3}' $1

Nice in that I don't have to make a call to grep. Will verify and amend.

Thanks for taking the time to review.

Regards -

Charles


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

Re: Request to distribute Casual packages on NonGNU ELPA

[Stefan Monnier]

> In specifying requirements, I've taken a more conservative tack of listing
> a configuration that I am able to test, in this case, Emacs 29 running on
> macOS and Linux. I do not have the time nor resources to fully test older
> versions of Emacs and associated packages, much less test on
> different platforms.

There's a big gap between "recommended/tested versions" and "required
versions".  When specifying dependencies, please use the more lenient
threshold.  We don't want to follow the treadmill trap of having to be
always at the edge, bleeding.

Usually the "required" versions are those for which you have good
reasons to suspect anything below simply won't work.
[ ELisp development conventions are very different from Rust/Go/... ]

You can then state in the README which versions are known to work
and/or recommended.

> As I am new to Elisp publishing, I was and still am reluctant to trust lint
> tools to verify behavior on older versions of Emacs and associated packages
> as it would commit me to supporting them.  Is lint sufficient enough for
> verification of correct behavior on lower versions of Emacs?

You can't verify correct behavior in any version of Emacs at all anyway,
because it depends on way too many factors.  At best you can test a few
specific behaviors in a few specific versions in a few
specific configurations.
The upside is that noone will sue or fire you when something doesn't
work quite right.

> What happens when it isn't?

Either nothing because it so happens that noone used your package on
that older version of Emacs enough to bump into the problem.  Or you may
get an email about someone having trouble with your package, with luck
it might even include a patch.  Personally if it doesn't include a patch
and the Emacs version is "too old" or "too weird" for my taste,
I consider it's the responsibility of the user of this odd circumstance
to do the bulk of tracking down the bug and coming up with a fix.

>> +(defun casual-lib-display-line-numbers-mode-p () ;why do you have this as a predicate?
>
> For reasons I do not understand or have clear enough knowledge about,
> I could not write an expression to pass to a Transient macro, but instead
> has to pass a function symbol to get working code. Hence making
> a predicate here.

[ In those kinds of situations, I usually try to put a comment in the
  code stating it, so my future self isn't tempted to undo the
  workaround I came up with.  ]


        Stefan

Re: Request to distribute Casual packages on NonGNU ELPA

[Philip Kaludercic]

Charles Choi <kickingvegas@gmail.com> writes:

> Philip -
>
> Appreciate the input. My responses to your feedback below:
>
>> My first impression that the project seems a tad over-engineered for
>
> This was a deliberate decision on my part in undertaking the
> development of Casual. As I am new to developing Elisp, I wanted to
> understand better what it would be like to build a library of Elisp
> packages using contemporary software engineering practices.

OK, it is just culturally uncommon for Elisp code (of the size as your
packages are) to be developed in such a way.

>> but I don't know where you got that information from?  (referencing ADM-3A)
>> https://www.emacswiki.org/emacs/EightyColumnRule e.g. says this goes
>> back to punch cards (which is the story I had in my head).
>
> My reference to the ADM-3A was written "off the cuff", as that was one
> of the first terminals I had worked with. I will amend to reference
> the 80 column rule.

1+

>> Regarding casual-lib.el:  Do you actually need Emacs 29?  Package lint
>> seems to be fine with lowering the version to Emacs 25.
>
> In specifying requirements, I've taken a more conservative tack of
> listing a configuration that I am able to test, in this case, Emacs 29
> running on macOS and Linux. I do not have the time nor resources to
> fully test older versions of Emacs and associated packages, much less
> test on different platforms.
>
> As I am new to Elisp publishing, I was and still am reluctant to trust
> lint tools to verify behavior on older versions of Emacs and
> associated packages as it would commit me to supporting them. Is lint
> sufficient enough for verification of correct behavior on lower
> versions of Emacs? What happens when it isn't?

Usually yes, but if not someone will tell you and you can adjust it.  As
insinuated above, Elisp development is more /casual/ and direct.  If
someone finds a problem despite what `package-lint' says, they are more
likely to report it to you in a constructive way.

>> + :group 'casual)			;please add a `defgroup' before referring to it!  You don't need to specify the :group afterwards.
>
> Will amend.
>
>> +(defun casual-lib-display-line-numbers-mode-p () ;why do you have this as a predicate?
>
> For reasons I do not understand or have clear enough knowledge about,
> I could not write an expression to pass to a Transient macro, but
> instead has to pass a function symbol to get working code. Hence
> making a predicate here.
>
>> +      (not transient--stack)))		;btw. are you allowed to use this internal variable?
>
> This was guidance provided by Jonas Bernoulli, maintainer of Transient. https://github.com/magit/transient/discussions/290

Then it's fine ^^  Though it would be nice if there were some explicit
API for that...

>> +  :key "C-q"				;IIUC this is the binding that closes your transient buffer?  Could this be rebound to the more conventional "q"?
>
> Initially I did. Guidance from Jonas Bernoulli argued that Transient
> convention is to use C-q as detailed in
> https://magit.vc/manual/transient/FAQ.html#Why-does-q-not-quit-popups-anymore_003f-1

Oh, I did not know about this.  Forget about that then.

>> +  (casual-lib-customize-casual-lib-hide-navigation)) ;why not just inline the above definition?
>
> Likely over-modularization on my part. Will audit all Casual packages and if this usage is singular, will inline.

Great, I find that would help with readability.

>> +awk '/Version: / {print $3}' $1
>
> Nice in that I don't have to make a call to grep. Will verify and amend.
>
> Thanks for taking the time to review.
>
> Regards -
>
> Charles
>
>
> —
> Charles Y. Choi, Ph.D.
> kickingvegas@gmail.com
>
>

-- 
	Philip Kaludercic on siskin

Re: Request to distribute Casual packages on NonGNU ELPA

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

Charles Choi <kickingvegas@gmail.com> writes:

> https://github.com/kickingvegas/casual-isearch/
> https://github.com/kickingvegas/casual-symbol-overlay/
> https://github.com/kickingvegas/casual-avy/
> https://github.com/kickingvegas/casual-re-builder/
> https://github.com/kickingvegas/casual-dired/
> https://github.com/kickingvegas/casual-bookmarks/
> https://github.com/kickingvegas/casual-calc/
> https://github.com/kickingvegas/casual-ibuffer/
> https://github.com/kickingvegas/casual-info/
> https://github.com/kickingvegas/casual-agenda/
> https://github.com/kickingvegas/casual-editkit/

I have taken a look at all the repositories, with the exception of
casual-calc, and the mostly seem the follow the same pattern.  I don't
have any special comments on the transient menus and their auxiliary
functions.  A little tip, the casual-...-about commands can be
simplified by just generating a custom *Help* buffer:


[-- Attachment #2: Type: text/plain, Size: 1107 bytes --]

diff --git a/lisp/casual-isearch-settings.el b/lisp/casual-isearch-settings.el
index f93aea2..78e2573 100644
--- a/lisp/casual-isearch-settings.el
+++ b/lisp/casual-isearch-settings.el
@@ -45,8 +45,11 @@
   (interactive)
   (customize-group "isearch"))
 
-(defun casual-isearch-about-isearch ()
-  "Casual I-Search is a Transient menu for I-Search.
+(defun casual-isearch-about ()		;this might be better located in a manual
+  "About information for Casual I-Search."
+  (interactive)
+  (with-help-window "*About Casual Isearch*"
+    (princ "Casual I-Search is a Transient menu for I-Search.
 
 Learn more about using Casual I-Search at our discussion group on GitHub.
 Any questions or comments about it should be made there.
@@ -65,13 +68,7 @@ San Francisco, California.
 
 Thank you for using Casual I-Search.
 
-Always choose love."
-  (ignore))
-
-(defun casual-isearch-about ()
-  "About information for Casual I-Search."
-  (interactive)
-  (describe-function #'casual-isearch-about-isearch))
+Always choose love.")))
 
 (provide 'casual-isearch-settings)
 ;;; casual-isearch-settings.el ends here

[-- Attachment #3: Type: text/plain, Size: 1002 bytes --]


Other than that I can just strongly support the point that others have
raised, that merging the functionality into a single package would be
preferable.  While at it, I would also recommend to keep everything
related to what is currently a single package in one file.  Drop the
...-version.el files, and instead refer the users to use
describe-package (or analogous commands) if they want to know what
version they have installed.

As a upgrade procedure, I would recommend just copying everything into
"casual-suite" and updating the remaining package with a top-level

  (warn "This package has been deprecated, please install `casual-suite'")

A general comment is that I would recommend not treating this as a
commercial product or service.  It is just an Emacs package.

>
> https://github.com/kickingvegas/casual-suite/

[...]

> All my best -
>
> Charles
>
> —
> Charles Y. Choi, Ph.D.
> kickingvegas@gmail.com
>
>
>
>
>

-- 
	Philip Kaludercic on siskin

Re: Request to distribute Casual packages on NonGNU ELPA

[Charles Choi]

Stefan - 

Please clarify which persons are decision making in the review of the Casual Packages for NonGNU ELPA so I can focus my attention to in response.

At current I understand that it is you, Philip Kaludercic, and Stefan Monnier.

Thanks! 

Charles

Re: Request to distribute Casual packages on NonGNU ELPA

[Stefan Kangas]

Charles Choi <kickingvegas@gmail.com> writes:

> Please clarify which persons are decision making in the review of the
> Casual Packages for NonGNU ELPA so I can focus my attention to in
> response.
>
> At current I understand that it is you, Philip Kaludercic, and Stefan
> Monnier.

AFAIU, the decision is ultimately with Stefan Monnier and Philip
Kaludercic, who maintain (Non-)GNU ELPA.

Re: Request to distribute Casual packages on NonGNU ELPA

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Charles Choi <kickingvegas@gmail.com> writes:
>
>> Please clarify which persons are decision making in the review of the
>> Casual Packages for NonGNU ELPA so I can focus my attention to in
>> response.

It is a public mailing list, everyone is free to comment and raise
worthwhile points.

>> At current I understand that it is you, Philip Kaludercic, and Stefan
>> Monnier.
>
> AFAIU, the decision is ultimately with Stefan Monnier and Philip
> Kaludercic, who maintain (Non-)GNU ELPA.

Anyone with access to elpa.git/nongnu.git can add a package, it is just
that we usually respond to messages regarding the addition of new
packages.

-- 
	Philip Kaludercic on siskin

Re: Request to distribute Casual packages on NonGNU ELPA

[Charles Choi]

> On Sep 27, 2024, at 8:34 AM, Philip Kaludercic <philipk@posteo.net> wrote:
> 
> It is a public mailing list, everyone is free to comment and raise
> worthwhile points.


Understood. That said, as this is the first time I am going through this process, I am uncomfortable answering to people who I do not know if they are empowered to access elpa.git/nongnu.git. I do not want to make change requests or make rationalizations to persons who do not have this access as their opinions of my work may not reflect those who do. 


Regards - 

Charles


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

Re: Request to distribute Casual packages on NonGNU ELPA

[Stefan Monnier]

> Please clarify which persons are decision making in the review of the Casual
> Packages for NonGNU ELPA so I can focus my attention to in response.

There is very little "decision making" involved here.
We rarely decide to reject packages.

Instead, those with write access to `nongnu.git` (we're talking more
than 100 persons) may add it/them if they like it/them.

When it comes to your packages, here's my quick assessment:

- The functionality is fine.
- A cursory check suggests there is no technical that should get in the
  way either.

So it's just a matter of getting someone to do the work.

I'd have probably already added the whole if it were a single package.
But the work involved is proportional to the number of packages, and the
ratio of work compared to what each package provides is somewhat
discouraging because each package contains a relatively small amount of
code compared to the amount of boilerplate copied N times.

Your packages aren't the only ones in that situation, but when faced
with N such package in a block I can't help but hope that "someone else
will do it".  🙁


        Stefan


PS: I'd also recommend you get rid of all the `casual-*-version`
thingies.  It's just not worth the trouble IME.  You can get pretty much
the same info in a generic way from the package managers for the rare
cases where it's useful.

Re: Request to distribute Casual packages on NonGNU ELPA

[Charles Choi]

Stefan -

Thanks for your clarifications. In particular I now have a better understanding of the logistical challenges in reviewing a bundle of packages for ELPA by the participants here. I will consider a migration plan to consolidate all the Casual menus into a single package. That said, this is a significant ask and will require existing Casual users to change their setups. This migration plan will also likely impact web searches which are significant to these packages discovery. A final decision on consolidation has not been made and as such I request that review of the current set of Casual packages for NonGNU ELPA distribution be suspended until further notice.

I express my thanks and appreciation for the feedback already given to Casual.


Regards -

Charles

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

Re: Request to distribute Casual packages on NonGNU ELPA

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Thanks for your clarifications. In particular I now have a better
  > understanding of the logistical challenges in reviewing a bundle
  > of packages for ELPA by the participants here. I will consider a
  > migration plan to consolidate all the Casual menus into a single
  > package.

Another approach, which might or might not be better here,
is to put these customiaions into major modes.  There are
many Emacs features that, by convention, major modes
should customize.

I don't have an opinion aboit whether this approach would be better
here, I simply suggest consider the question.

             That said, this is a significant ask and will require
  > existing Casual users to change their setups.

The cost of a transient like that is easy to justify
for switching to the approach that is best in the long term,
If there is a switch to be made, now is the time to do it.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Request to distribute Casual packages on NonGNU ELPA

[Emanuel Berg]

[-- Attachment #1: Type: text/plain, Size: 83 bytes --]

Richard Stallman [...]

Hello RMS, I just made this for you.

I hope you like it!


[-- Attachment #2: ge.png --]
[-- Type: image/png, Size: 584 bytes --]

[-- Attachment #3: Type: text/plain, Size: 61 bytes --]


-- 
underground experts united
https://dataswamp.org/~incal

Re: Request to distribute Casual packages on NonGNU ELPA

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Its cue -- thank you.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Request to distribute Casual packages on NonGNU ELPA

[Stefan Kangas]

Charles Choi <kickingvegas@gmail.com> writes:

> Greetings Emacs Devel -
>
> Over the course of this past year, I have published a number of Emacs
> packages that offer Transient-based user interfaces for different
> modes with the moniker of "Casual" on MELPA. I wish to pursue
> publishing them on NonGNU ELPA and seek guidance on how to move
> forward with this. I have read the README at
> https://git.savannah.gnu.org/cgit/emacs/nongnu.git/plain/README.org
> and believe that these packages all comply with the guidance for
> package acceptance into NonGNU ELPA.
>
> A current listing of the packages that I wish to distribute on NonGNU
> ELPA can be found at the link
> https://melpa.org/#/?q=kickingvegas%20casual

I have given the `casual-bookmarks` command a spin, and I have looked at
a few others.  The screenshots really helped here.  Please find below my
review of Casual, and some ideas for potential improvements.  I hope you
find it useful.

AFAICT, Casual essentially provides something similar to
`which-key-show-full-mode` but with a hand-crafted display based on
transient instead of the auto-generated display which-key has.  Another
comparison is `help-quick-toggle`, though connected to the current major
mode.  It could also be compared to the many various `hydra` recipes
floating around out there.

I quite like it to the extent that it does the above, FWIW.  But there
are also some things that I think could be improved.

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

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

- I would put Casual on GNU ELPA, if possible.

I also have some comments based on the README.md for `casual-bookmarks`:

> Casual Bookmarks is an opinionated Transient-based user interface for
> Emacs Bookmarks.
>
> INSTALLATION (require 'casual-bookmarks) ;; optional

Using `require` is redundant, and not best practice: it slows down
starting Emacs and requires more memory, even if the commands are never
used.  All useful entry-points should simply be autoloaded (this is done
automatically by package.el on install).

> (keymap-set bookmark-bmenu-mode-map "C-o" #'casual-bookmarks-tmenu)
>
> Alternately with `use-package': (use-package bookmark
>   :ensure nil :defer t)

AFAICT, this form does nothing and can be removed.

> (use-package casual-bookmarks
>   :ensure t :bind (:map bookmark-bmenu-mode-map
>               ("C-o" . casual-bookmarks-tmenu) ("S"
>               . casual-bookmarks-sortby-tmenu) ("J" . bookmark-jump))
>   :after (bookmark))

The `bookmark-jump` key binding is generally useful, and should
preferably be sent as a patch to Emacs itself.

Perhaps this also applies to the new key bindings for info, ibuffer, and
org-agenda, etc.  I don't know, and I didn't look into it.

> Casual Bookmarks requires Casual Lib which in turn requires a recent
> installation of Transient 0.6.0+ from either ELPA or MELPA. As an
> older version of Transient is built-in to the Emacs release,

This should say which version of Emacs needs to have transient upgraded.
If it is Emacs 29.4, then say that.

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

Re: Request to distribute Casual packages on NonGNU ELPA

[Adam Porter]

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

FWIW, IMHO, I think it would be much simpler for users if there were a 
single package which included all of the "Casual" libraries.  Then users 
can load the ones they want to use, and the others can remain unloaded. 
Having them split among 13 packages takes up a lot more space in the 
package list, and is much more to deal with when upgrading to new 
versions, etc.

Re: Request to distribute Casual packages on NonGNU ELPA

[Philip Kaludercic]

Adam Porter <adam@alphapapa.net> writes:

>> 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?
>
> FWIW, IMHO, I think it would be much simpler for users if there were a
> single package which included all of the "Casual" libraries.  Then
> users can load the ones they want to use, and the others can remain
> unloaded. Having them split among 13 packages takes up a lot more
> space in the package list, and is much more to deal with when
> upgrading to new versions, etc.

I agree FWIW.  It is not "blocking" (usually the only blocking issues
would be regarding non-free software), but something would be worth
considering.

-- 
	Philip Kaludercic on siskin

Re: Request to distribute Casual packages on NonGNU ELPA

[Stefan Kangas]

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.