unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>,
	Stefan Kangas <stefan@marxist.se>
Cc: "53153@debbugs.gnu.org" <53153@debbugs.gnu.org>
Subject: bug#53153: [External] : bug#53153: package-quickstart: unusual autoload form in selectrum gives byte-compilation warning
Date: Thu, 13 Jan 2022 16:20:00 +0000	[thread overview]
Message-ID: <SJ0PR10MB54886108F879B76893B0593BF3539@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <jwvilunvgq9.fsf-monnier+emacs@gnu.org>

> Global minor modes define a `defcustom` and its
> :group is usually provided by default by the last 
> `defgroup` but if you copy this `define-minor-mode`
> to some other file (such as an autoloads file),
> then you can't rely on this defaulting so you
> should provide a `:group` explicitly.

FWIW -

IMO, it's misguided to recommend that people not
use :group explicitly when they can get away
with depending on the preceding :group being for
the same group.

That's a sort of "premature visual optimization"
that provides no real advantage and presents the
disadvantages of (1) being less clear (at the
limit, it requires readers of the code to search
backward) and (2) gotchas such as the one you
described.

People no doubt have different feelings about
such things, which is fine - it's partly an
individual style choice.  I disagree with
recommending one or the other as a general
guideline.

But if one of them is to be used as a guideline
it should be to specify :group explicitly, even
when it might not be strictly necessary.  Clear
for all.

And what's the purported advantage of omitting
:group when it's not needed?  Presumably it's
 (1) less clutter/noise and perhaps (2) easier
to notice when the "current" :group changes.

#1 is very minor, at best.  :group labels are
not verbose.

#2 can be misleading.  If a reader of the code
tries to depend on each :group being significant
(i.e., it can't be omitted), that assumption
will bite, sooner or later.

(Just one opinion.)





      parent reply	other threads:[~2022-01-13 16:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-10  4:46 bug#53153: package-quickstart: unusual autoload form in selectrum gives byte-compilation warning Stefan Kangas
2022-01-13  9:11 ` Lars Ingebrigtsen
2022-01-13 11:20   ` Stefan Kangas
2022-01-13 14:46 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-13 15:30   ` Stefan Kangas
2022-01-13 16:20   ` Drew Adams [this message]

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=SJ0PR10MB54886108F879B76893B0593BF3539@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=53153@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=stefan@marxist.se \
    /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).