From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lute Kamstra Newsgroups: gmane.emacs.devel Subject: Re: define-derived-mode Date: Tue, 10 May 2005 10:47:45 +0200 Message-ID: <87wtq731se.fsf@xs4all.nl> References: <200505080101.j48117N24298@raven.dms.auburn.edu> <200505080315.j483F2l24405@raven.dms.auburn.edu> <200505081748.j48HmHm26026@raven.dms.auburn.edu> <8764xs7kmi.fsf@xs4all.nl> <200505100007.j4A078L07495@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1115716326 26304 80.91.229.2 (10 May 2005 09:12:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 10 May 2005 09:12:06 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 10 11:11:59 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DVQlk-0005GV-V4 for ged-emacs-devel@m.gmane.org; Tue, 10 May 2005 11:11:14 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DVQuG-0005KU-7C for ged-emacs-devel@m.gmane.org; Tue, 10 May 2005 05:20:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DVQYC-0002Ry-DQ for emacs-devel@gnu.org; Tue, 10 May 2005 04:57:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DVQY6-0002RM-Ql for emacs-devel@gnu.org; Tue, 10 May 2005 04:57:10 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DVQQs-0002Bh-E8 for emacs-devel@gnu.org; Tue, 10 May 2005 04:49:41 -0400 Original-Received: from [194.109.24.26] (helo=smtp-vbr6.xs4all.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DVQVO-0004Lw-Mn; Tue, 10 May 2005 04:54:19 -0400 Original-Received: from pijl (a80-127-67-124.adsl.xs4all.nl [80.127.67.124]) by smtp-vbr6.xs4all.nl (8.12.11/8.12.11) with ESMTP id j4A8lk4d060150; Tue, 10 May 2005 10:47:46 +0200 (CEST) (envelope-from Lute.Kamstra@xs4all.nl) Original-Received: from lute by pijl with local (Exim 3.36 #1 (Debian)) id 1DVQP4-00016k-00; Tue, 10 May 2005 10:47:46 +0200 Original-To: Luc Teirlinck In-Reply-To: <200505100007.j4A078L07495@raven.dms.auburn.edu> (Luc Teirlinck's message of "Mon, 9 May 2005 19:07:08 -0500 (CDT)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Original-Lines: 69 X-Virus-Scanned: by XS4ALL Virus Scanner 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:36936 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36936 Luc Teirlinck writes: > Lute Kamstra wrote: > > > which was an incompatible change. > > Not compatible with what? > > With pre-existing defvars or defcustoms for these hooks. (Unless you > checked for _all_ uses of `define-generic-mode' that there are none. > But how did you get a list of _all_ outside packages that use it?) define-generic-mode is an all-in-one solution for defining a major mode. You call it, and every aspect of the major mode should be set up. I think it's very unlikely that anyone who uses define-generic-mode will add a defvar for the mode hook. (This certainly isn't the case in Emacs' sources.) > In the case of `define-minor-mode' two concrete examples of variables > with competing defcustoms are auto-revert-mode-hook and > global-auto-revert-mode-hook. In this particular case, not too much > harm is done, but it is not exactly very clean. > > I primarily wanted to define the mode hook as a variable so that I > could give it docstring. I chose defcustom over defvar because > define-minor-mode and quite some other major modes did that. I don't > strongly object to making the defcustom a defvar, but I don't > understand your problems with the use of defcustom: > > I have a problem with _both_ defvar and defcustom. Hooks do not need > a defvar, most hooks do not have them. The only reason for a defvar > is to add a docstring. You use the defvar to give the hook the > docstring: "Hook run when entering Mymode mode.". This "generic" > docstring contains no info that is not already contained in the hook's > name and it could overwrite _real_ info contained in a handwritten > defvar or defcustom. > > If you want to make people aware of the mode hook, it would seem > better to put an additional sentence in the default mode doc: > > "Mymode mode. > This a generic mode defined with `define-generic-mode'. > As all such modes, it runs `foo-mode-hook' as the very last thing it does." Ok, that sounds reasonable. I'll implement that. > I don't recall the bugs you refer to; could you give me the subject(s) > of the relevant thread(s)? > > It is scattered over several threads. Threads about Custom tend to be > superlong and unfocused. `find-file-hook as illustration of Custom problems' > is one of the threads, but several other threads about Custom were > going on at the same time and they all intertwined. > > There are several problems, related to the fact that hooks have to be > customized using add-hook and remove-hook and not using setq. But > Custom does use setq. Here is an example of the type of problems that > occur. (By no means the only one.) The user customizes foo-hook > using Custom. Then in the next Emacs version, a very essential > function badly-needed-fun is added to foo-hook. The user's > custom-set-variables form overrides the adding of badly-needed-fun to > foo-hook. > > These kind of problems are supposed to get fixed in 23 or 24, but it > is too tricky to still get it done for 22. Thanks for clarifying, Lute.