Re: Request to distribute Casual packages on NonGNU ELPA

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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