unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Default custom group
@ 2005-05-14 15:12 Richard Stallman
  2005-05-16  5:56 ` Katsumi Yamaoka
  0 siblings, 1 reply; 9+ messages in thread
From: Richard Stallman @ 2005-05-14 15:12 UTC (permalink / raw)


While cleaning up etc/NEWS I was reminded that the feature
if the default group in defcustom is new in this release.
I have never been happy with this default, and the best time
to change things is now, before we make a release with it.

So I just made the byte compiler warn whenever a custom definition
fails to specify a group.

At some time in the future we should make them get errors at
run time if they don't specify a group, but not right away.

This default feature was not documented in the Lisp Manual,
so I had no change to make there.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Default custom group
  2005-05-14 15:12 Default custom group Richard Stallman
@ 2005-05-16  5:56 ` Katsumi Yamaoka
  2005-05-17 21:23   ` Daniel Brockman
  2005-05-18  5:20   ` Richard Stallman
  0 siblings, 2 replies; 9+ messages in thread
From: Katsumi Yamaoka @ 2005-05-16  5:56 UTC (permalink / raw)
  Cc: emacs-devel

>>>>> In <E1DWyJi-0003yb-Td@fencepost.gnu.org> Richard Stallman wrote:

> While cleaning up etc/NEWS I was reminded that the feature
> if the default group in defcustom is new in this release.
> I have never been happy with this default, and the best time
> to change things is now, before we make a release with it.

> So I just made the byte compiler warn whenever a custom definition
> fails to specify a group.

> At some time in the future we should make them get errors at
> run time if they don't specify a group, but not right away.

> This default feature was not documented in the Lisp Manual,
> so I had no change to make there.

I got many warnings when compiling Gnus.  For instance:

smime.el:123:1:Warning: defgroup for `smime' fails to specify containing group

I think there might be customization groups which don't belong
to any parent groups except `emacs'.  Although it is possible to
avoid warnings by adding the ``:group 'emacs'' parameters, I
don't think it is useful especially for `defgroup'.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Default custom group
  2005-05-16  5:56 ` Katsumi Yamaoka
@ 2005-05-17 21:23   ` Daniel Brockman
  2005-05-18 22:45     ` Richard Stallman
  2005-05-18  5:20   ` Richard Stallman
  1 sibling, 1 reply; 9+ messages in thread
From: Daniel Brockman @ 2005-05-17 21:23 UTC (permalink / raw)


Katsumi Yamaoka <yamaoka@jpl.org> writes:

> I think there might be customization groups which don't belong to
> any parent groups except `emacs'.  Although it is possible to avoid
> warnings by adding the ``:group 'emacs'' parameters, I don't think
> it is useful especially for `defgroup'.

I expect to be able to get to any customization group by starting from
M-x customize RET and following the links.  Groups that indeed don't
belong to any parent groups except `emacs' SHOULD have :group 'emacs.
I don't see what the problem is.

-- 
Daniel Brockman <daniel@brockman.se>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Default custom group
  2005-05-16  5:56 ` Katsumi Yamaoka
  2005-05-17 21:23   ` Daniel Brockman
@ 2005-05-18  5:20   ` Richard Stallman
  2005-05-18  6:18     ` Katsumi Yamaoka
  1 sibling, 1 reply; 9+ messages in thread
From: Richard Stallman @ 2005-05-18  5:20 UTC (permalink / raw)
  Cc: emacs-devel

    I got many warnings when compiling Gnus.  For instance:

    smime.el:123:1:Warning: defgroup for `smime' fails to specify containing group

I think that is a real bug.  This group should surely be put in
a logical place in the hierarchy.

    I think there might be customization groups which don't belong
    to any parent groups except `emacs'.

There should not be any such groups, except the first-level groups
defined in cus-edit.el specifically for that purpose.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Default custom group
  2005-05-18  5:20   ` Richard Stallman
@ 2005-05-18  6:18     ` Katsumi Yamaoka
  2005-05-18 22:44       ` Richard Stallman
  2005-05-18 22:44       ` Richard Stallman
  0 siblings, 2 replies; 9+ messages in thread
From: Katsumi Yamaoka @ 2005-05-18  6:18 UTC (permalink / raw)
  Cc: emacs-devel

>>>>> In <E1DYGz1-0003eZ-AL@fencepost.gnu.org> Richard Stallman wrote:

>     I got many warnings when compiling Gnus.  For instance:

>     smime.el:123:1:Warning: defgroup for `smime' fails to specify containing group

> I think that is a real bug.  This group should surely be put in
> a logical place in the hierarchy.

I'm sorry for insufficient information.  It was caused by the
following form which didn't specify the parent group.

(defgroup smime nil
  "S/MIME configuration.")

