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: Wed, 3 Jul 2002 20:18:55 -0500 (CDT) Sender: emacs-devel-admin@gnu.org Message-ID: <200207040118.UAA22469@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> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1025745663 17103 127.0.0.1 (4 Jul 2002 01:21:03 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 4 Jul 2002 01:21:03 +0000 (UTC) Cc: rms@gnu.org, 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 17PvIt-0004Rk-00 for ; Thu, 04 Jul 2002 03:21:03 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17PvOe-0001Ew-00 for ; Thu, 04 Jul 2002 03:27:00 +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 17PvIx-0004XW-00; Wed, 03 Jul 2002 21:21:07 -0400 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17PvG0-0004Ox-00; Wed, 03 Jul 2002 21:18:04 -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 UAA20392; Wed, 3 Jul 2002 20:18:03 -0500 (CDT) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.9.3+Sun/8.9.3) id UAA22469; Wed, 3 Jul 2002 20:18:55 -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: <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:5431 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5431 Stefan Monnier wrote: 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 decision was arbitrary (mostly trying to minimize the change in behavior for better compatibility). I believe that in the given situation it is actually the only choice. If bar occurs in both the global and the local value it will get executed twice each time foo is ran. This is very likely to be unintended. The user should be able to correct the situation with a single (remove-hook 'foo 'bar 'local) rather than still having to re-add it to the global value. However, I now believe that there is an even better solution which not only removes the arbitrariness in the above example, but moreover removes any danger of breaking existing code, which otherwise seems to be a very real danger, and which also adds useful flexibility. Indeed, I now start to get really weary about breaking existing code where people rely on the fact that remove-hook "does no harm anyway" if bar is not in the local value of foo and hence it does not matter whether (remove-hook 'foo 'bar 'local) is executed several times if a file is accidentally loaded more than once. 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. So: (remove 'foo 'bar 'local) completely keeps the present behavior: remove from local value if bar is in the local value. Do nothing otherwise. Same if 'local is replaced by t or any value other than nil or override. (remove 'foo 'bar 'override) overrides any other occurrences of bar further down the list, local or global. Depending on peoples' style, current code may contain third non-nil arguments of t or 'local, as you use, but I can not possibly see how people would have used a third argument 'override anywhere. (Unless they were actually anticipating your code.) Hence, all worries about breaking existing code would be gone, the worry about arbitrariness in cases of the type you describe is gone, the worry about bad things happening if files get accidentally loaded more than once is totally gone and we have, moreover, better flexibility. Sincerely, Luc Teirlinck.