From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: comint-carriage-motion causes severe problems. Date: Thu, 4 Jul 2002 12:24:08 -0600 (MDT) Sender: emacs-devel-admin@gnu.org Message-ID: <200207041824.g64IO8i06426@aztec.santafe.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> Reply-To: rms@gnu.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1025809715 21333 127.0.0.1 (4 Jul 2002 19:08:35 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 4 Jul 2002 19:08:35 +0000 (UTC) Cc: teirllm@dms.auburn.edu, monnier+gnu/emacs@rum.cs.yale.edu, 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 17QBxz-0005Xy-00 for ; Thu, 04 Jul 2002 21:08:35 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17QC46-0008Ov-00 for ; Thu, 04 Jul 2002 21:14:55 +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 17QBSm-0007Ap-00; Thu, 04 Jul 2002 14:36:20 -0400 Original-Received: from pele.santafe.edu ([192.12.12.119]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17QBGz-0005Wt-00; Thu, 04 Jul 2002 14:24:09 -0400 Original-Received: from aztec.santafe.edu (aztec [192.12.12.49]) by pele.santafe.edu (8.11.6+Sun/8.11.6) with ESMTP id g64IOCV00558; Thu, 4 Jul 2002 12:24:12 -0600 (MDT) Original-Received: (from rms@localhost) by aztec.santafe.edu (8.10.2+Sun/8.9.3) id g64IO8i06426; Thu, 4 Jul 2002 12:24:08 -0600 (MDT) X-Authentication-Warning: aztec.santafe.edu: rms set sender to rms@aztec using -f Original-To: monnier+gnu/emacs@rum.cs.yale.edu In-Reply-To: <200207032111.g63LBAv25925@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:5477 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5477 Actually, there are some unclear semantics when you do things like (add-hook 'foo 'bar) (add-hook 'foo 'bar nil 'local) (remove-hook 'foo 'bar 'local) The current code removes `bar' from the local value of `foo' but leaves it in the global one. My new code does the same and only a second (remove-hook 'foo 'bar 'local) will add a (not . bar) such that the global setting is overridden. This is semantically incoherent. It is very dangerous for two identical calls to remove-hook to be different in effect from one. I am starting to believe that it might be good to keep the present behavior of remove-hook, unless the third argument is the symbol 'override, in which case it would override any function later in the hook, including global functions. That gives a clean and predictable semantics for remove-hook. However, this leaves the question of how you remove one of these overrides. Related question: how should add-hook deal with them? This relates to another question: what should (remove-hook 'foo 'bar 'local) do after (remove-hook 'foo 'bar 'override)? Nothing? I don't think that is right, because doing nothing would leave the override marker in place; the state for `bar' would not be "no local hook". There are three states that the local hook list can have, for any function `bar': 1. Present 2. Absent 3. Overridden. We could say that (add-hook 'foo 'bar 'local) puts it in state 1, (remove-hook 'foo 'bar 'local) puts it in state 2, and (remove-hook 'foo 'bar 'override) puts it in state 3. None of them changes the global hook list, and global use of add-hook or remove-hook does not change the local hook list. Now we have fully coherent semantics for both add-hook and remove-hook. However, I think it is even cleaner to regard (not . bar) as a kind of local hook value in its own right, and use add-hook to add that and remove-hook to remove it. (add-hook 'foo 'bar 'local) puts it in state 1 (remove-hook 'foo 'bar 'local) puts it in state 2 (add-hook 'foo '(not . bar) 'local) puts it in state 3 (remove-hook 'foo '(not . bar) 'local) puts it in state 2 so this is equivalent to (remove-hook 'foo 'bar 'local). This is a coherent feature. Is it really useful? I am not sure. The reason is, it is wrong to call comint-carriage-motion by adding it globally and unconditionally to the hook. When a function should be called unconditionally, it should be called explicitly from the code, not thru a hook. Once this change is made, the way to fix the present problem is for ielm to bind a variable that tells the code not to call comint-carriage-motion, or tells comint-carriage-motion to do nothing. The hook override feature won't be used here. Do we have any other occasion to use the hook override feature? Is that a useful feature?