>     I think there might be customization groups which don't belong
>     to any parent groups except `emacs'.

> There should not be any such groups, except the first-level groups
> defined in cus-edit.el specifically for that purpose.

Yesterday, I changed my mind and added the ``:group 'something''
argument to every defgroup, defface and defcustom forms in which
it hasn't been specified in Gnus (the changes will be propagated
into the Emacs trunk after a while).  At that time, I felt like
to add some first-level groups (e.g., cryptograph, security, etc.)
is necessary.  However, I'm not positive to propose adding of
them since Gnus v5.11 supports not only Emacs CVS but also Emacs
20 and 21.

By the way, I noticed the new bytecomp doesn't warn to the
defcustom form in which the parent group is not specified.  For
example:

(let ((file (expand-file-name
	     (concat (make-temp-name "testing") ".el")
	     temporary-file-directory)))
  (with-temp-file file
    (insert "\
\(defgroup foo nil \"doc\")
\(defcustom bar nil \"doc\")
"))
  (byte-compile-file file)
  (delete-file file)
  (delete-file (concat file "c")))

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Default custom group
  2005-05-18  6:18     ` Katsumi Yamaoka
@ 2005-05-18 22:44       ` Richard Stallman
  2005-05-18 23:00         ` Katsumi Yamaoka
  2005-05-18 22:44       ` Richard Stallman
  1 sibling, 1 reply; 9+ messages in thread
From: Richard Stallman @ 2005-05-18 22:44 UTC (permalink / raw)
  Cc: emacs-devel

    I'm sorry for insufficient information.  It was caused by the
    following form which didn't specify the parent group.

    (defgroup smime nil
      "S/MIME configuration.")

That ought to be fixed, and likewise any other defgroups that fail
to specify a parent.

    Yesterday, I changed my mind and added the ``:group 'something''
    argument to every defgroup, defface and defcustom forms in which
    it hasn't been specified in Gnus (the changes will be propagated
    into the Emacs trunk after a while).

Thank you.  (What is the upper bound on "a while"?)

      At that time, I felt like
    to add some first-level groups (e.g., cryptograph, security, etc.)
    is necessary.

Maybe you are right.  It would not be hard to add first-level groups
now; it won't break anything.  However, I want to consider the question
carefully.  For instance, it doesn't make sense to add both cryptography
and security as first-level groups; the latter includes the former.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Default custom group
  2005-05-18  6:18     ` Katsumi Yamaoka
  2005-05-18 22:44       ` Richard Stallman
@ 2005-05-18 22:44       ` Richard Stallman
  1 sibling, 0 replies; 9+ messages in thread
From: Richard Stallman @ 2005-05-18 22:44 UTC (permalink / raw)
  Cc: emacs-devel

    By the way, I noticed the new bytecomp doesn't warn to the
    defcustom form in which the parent group is not specified.

Strange, I thought I had tested it on that case.
I fixed it now.  Thanks.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Default custom group
  2005-05-17 21:23   ` Daniel Brockman
@ 2005-05-18 22:45     ` Richard Stallman
  0 siblings, 0 replies; 9+ messages in thread
From: Richard Stallman @ 2005-05-18 22:45 UTC (permalink / raw)
  Cc: emacs-devel

    I expect to be able to get to any customization group by starting from
    M-x customize RET and following the links.  Groups that indeed don't
    belong to any parent groups except `emacs' SHOULD have :group 'emacs.
    I don't see what the problem is.

It is not right for these to be first-level groups.
They belong at other places in the tree.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Default custom group
  2005-05-18 22:44       ` Richard Stallman
@ 2005-05-18 23:00         ` Katsumi Yamaoka
  0 siblings, 0 replies; 9+ messages in thread
From: Katsumi Yamaoka @ 2005-05-18 23:00 UTC (permalink / raw)
  Cc: emacs-devel

>>>>> In <E1DYXHL-00062d-CL@fencepost.gnu.org> Richard Stallman wrote:

>     Yesterday, I changed my mind and added the ``:group 'something''
>     argument to every defgroup, defface and defcustom forms in which
>     it hasn't been specified in Gnus (the changes will be propagated
>     into the Emacs trunk after a while).

> Thank you.  (What is the upper bound on "a while"?)

Usually it will be done by Miles Bader within a couple of days.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2005-05-18 23:00 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-05-14 15:12 Default custom group Richard Stallman
2005-05-16  5:56 ` Katsumi Yamaoka
2005-05-17 21:23   ` Daniel Brockman
2005-05-18 22:45     ` Richard Stallman
2005-05-18  5:20   ` Richard Stallman
2005-05-18  6:18     ` Katsumi Yamaoka
2005-05-18 22:44       ` Richard Stallman
2005-05-18 23:00         ` Katsumi Yamaoka
2005-05-18 22:44       ` Richard Stallman

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