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: comint-carriage-motion causes severe problems. Date: Thu, 4 Jul 2002 11:56:22 -0500 (CDT) Sender: emacs-devel-admin@gnu.org Message-ID: <200207041656.LAA22736@eel.dms.auburn.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> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1025805772 14509 127.0.0.1 (4 Jul 2002 18:02:52 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 4 Jul 2002 18:02:52 +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 17QAwO-0003lu-00 for ; Thu, 04 Jul 2002 20:02:52 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17QB2U-0006ux-00 for ; Thu, 04 Jul 2002 20:09:10 +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 17QAwi-0004SL-00; Thu, 04 Jul 2002 14:03:12 -0400 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17Q9tC-0006kM-00; Thu, 04 Jul 2002 12:55:30 -0400 Original-Received: from eel.dms.auburn.edu (eel.dms.auburn.edu [131.204.53.108]) by manatee.dms.auburn.edu (8.9.1a/8.9.1) with ESMTP id LAA21240; Thu, 4 Jul 2002 11:55:28 -0500 (CDT) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.9.3+Sun/8.9.3) id LAA22736; Thu, 4 Jul 2002 11:56:22 -0500 (CDT) X-Authentication-Warning: eel.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: monnier+gnu/emacs@rum.cs.yale.edu In-Reply-To: <200207041543.g64FhEb29778@rum.cs.yale.edu> (monnier+gnu/emacs@rum.cs.yale.edu) 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:5465 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5465 Dear Stefan, My main concern with the 'override stuff was the danger of breaking existing code and the danger of repeated loading having unwanted effects. If you checked out things carefully, then I guess it is not needed. This makes, of course, the other change a little bit more dangerous, since its effect on existing code has not been tested yet. 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. 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. On the other hand: (remove-hook 'foo 'bar 'local) (add-hook 'foo 'bar) first removes it from the local value and then adds it to the global. This is not an inverse operation, as in the previous example, and hence, there is no logical reason why it should be a no-op. I will wait for your comments before making any additional suggestions. Sincerely, Luc.