unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Charles Choi <kickingvegas@gmail.com>
To: emacs-devel <emacs-devel@gnu.org>
Cc: Stefan Kangas <stefankangas@gmail.com>,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	Philip Kaludercic <philipk@posteo.net>
Subject: Re: Request to distribute Casual packages on NonGNU ELPA
Date: Fri, 27 Sep 2024 11:12:01 -0700	[thread overview]
Message-ID: <FC85517C-514B-40BF-BA1C-ACDD14A64233@gmail.com> (raw)
In-Reply-To: <877caxqejq.fsf@posteo.net>

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





  parent reply	other threads:[~2024-09-27 18:12 UTC|newest]

Thread overview: 28+ 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  3:08         ` Richard Stallman
2024-09-28  8:52           ` Charles Choi
2024-09-27 15:52       ` Philip Kaludercic
2024-09-27 16:04         ` Philip Kaludercic
2024-09-27 18:12         ` Charles Choi [this message]
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-09-25 23:44 ` Stefan Kangas
2024-09-26 17:01   ` Charles Choi
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=FC85517C-514B-40BF-BA1C-ACDD14A64233@gmail.com \
    --to=kickingvegas@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --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).