From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: comint-carriage-motion causes severe problems. Date: Thu, 04 Jul 2002 13:04:41 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200207041704.g64H4fU30311@rum.cs.yale.edu> References: <200207020035.TAA19789@eel.dms.auburn.edu> <200207021534.g62FYao17897@rum.cs.yale.edu> <200207021618.LAA20219@eel.dms.auburn.edu> <200207032057.g63KvX604721@aztec.santafe.edu> <200207032111.g63LBAv25925@rum.cs.yale.edu> <200207040118.UAA22469@eel.dms.auburn.edu> <200207041543.g64FhEb29778@rum.cs.yale.edu> <200207041656.LAA22736@eel.dms.auburn.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1025806219 15243 127.0.0.1 (4 Jul 2002 18:10:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 4 Jul 2002 18:10:19 +0000 (UTC) Cc: monnier+gnu/emacs@rum.cs.yale.edu, rms@gnu.org, miles@lsi.nec.co.jp, Kai.Grossjohann@CS.Uni-Dortmund.DE, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17QB3a-0003xk-00 for ; Thu, 04 Jul 2002 20:10:18 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17QB9h-00072z-00 for ; Thu, 04 Jul 2002 20:16:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17QAZW-0001zj-00; Thu, 04 Jul 2002 13:39:14 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17QA27-0007Qq-00; Thu, 04 Jul 2002 13:04:44 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g64H4fU30311; Thu, 4 Jul 2002 13:04:41 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Luc Teirlinck Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5466 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5466 > Let me just tell you about my concern. Through autoloads, :load and > :require keywords in defgroups and defcustoms and so on, plenty of > functions can be unpredictably added to the global values of hooks, > behind the user's back. This actually happens all the time in > practice. Just searching for some item using customize-browse can add > plenty of functions to hooks, even if no custumizations are actually > made. Some of these functions may be globally necessary, but cause > trouble locally. We may want to exclude them from the local value > before they appear in the global one because we have no idea when that > might happen. I haven't seen any evidence for the need of such a thing. The only cases I've seen where my patch is useful is when you want to turn a feature on globally but turn it off at a few places. Global customizations normally occur before buffers are created, so before the (remove-hook 'foo 'bar 'local) has even a chance of being run. If you could show me something more concrete, I might better understand your concern. > After all > > (remove-hook 'foo 'bar) > (add-hook 'foo 'bar) > > does not prevent `bar' from being run (the `remove-hook' above ends up > being a noop). > > This is not the same situation. We remove bar fom the global value > and add it right back. Clearly that should be a no-op. I assumed that the hook was nil before the above two commands were executed, which is why the `remove-hook' is a noop. Stefan