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 22:02:45 -0600 (CST) Message-ID: <200502060402.j1642jN21168@raven.dms.auburn.edu> References: <200502040036.j140atb03430@raven.dms.auburn.edu> <200502060150.j161oqh15336@raven.dms.auburn.edu> <200502060326.j163QkE16205@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1107663098 8983 80.91.229.2 (6 Feb 2005 04:11:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 6 Feb 2005 04:11:38 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 06 05:11:38 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Cxdli-0005aM-Bk for ged-emacs-devel@m.gmane.org; Sun, 06 Feb 2005 05:11:30 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CxdzZ-0001rE-8m for ged-emacs-devel@m.gmane.org; Sat, 05 Feb 2005 23:25:49 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cxdy4-0001Xp-RN for emacs-devel@gnu.org; Sat, 05 Feb 2005 23:24:16 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cxdxy-0001TP-Pz for emacs-devel@gnu.org; Sat, 05 Feb 2005 23:24:11 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cxdxx-0001S1-Ms for emacs-devel@gnu.org; Sat, 05 Feb 2005 23:24:10 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cxdea-00067n-8s; Sat, 05 Feb 2005 23:04:08 -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 j164479N003627; Sat, 5 Feb 2005 22:04:07 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j1642jN21168; Sat, 5 Feb 2005 22:02:45 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: teirllm@dms.auburn.edu In-reply-to: <200502060326.j163QkE16205@raven.dms.auburn.edu> (message from Luc Teirlinck on Sat, 5 Feb 2005 21:26:46 -0600 (CST)) 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:32931 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32931 >>From my previous message: Maybe we could avoid that additional complexity if non-preloaded code strictly adhered to the conventions proposed in another message and if preloaded code put, for all involved list-vars, all elements of the involved hook, list or alist, that should be user-overridable in custom-list-var (instead of just in list-var). That way, these elements would _not_ appear in the Custom buffer as "untouchable". The situation is somewhat more complex. _Newly added_ (by code) elements could be unwittingly overridden by .emacs if they were just put into custom-list-var. (That is one of the reasons why the distinction between list-var and custom-list-var is needed. I forgot about that for a moment.) But _maybe_ it is OK anyway. _Essential_ elements get put in list-var, so Emacs will never malfunction as a result of essential new code being overridden in .emacs. Non-essential ones go in custom-list-var. When upgrading to a new Emacs version, the user could then do `M-x customize-changed-options' to see what new non-essential elements were added and see whether he likes them. Maybe we may need special `remove-hook' and `delete' functionality, maybe we can avoid it. Probably the person volunteering to implement this (if anybody) might have to decide. Sincerely, Luc.