bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22727: Managing packages writes the user init file


From: Eli Zaretskii
Subject: bug#22727: Managing packages writes the user init file
Date: Thu, 18 Feb 2016 18:48:41 +0200

> From: Angelo Graziosi <address@hidden>
> Date: Thu, 18 Feb 2016 01:49:36 +0100
> 
> I have noticed that just using
> 
>   Options - Manage Emacs Packages
> 
> writes my init file. For example I find these additions in my case:
> 
> (custom-set-variables
>  ;; custom-set-variables was added by Custom.
>  ;; If you edit it by hand, you could mess it up, so be careful.
>  ;; Your init file should contain only one such instance.
>  ;; If there is more than one, they won't work right.
>  '(package-selected-packages (quote (tabbar-ruler sr-speedbar))))
> (custom-set-faces
>  ;; custom-set-faces was added by Custom.
>  ;; If you edit it by hand, you could mess it up, so be careful.
>  ;; Your init file should contain only one such instance.
>  ;; If there is more than one, they won't work right.
>  )
> 
> I discovered this only casually..
> 
> I think this is not the right thing to do. Why an application should write a 
> file which belongs to the user? 

This is how Custom behaves since ages ago: when you save
customizations, it writes such forms into your ~/.emacs.  The use case
with package managing is therefore not special in any way; rather, you
are proposing to divert the customizations made by Custom to a
separate file.  We already have an option to do that, named
'custom-file'; see the node "Saving Customizations" in the Emacs User
Manual.  Is that option sufficient to solve your problem in this bug
report?  If not, can you tell why not?

It is possible that your objection is somehow limited to what
package.el does, but, as written, it describes a much more broad class
of functionalities, and is not specific to package.el.

For the record, the reason why customizations are by default saved in
~/.emacs is that originally the idea was to teach users how to use
Lisp for customizing Emacs, so that users could progressively migrate
from using Custom to writing their own Lisp, as they gain proficiency.
I don't think we've abandoned this idea, even though I'm not sure it
is working as planned.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]