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 19:47:38 -0500 (CDT) Sender: emacs-devel-admin@gnu.org Message-ID: <200207050047.TAA23595@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> <200207041824.g64IO8i06426@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1025830082 18565 127.0.0.1 (5 Jul 2002 00:48:02 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 5 Jul 2002 00:48:02 +0000 (UTC) Cc: monnier+gnu/emacs@rum.cs.yale.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 17QHGU-0004pK-00 for ; Fri, 05 Jul 2002 02:48:02 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17QHMj-0007iE-00 for ; Fri, 05 Jul 2002 02:54:29 +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 17QHGb-00082Y-00; Thu, 04 Jul 2002 20:48:09 -0400 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17QHFQ-0007zn-00; Thu, 04 Jul 2002 20:46:56 -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 TAA22026; Thu, 4 Jul 2002 19:46:47 -0500 (CDT) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.9.3+Sun/8.9.3) id TAA23595; Thu, 4 Jul 2002 19:47:38 -0500 (CDT) X-Authentication-Warning: eel.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: rms@gnu.org In-Reply-To: <200207041824.g64IO8i06426@aztec.santafe.edu> (message from Richard Stallman on Thu, 4 Jul 2002 12:24:08 -0600 (MDT)) 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:5498 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5498 Richard Stallman wrote: 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? I am not too sure I answered this question adequately in my previous message. Again the proposed solution for the ielm-comint problem using a variable is perfectly satisfactory. Richard's question seems to be: Do we know any other use for this feature in the Emacs source code? I do not know any and if one crops up, we could always use the variable trick again. But that is not really what I believe the main question is. The main question is: Is it useful for user customization? If the user wants to call a hook function unconditionally, (s)he adds it to the global hook. If (s)he wants to add it to a few specialized modes (s)he adds them to the corresponding local hooks. What does (s)he do if (s)he wants it in all but a few modes, where it back-fires? It seems inconvenient to add the function locally to all modes (s)he could possibly ever use, including new modes in new emacs releases, just to avoid enabling them in, say, one single mode. In addition, the proposed variable trick requires changing the file that sets the global value, which quite often is a file that is part of Emacs. With the feature a user (or somebody writing some major-mode package) can easily override a locally inappropriate function. Using the variable trick would not work without altering the Emacs source code. I believe I allowed myself to get side-tracked and somewhat unfocused in my previous message. Sincerely, Luc.