From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Feature Request: Per-package custom save files? Date: Tue, 24 Jun 2014 13:19:41 -0400 Message-ID: References: <21413.43005.992475.896234@lapdog.roam.corp.google.com> <21416.23354.391473.953888@retriever.mtv.corp.google.com> <21416.39268.648625.775759@retriever.mtv.corp.google.com> <87d2dyjr15.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1403630505 23749 80.91.229.3 (24 Jun 2014 17:21:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Jun 2014 17:21:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: raman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 24 19:21:38 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WzUPT-0000FM-B4 for ged-emacs-devel@m.gmane.org; Tue, 24 Jun 2014 19:21:31 +0200 Original-Received: from localhost ([::1]:33045 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzUPQ-0003Gz-Io for ged-emacs-devel@m.gmane.org; Tue, 24 Jun 2014 13:21:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzUNq-0000Ct-NU for emacs-devel@gnu.org; Tue, 24 Jun 2014 13:19:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzUNi-0002V5-Sq for emacs-devel@gnu.org; Tue, 24 Jun 2014 13:19:50 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:31509) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzUNi-0002Uu-Od for emacs-devel@gnu.org; Tue, 24 Jun 2014 13:19:42 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNLd+D9/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOegeEOASUYwWUMYFqg0wh X-IPAS-Result: ArUGAIDvNVNLd+D9/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOegeEOASUYwWUMYFqg0wh X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="69406805" Original-Received: from 75-119-224-253.dsl.teksavvy.com (HELO ceviche.home) ([75.119.224.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 24 Jun 2014 13:19:41 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 744126638E; Tue, 24 Jun 2014 13:19:41 -0400 (EDT) In-Reply-To: <87d2dyjr15.fsf@gmail.com> (raman@google.com's message of "Tue, 24 Jun 2014 07:55:34 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172684 Archived-At: > Once the custom settings are split out: > 1. Load on demand I don't see any need for it. The time to load a single customization file should be negligible unless it's *really* large or causes loading other files (e.g. if some of the customizations enable minor modes). And doing it "on-demand" might be very difficult. E.g. you can't delay "activate global-reveal-mode" to when reveal.el is loaded, since it's the activation of global-reveal-mode which would cause loading reveal.el. And it's this loading which takes the time, so delaying the other reveal-related settings would be pointless since these take a ridiculously small amount of time. If we want to speed up startup, there are several things we can do, but I don't think any of them would be helped by splitting the customization file. > 2. Smaller, more manageable custom files. We can cut the file in chunks, but that doesn't mean it's necessarily more manageable. > The reason this bubbled up for me is that in the past few months I've > had to go back in time to retrieve a custom file from my local git repo > because the giant custom file got corrupted during an emacs custom-save > at some point -- I've not chased down the culprit -- but when that > happens, you're left with a giant file that is impossible to fix by > hand. Can you give details of the difficulties you encountered? Would they have been different if the customizations were split among several files, each of them similarly corrupted? Or would it only be different under the assumption that the corruption would have affected a single file, thus reducing the amount of corruption? The customization file should contain 2 parts: the face settings and the var settings. Each part should be sorted alphabetically which (due to the prefix-convention we use for names) should largely group settings "by package". So splitting the "one big file" into several smaller files would not really change any ordering. > I now regularly git commit my .custom file to a local repo just > for this reason I do that as well, tho not for this reason. Stefan