unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "michael_heerdegen@web.de" <michael_heerdegen@web.de>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: RE: [External] : Re: [ELPA] New package: dired-duplicates
Date: Wed, 1 Nov 2023 16:28:40 +0000	[thread overview]
Message-ID: <SJ0PR10MB5488D18B8932D771C8DDC832F3A7A@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <83y1fh8ojy.fsf@gnu.org>

> > > If a ‘defcustom’ does not specify any ‘:group’, the last group
> > > defined with ‘defgroup’ in the same file will be used.  This way,
> > > most ‘defcustom’ do not need an explicit ‘:group’.
> >
> > All true.
> > But "not need" doesn't imply "shouldn't have".
> 
> We decided that it means "shouldn't have".

I wasn't aware that such a rigid decision had been made.

However, I don't see it in the Elisp manual.  Where is
it specified?

Instead, in the Elisp manual, node `Group Definitions':

  you specify the group’s members by using the
  ‘:group’ keyword when defining those members.

Sounds a bit like one explicitly specifies :group
for each member.  Nothing about specifying it only
for the first member of a set of consecutive member
definitions.  Ambiguous, at best, I guess, if it's
intended to say where and when you "should" specify
:group.

Perhaps you should change the text quoted by Michael,
to make clear that you don't really mean (what most
people understand by) "do not need", but instead you
really mean "shouldn't have"?

  If a ‘defcustom’ does not specify any ‘:group’, the last group
  defined with ‘defgroup’ in the same file will be used.  This way,
  most ‘defcustom’ do not need an explicit ‘:group’.
                   ^^^^^^^^^^^
                 shouldn't have

As for an explicit statement of the convention, I
find nothing at all about :group in the sections
of the manual (such as `Coding Conventions'), that
state the Elisp coding conventions.

Is this a doc bug?  Is there somewhere else where
what you say was decided is declared?

> > > If :group is specified, it will most of the time mean
> > > the defcustom should be assigned to some other, not
> > > to the default, group.  So it's better style to not
> > > explicitly specify the default.
> >
> > FWIW, I disagree, stylistically; I think it's worse
> > style.
> 
> You are entitled to your opinions, but it is futile to reiterate them
> here, since the project as a whole has decided on a certain policy,
> and we ask you to please respect that and stop fighting it here, lest
> someone is mistaken to think that it is a matter of personal
> preferences, when Emacs source code is discussed.

I made clear that I was talking about use of :group by
users in their code, not for code that's to be included
in Emacs.  Very clear.  No fighting, though you appear
to be trying.

But I now have the question about where your edict about
:group is proclaimed for code that's to be included in
Emacs.  Where is that, besides in your slap-down reply
to my msg?

  reply	other threads:[~2023-11-01 16:28 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-31 10:34 [ELPA] New package: dired-duplicates Harald Judt
2023-10-31 12:21 ` Philip Kaludercic
2023-10-31 21:05   ` Harald Judt
2023-11-01  2:14     ` Michael Heerdegen
2023-11-01 15:16       ` [External] : " Drew Adams
2023-11-01 15:45         ` Eli Zaretskii
2023-11-01 16:28           ` Drew Adams [this message]
2023-11-01 16:47             ` Eli Zaretskii
2023-11-01 16:33         ` Philip Kaludercic
2023-11-01 11:32     ` Philip Kaludercic
2023-11-01 20:04       ` Harald Judt
2023-11-01 21:29         ` Philip Kaludercic
2023-11-02  8:44           ` Harald Judt
2023-11-03  8:19             ` Philip Kaludercic
2023-11-03 20:19               ` Harald Judt
2023-11-04 15:27                 ` Philip Kaludercic
2023-11-06  9:33                   ` Harald Judt
2023-11-10  8:37                     ` Philip Kaludercic
2023-11-10 10:02                       ` Harald Judt
2023-11-23  6:12                         ` Philip Kaludercic
2023-10-31 21:24   ` Harald Judt
2023-11-01 17:40     ` Stefan Kangas
2023-11-01  3:30   ` Eli Zaretskii
2023-11-01 13:53     ` Visuwesh
2023-11-01 14:12       ` Eli Zaretskii
2023-11-01 17:57         ` Philip Kaludercic
2023-11-01 19:24           ` Eli Zaretskii
2023-11-01 20:09             ` Harald Judt
2023-11-02  5:55               ` Eli Zaretskii
2023-11-08 20:29                 ` Harald Judt
2023-11-09  5:52                   ` Eli Zaretskii
2023-11-09  8:00                     ` Harald Judt
2023-11-09  8:38                       ` tomas
2023-11-09  8:48                         ` Eli Zaretskii
2023-11-09  8:43                       ` Eli Zaretskii
2023-11-09  8:53                         ` tomas
2023-11-09  9:18                         ` Harald Judt
2023-11-09 14:52                           ` Harald Judt

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=SJ0PR10MB5488D18B8932D771C8DDC832F3A7A@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=michael_heerdegen@web.de \
    /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).