From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: custom-set-variables fails to set variable Date: Fri, 11 Nov 2005 22:05:29 -0600 (CST) Message-ID: <200511120405.jAC45Tl25795@raven.dms.auburn.edu> References: <11859.1131656026@olgas.newt.com> <87lkzwxduk.fsf@olgas.newt.com> <200511110043.jAB0hhc17895@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1131768442 30542 80.91.229.2 (12 Nov 2005 04:07:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 12 Nov 2005 04:07:22 +0000 (UTC) Cc: p.galbraith@globetrotter.net, wohler@newt.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 12 05:07:17 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EameZ-0006Dl-MI for ged-emacs-devel@m.gmane.org; Sat, 12 Nov 2005 05:06:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EameZ-0000IO-1i for ged-emacs-devel@m.gmane.org; Fri, 11 Nov 2005 23:06:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EameP-0000IJ-S5 for emacs-devel@gnu.org; Fri, 11 Nov 2005 23:06:01 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EameO-0000Hn-9u for emacs-devel@gnu.org; Fri, 11 Nov 2005 23:06:01 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EameO-0000Hk-8L for emacs-devel@gnu.org; Fri, 11 Nov 2005 23:06:00 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EameN-0007hx-DQ; Fri, 11 Nov 2005 23:05:59 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.13.3+Sun/8.13.3) with ESMTP id jAC45nTI015398; Fri, 11 Nov 2005 22:05:49 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id jAC45Tl25795; Fri, 11 Nov 2005 22:05:29 -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: (rms@gnu.org) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.1 (manatee.dms.auburn.edu [131.204.53.104]); Fri, 11 Nov 2005 22:05:49 -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 Xref: news.gmane.org gmane.emacs.devel:45798 Archived-At: Why does define-minor-mode need to defvar the mode hook? There is no need to defvar hooks. `add-hook' can perfectly handle unbound hook variables. I propose that we revert this change in define-derived-mode. I agree, if we can't find a better solution. Another possible solution is to autoload the defcustoms for these particular variables. Would that work? Yes, but this is inevitably going to be forgotten for some defcustoms. A more automatic solution could be: define-derived-mode could automatically produce an autoload definition of the defvar. That would solve the problem, right? Yes, but both the manual and the automated solutions have the potential for problems. Somebody supplying a defcustom may want a tailor-made docstring for the defcustom, mentioning typical uses for the hook and the defvar's docstring could overwrite that. In general, it does not seem very good to have two competing different definitions for a variable. This solution might also unnecessarily bloat loaddefs. Remember that all of this came about because the mode's docstring contains: Entry to this mode calls the value of `lisp-mode-hook' if that value is non-nil. And `C-h v' on lisp-mode-hook did not work. Maybe we could just change that to: Entry to this mode calls the value of `lisp-mode-hook' if that value is bound and non-nil. `add-hook' automatically binds a hook variable if it was previously unbound. That would also help people understand why `C-h v foo-hook' does not always work for hooks. Many hooks that are not mode hooks have no defvar. Sincerely, Luc.