Re: A proposal for a friendlier Emacs

[Alexander Adolf]

Eli Zaretskii <eliz@gnu.org> writes:

> [...] 
>> Let the package author choose and, and only one category, and any number
>> of tags he/she wants to use to describe the package.
>
> That might be possible for some specialized packages, but not forf all
> of them.



>> When a user installs a package from a package archive, the category
>> chosen by the author is presented as the default choice, and can be
>> overridden by the user.
>
> If the category is not fixed, I'm not sure I see the utility of having
> such categories at all in the custom file.

My idea about the category was to use it for grouping things into
"topical files" inside emacs.d. Consider the following, fictional,
example:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ~/.emacs.d/init.el                                    
───────────────────────────────────────────────────────
 ;;;; %%%%% magic-comment (emacs-core) %%%%%           
 (custom-set-* …) ;; inserted and maintained by Custom 
 ;;;; %%%%%                                            
 (…) ;; manual init code for emacs-core                
                                                       
 (require 'setup-email)                                
 (require 'setup-progn)                                
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ~/.emacs.d/setup-email.el                                   
───────────────────────────────────────────────────────
 ;;;; %%%%% magic-comment (my-awesome-package) %%%%%   
 (custom-set-* …) ;; inserted and maintained by Custom 
 ;;;; %%%%%                                            
 (…) ;; manual init code for my-awesome-package        
                                                       
 ;;;; %%%%% magic-comment (even-greater-package) %%%%% 
 (custom-set-* …) ;; inserted and maintained by Custom 
 ;;;; %%%%%                                            
 (…) ;; manual init code for even-greater-package      
                                                       
 (provide 'setup-email)                                
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ~/.emacs.d/setup-progn.el                                     
─────────────────────────────────────────────────────────
 ;;;; %%%%% magic-comment (super-duper-package) %%%%%    
 (custom-set-* …) ;; inserted and maintained by Custom   
 ;;;; %%%%%                                              
 (…) ;; manual init code for super-duper-package         
                                                         
 ;;;; %%%%% magic-comment (totally-useful-package) %%%%% 
 (custom-set-* …) ;; inserted and maintained by Custom   
 ;;;; %%%%%                                              
 (…) ;; manual init code for totally-useful-package      
                                                         
 (provide 'setup-progn)                                  
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

In this case, the user has installed four packages. Two of them were
categorised as "email", and two of them as "progn". When the first
package from a new category gets installed, a new setup-category.el file
would be generated in emacs.d. Whatever the user tweaks in Custom, gets
inserted in the (custom-set-* …) block for the package, and in the
respective setup-category.el file.

When a new user starts using Emacs (i.e. neither ~/.emacs.d nor ~/.emacs
exist), and changes settings in Custom, a ~/.emacs.d/init.el would be
created, with the magic comment/(custom-set-* …) block.

When a new package gets installed, the user would be prompted "Install
super-duper-package as category [progn]?", with the category chosen by
the package author (and stored in the package repository) as the
default. An option to never ask and always use the package's category
would also seem to make sense, and there might even be a point in
setting it to true by default (to not overwhelm new users with questions
they might have a hard time to understand). Later on, as the user
becomes more experienced, he/she may set that variable to false, and
move configuration blocks between init files as he/she deems fit.

Disadvantages:

• manual and automatic edits in the same file, which may lead to
  breakage

Advantages:

• new users are guided towards a topical config structure, and without
  any work on their part get a skeleton config to build upon

• all settings for any given package are collected in one place, instead
  of being spread out between the custom file and manually created files


Many thanks and looking forward to your thoughts,

  --alexander