From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Settings Date: Thu, 15 Aug 2019 16:11:34 -0700 (PDT) Message-ID: <394f3e11-20cf-4fc8-9222-751ea250cb99@default> References: <87y2zuumeg.fsf@mouse.gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="161767"; mail-complaints-to="usenet@blaine.gmane.org" To: Lars Ingebrigtsen , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 16 01:11:52 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hyOuN-000g0C-Ko for ged-emacs-devel@m.gmane.org; Fri, 16 Aug 2019 01:11:51 +0200 Original-Received: from localhost ([::1]:47806 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hyOuL-00068t-II for ged-emacs-devel@m.gmane.org; Thu, 15 Aug 2019 19:11:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42364) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hyOuF-00068m-Im for emacs-devel@gnu.org; Thu, 15 Aug 2019 19:11:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hyOuD-0003Ys-Iv for emacs-devel@gnu.org; Thu, 15 Aug 2019 19:11:42 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:46144) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hyOuD-0003OS-9o for emacs-devel@gnu.org; Thu, 15 Aug 2019 19:11:41 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x7FN98ad130820; Thu, 15 Aug 2019 23:11:39 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=61zL8ee9FB1nyipLS0oJvyUQZTuIEjXpA0Nt41u/VKM=; b=BoBRTMSBLcZrGgJe1ZKd1hE6myM0JzSNJvoA+NwSgI+Wi7iB6QzZ1zEKfnIXI0iKoP0L 65HM8oIJ00SRHl16tVJrWbpK+Zt1HDW09WIJho+zKky2MGdp0bpRRyApElK4tqc+SXR7 b74ny4QK7YJqgcyzDGGj7UjHBHTEd/2CkjL1cfPYmnXc8ZgcWdfNyuuORGaHbvaA1T/o VunZutec/mvSu1U6BWn45dqIyZ3422HdtXbC7BDBJ74EJ6TFOH19Vm+qLqitmWEcQ8dp fjf1PhhAEYpXHbWHloz/h6xEb+8juEowNRc/0K8thoeTsIeP//VUU005QWSVdnxeiB2V xQ== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 2u9nbtwj7p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 15 Aug 2019 23:11:39 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x7FN8MoV023657; Thu, 15 Aug 2019 23:11:39 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 2udgr286hb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 15 Aug 2019 23:11:38 +0000 Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x7FNBauI029955; Thu, 15 Aug 2019 23:11:36 GMT In-Reply-To: <87y2zuumeg.fsf@mouse.gnus.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4873.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9350 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908150221 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9350 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908150221 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 156.151.31.86 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.org gmane.emacs.devel:239389 Archived-At: > Reading some bug reports about problems with saving Customize settings... For example? What kinds of problems saving Customize settings? But you go on to talk about non-Customize settings. What kinds of problems can you report about saving those? Just what's the problem you're trying to solve? > Emacs should have one way to save settings. Why only one? What's the problem? > Currently, there way settings are saved are in three classes: > 1) Older stuff: > (put 'narrow-to-region 'disabled nil) saved to ~/.emacs (or whatever > the init file is called). Are you referring to the use of symbol property lists? Or just to the fact that such info is being saved in the init file? Or are you referring only to the use of property `disabled' to control command disabling? (Property lists are about as old as Lisp, but there's nothing outmoded or "older" about them.) > 2) Post-Customize stuff saved to ~/.emacs: >=20 > (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. > '(load-home-init-file t t) > ...) Similarly, is this about Customize settings or the fact of saving them in the init file? =20 > 3) Ad-hoc methods for saving key/values in different files > (~/url/cookies, ~/.emacs.d/network-security.data) >=20 > I think Emacs can do better. "Ad hoc" and "better' makes it sound like there is no reason for saving different things in different files. The devil's in the details, for all such considerations. It can make sense for a given function to save some info in a specific file (e.g. chosen by the user). Depends on the info and its use. And it can make sense for some info to be handled by Customize, as options and faces, and so saved in the single file that's handled by Customize. > As a first principle, I think Emacs should not mess, at all, with the > ~/.emacs file. That's for users to put their lovingly hand-crafted > setqs in. On that, I agree 100%. I've long advocated that users use `custom-file' and not let Customize fiddle with their init file. > Second of all, Emacs should allow listing, with one command, all > settings that Emacs has saved on your behalf, and that allows you to > remove anything you don't want to have saved. Define "Emacs", here. If library synonyms.el has user options for a cache file and a thesaurus file, then that library - not "Emacs" - should be responsible for the functions that update/save such info. Why would "Emacs" have any need to know about or include such files in any listing, which arguably "Emacs" (by way of that library) saved on the user's behalf? Likewise, a bookmark library is responsible for a user's bookmarks file(s). That's how it should be. A user can easily transport just her bookmarks, or whatever. Why would we want to save everything that a user might want to persist in the same giant file/database? Customize already lets a user "list" options and their values, and it does so on a library basis. Customize also allows ad hoc (yes) tags, called "groups" for categorizing its options and faces. And you can "list" the entries for any group. > And finally, Emacs should save some metadata about the setting, like > when it was done and from what Emacs version it was done. Again, this should be up to (the user and) the facility that's managing the persistent thingy: Customize or a library. And only if it (its author) thinks that's helpful/appropriate for that thingy. > There's a file ~/.emacs.d/settings, and whenever we want to register a > command as not disabled, or save a Customize setting, or store an NSM > exception, we just append a form to that file... > and when Emacs starts up, then it reads the file and the final value > wins. (We'd have a compacting function to get rid of redundant > entries.) No one-size-fits-all solution looking for a problem to solve, please. The following should be decided based on the particular thingy and its purpose: * Whether and when and where to save it * Whether and when and where to restore it And who better knows those conditions than the relevant library (together with the user)? Even when to load `custom-file' is problematic. Ultimately only the user knows what's right for that. > if you start, say, Emacs 28, and it converts > your old-timey settings into new-style settings, I'll try to be sure to make sure that never happens. ;-) Doesn't sound great so far, to me. Sounds like a one-size-fits-all solution in search of a copasetic problem. But if you report about specific problems you're looking to solve then perhaps things will be clearer. Before inventing a high-level solution, can we please see some specific problems that you think call for such a solution?