From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Lennart Borgman" Newsgroups: gmane.emacs.devel Subject: Re: Documentation for custom-file - is not (load custom-file) needed? Date: Wed, 8 Dec 2004 01:44:21 +0100 Message-ID: <03be01c4dcbf$139bfa30$0200a8c0@sedrcw11488> References: <075b01c4d9a4$52799460$0200a8c0@sedrcw11488> <00bb01c4daee$5eb81350$0200a8c0@sedrcw11488> <200412051733.iB5HXIX13206@raven.dms.auburn.edu> <000001c4db1a$8d3770f0$0200a8c0@sedrcw11488> <200412060046.iB60kZj15003@raven.dms.auburn.edu> <003e01c4db31$e45a2550$0200a8c0@sedrcw11488> <200412060402.iB6421q15173@raven.dms.auburn.edu> <200412070539.iB75dV924747@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1102466777 9746 80.91.229.6 (8 Dec 2004 00:46:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 8 Dec 2004 00:46:17 +0000 (UTC) Cc: John Paul Wallington , Emacs Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 08 01:46:09 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Cbpy5-0003qM-00 for ; Wed, 08 Dec 2004 01:46:09 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cbq7u-0004vl-G8 for ged-emacs-devel@m.gmane.org; Tue, 07 Dec 2004 19:56:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cbq7h-0004tn-7C for emacs-devel@gnu.org; Tue, 07 Dec 2004 19:56:05 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Cbq7g-0004sm-6Z for emacs-devel@gnu.org; Tue, 07 Dec 2004 19:56:04 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cbq7g-0004sd-2O for emacs-devel@gnu.org; Tue, 07 Dec 2004 19:56:04 -0500 Original-Received: from [81.228.10.108] (helo=av9-1-sn4.m-sp.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cbpwp-0002Kl-G6; Tue, 07 Dec 2004 19:44:52 -0500 Original-Received: by av9-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 7CF3237F2B; Wed, 8 Dec 2004 01:44:49 +0100 (CET) Original-Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av9-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 6321037E44; Wed, 8 Dec 2004 01:44:49 +0100 (CET) Original-Received: from sedrcw11488 (t3o58p181.telia.com [195.252.56.181]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with SMTP id BE09F37E42; Wed, 8 Dec 2004 01:44:47 +0100 (CET) Original-To: "Luc Teirlinck" , X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:30820 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:30820 ----- Original Message ----- From: "Luc Teirlinck" > The situation would be a much bigger mess than I thought when I wrote > the quote you are responding too. The user _did_ customize > `custom-file' through Custom. But we actually just wrote a setq form > into .emacs. Should we now _consider_ `custom-file' to be customized > through Custom? Since the user customized it through Custom, he > probably would believe that things that normally work when setting > things through Custom work for custom-file too. But then you have to > set various properties like custom-saved and others. (That would be > done by these named functions I referred to, which could be newly > written named functions. If Custom started adding new properties to > the symbol-plist, which has happened in the past and may happen in the > future, these functions would need to be updated.) But the situation > is worse than that. If you do not set these properties, you get into > various anomalies, like the "State" message in a Custom buffer saying > that `custom-file' was changed outside Custom, which could confuse the > user. If you do set them, you get other anomalies, because then > Custom believes that `custom-file' is defined in the custom file, > whereas it is not. It is a mess and there is no need whatsoever to > get into that mess. Hi Luc, I cannot follow all your arguments here, but I see you have an important point about anomalies. Maybe some of the arguments you have could be removed if the normal functions used in defcustom were still called AND some other needed actions where taken for custom-file? (Am I clear enough here?) Due to your argument about anomalies I have tried to rethink my view. The code I have written and sent to the list before could perhaps be used, but some more things must be done. I will try to summarize how I see this to get it a bit further: a) custom-file is a special variable and can not be treated only as a normal "defcustom variable". b) It is currently treated as a normal "defcustom variable". This should be changed. There are various ways to cure this: 1) Just do not make custom-file a "defcustom variable". This is the easiest and does not fool the user. But it is perhaps not very nice. 2) Keep custom-file a "defcustom variable" and cure the problems. Way 2 is more job, but maybe not very much. It depends a bit on how far we want to go on this way. Writing automatically into .emacs is a bit more job (I have done part of that but it must be tested since it is critical). However an alternative is telling the user this must be done and how it should/could look. What I believe have to be done if way 2 is choosen is A) Write a new version of custom-buffer-create for just custom-file, say custom-buffer-custom-file-create. This does not seem to hard to do. (A bit more minor issue here is whether custom-file should be saved to custom-set-variables and as I said I do not think it should.) B) Catch custom-file at various places so it will be customized just through the new function custom-buffer-file-create. Maybe it should be a new type of its own instead of custom-variable, but I do not understand the details there now. This point seems more difficult to me. Regards, Lennart