What is this `customize-group` about?

Often when asking questions somebody recommends me to use `customize-group`. But what is this? I know about that in a default emacs the `init.el` is trashed up automaticly by some custom-variables from emacs itself. To keep my own `init.el` clean from this I use this snipped ```lisp ;; === Custom file from Emacs automatic configuration (setq custom-file (expand-file-name "custom.el" user-emacs-directory)) (when (file-exists-p custom-file) (load custom-file)) ```

Emacs has informative, built-in documentation which can answer your question. `describe-function` (bound to `C-h f` by default) followed by the name of the function (customize-group) will display the function's documentation.

Why does everyone thinks that someone who ask don't know how to use `C-h`!? Of course I did that. But the "help" text their is not informative. What is a `GROUP`? I am not aware of that concept in the context of Emacs.

Because you haven't given anyone that information in your question. You can also check the built-in manual which will explain what a group is.

A customization group is just a set of related options, usually provided by a library or package. So e.g. if you M-x customize-group RET python, you will get a list of all options that relate to python-mode.

Have you considered [reading the fine manual](https://www.gnu.org/software/emacs/manual/html_node/elisp/Group-Definitions.html)? I think it says quite clearly what a group is. Simplified, it is just a set of options grouped together and displayed in a same page when browsing customized.

The concept is still not clear for me. Could it be described as a way to publish all possible options of a package to a user? It is like looking into the Settings-dialog of an application, right? Or is there another reason why a "group" should "contain options"? The concept behind it, the big picture, is still missing from the view point of Emacs newbies and none Lisp programmers.

The clumsy apparatus of `defcustom` (what with the *menage a trois* of `custom-set-variables`, `customize-set-variable` and `customize-set-value`) emerged from elisp's predating object oriented notions of data hiding and the johnny-come-lately bolt-ons of CLOS and EIEIO. Say the end user wants to dial up a customizable setting like litigiousness. Then the module logic needs to increase an internal count of lawyers. This is trivial in a language like C++ where `nlawyers` and `litigiousness` are private data, and `increase_litigiousness` is a public method. In old-school elisp however, the user, who, unlike partisans of the `defcustom` apparatus, often has a day job and just wants emacs to get out of the way, will rely on the old standby `setq litgiousness 10`. This of course leaves `nlawyers` high and dry. So we have `defcustom` and friends. I'd say less than 10% of emacs users worldwide know about it.

Oh, and I forgot the most tragic aspect. A `defcustom` can still be `setq`, which most unwitting users do, so essentially the `defcustom` machinery is a Trumpian border wall.

> Or is there another reason why a "group" should "contain options"? What is a reason why bread contains flour, water and salt? Or is there a reason why a program contains functions? What should a "group" contain, then? Or how would you call a set of related options? If you have a set of related options, that a presented to a user on a same screen, how would you call it? I think it is quite reasonable to say that "options are grouped together" and "group" is a quite normal word to use in this context. You can maybe use the word "node" or "page" or "dialogue" or whichever, but I don't see what makes any of those preferable over each other. The author(s) chose to use "group" and so group it is. Or "customization group" as it is more often seen.

OP wasn't asking for your thoughts on `defcustom`'s *raison d'etre*.

We come to the point. "group" is not the same way clear to me as "flour, water and salt". Why do I need a group? If I want to know which options does a package offer I look into the documentation, or do `C-h something` or look into the code itself. And If I want to modify an option I do something like `(setq something)`. It is still not clear for me why I need this sub-layer/concept of a "group" in that case.

Probably because customization and groups are very well described in the documentation and we can't work out what you're missing. The "Customization Groups" section of the manual says: > Customization settings are organized into “customization groups”. These groups are collected into bigger groups, all the way up to a master group called ‘Emacs’. That seems to cover it to me. It seems like perhaps you read this and think there is more to it, but this is really it. A customization group is a grouping of customization settings. That's all. If you want to, say, customize `dired`, you would `M-x customize-group RET dired RET`, and see the grouping of options for `dired`, because the `dired` maintainers have put their customizations into a `dired` group. If someone makes a large package, they may want to organize settings into other groupings, so when you ask elsewhere whether it's groups of settings for a package - well, often, yes, but not necessarily if it makes sense. Quite a few packages put their faces into another group, just because that's convenient organization. I feel like you're over-thinking this and can't get your head around the fact it's a very simple concept, and you're assuming there's much more to it.

> I feel like you're over-thinking this and can't get your head around the fact it's a very simple concept, and you're assuming there's much more to it. I assume you are right. It is often my problem to think to complicated while thinking that I am thinking the easy way. :D Thanks for your patience with me.

Well not everyone is (setq something) nor is looking into the source code. You might not prefer it, but some people prefer interactive graphical option which customize offers. For those people, customization groups exists to group together similar options for displaying on a screen, and for making it easier to navigate and lookup what they need.

> It is like looking into the Settings-dialog of an application, right? Yes. A `defgroup` group is a collection of options and faces that have something in common. Typically what they have in common is that they belong to a particular package. Or perhaps even a particular area/subject of a particular package. Example: Package [Icicles](https://www.emacswiki.org/emacs/Icicles) has these groups, to organize access to its `defcustom` settings (options and faces): * **Icicles** - Minibuffer input completion and cycling of completion candidates. (Overall group - gives you a list of the subgroups.) * **Icicles-Buffers** - Icicles preferences related to buffers. * **Icicles-Files** - Icicles preferences related to files. * **Icicles-Completions-Display** - Icicles preferences related to display of completion candidates. * **Icicles-Key-Bindings** - Icicles preferences related to key bindings. * **Icicles-Key-Completion** - Icicles preferences related to key completion (`icicle-complete-keys`). * **Icicles-Matching** - Icicles preferences related to matching input for completion. * **Icicles-Minibuffer-Display** - Icicles preferences related to minibuffer display during completion. * **Icicles-Miscellaneous** - Miscellaneous Icicles preferences. * **Icicles-Searching** - Icicles preferences related to searching. Why such groups? So you can focus on a particular area. If you use `M-x customize-group Icicles` you get a buffer with the list of subgroups (links).

It's not at all clear that your respondents are right. And your patience in the face of their well-nigh RTFM answers is admirable. I am frequently accused of overthinking things. My reply is usually that not only am I not overthinking, everyone else is under-thinking. That's what is (well, was -- this is, after all, a 200+ old days thread) happening here. The help in customization is *not* clear. In fact, the more I look, the more I conclude that is the case with much of the English. Erosion of emacs documentation. In many cases, while the authors were probably smart people, they were not native speakers and their phrasing is not only stilted, it is frequently ambiguous if not downright inaccurate. Unfortunately I cannot help you with your precise question. I just wanted to drop a note of support and to encourage you to keep on asking questions! (All that said, I have to acknowledge that several of your respondents clearly took time to consider your question, and to answer you. So even though I don't agree with their replies, I have to give them credit for making the effort.)