From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: find-file-hook as illustration of Custom problems Date: Sat, 5 Feb 2005 12:54:16 -0600 (CST) Message-ID: <200502051854.j15IsGZ07501@raven.dms.auburn.edu> References: <200502040036.j140atb03430@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1107630021 18863 80.91.229.2 (5 Feb 2005 19:00:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 5 Feb 2005 19:00:21 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 05 20:00:20 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CxVA5-0008MM-QS for ged-emacs-devel@m.gmane.org; Sat, 05 Feb 2005 20:00:06 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CxVNr-0006Wv-TN for ged-emacs-devel@m.gmane.org; Sat, 05 Feb 2005 14:14:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CxVMz-0006GK-MG for emacs-devel@gnu.org; Sat, 05 Feb 2005 14:13:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CxVMx-0006Fm-U1 for emacs-devel@gnu.org; Sat, 05 Feb 2005 14:13:25 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CxVMx-0006FK-HA for emacs-devel@gnu.org; Sat, 05 Feb 2005 14:13:23 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CxV5l-00072A-K3; Sat, 05 Feb 2005 13:55:37 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id j15Itb9N012432; Sat, 5 Feb 2005 12:55:37 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j15IsGZ07501; Sat, 5 Feb 2005 12:54:16 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Sat, 05 Feb 2005 12:38:33 -0500) 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 X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:32918 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32918 Richard Stallman wrote: For the case of hooks, we could imagine changing cus-edit.el so that edits made using Custom only affect elements that were installed using Custom. Any other elements could be invisible and untouchable; or they might be displayed in a separate way as "program-added hooks" and untouchable through the usual Custom features. I believe the latter. The user should know that there are other, untouchable things in the list. In effect, this means treating a single list as if it were the combination of too list values, one to be edited through Custom and one to be updated by programs. I guess that Custom could use an internal custom-list-var for every list-var. Everything specified in the definition of the defcustom should be in custom-list-var and hence, removable. I don't know how hard this would be. That is the problem, of course. The problem occurs not only for hooks, but for every non-atom, to which elements can be added both by code and by the user. So the solution should apply to all such non-atoms. But not to lists that have a fixed length, like values that are a supposed to be a single cons. How do we tell such things apart? Probably from the type. So something in the type of a list to which elements can be added both through code and through Custom should say that Custom needs to use a custom-list-var. Currently, types are not designed with this in mind. How do we determine whether a defcustom of type 'sexp' with standard value nil is intended to be a variable length list or not? I believe that we eventually should go in a direction like this. If we want it for 21.4 somebody should essentially start to try to implement it right now. Per already has said that he has no time. I do currently not have the time to start implementing something like this either. Sincerely, Luc.