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 15:19:30 -0500 (CDT) Sender: emacs-devel-admin@gnu.org Message-ID: <200207042019.PAA23314@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 1025814042 28746 127.0.0.1 (4 Jul 2002 20:20:42 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 4 Jul 2002 20:20:42 +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 17QD5m-0007TX-00 for ; Thu, 04 Jul 2002 22:20:42 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17QDBv-0001Ye-00 for ; Thu, 04 Jul 2002 22:27:03 +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 17QD6C-0001Vr-00; Thu, 04 Jul 2002 16:21:08 -0400 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17QD3s-0001S9-00; Thu, 04 Jul 2002 16:18:44 -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 PAA21754; Thu, 4 Jul 2002 15:18:38 -0500 (CDT) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.9.3+Sun/8.9.3) id PAA23314; Thu, 4 Jul 2002 15:19:30 -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:5490 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5490 Richard Stallman wrote: This is semantically incoherent. It is very dangerous for two identical calls to remove-hook to be different in effect from one. Indeed, what happens, for instance, if a file containing such a call gets accidentally loaded a second time in the same session? I start again to lean somewhat towards my original 'override proposal with Richard's amendments, but I have no strong feelings about that. Anyway, first we need to decide whether the feature is needed, then we can worry about its concrete implementation. I personally do not feel like further discussing implementation before discussing desirability, unless desirability depends on implementation. First question: What are hooks meant for? >From the Emacs Lisp manual: Emacs provides hooks for the sake of customization. Most often hooks are set in the init file, but Lisp programs can set them also. What Lisp programs are meant? If these are user files or external packages or specialized very optional packages and no major Emacs file is ever supposed to add functions to a global hook, then indeed the new feature is not needed. But if so, one has the problem that that convention is not followed in the actual Emacs code. In a previous message I gave an example of how functions get into global hooks just by looking at documentation. Given the fact that this is the actual behavior, I believe that we need some form of the feature. Let us first see whether or not we can agree on that and then we can discuss implementation details. 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. I do not believe comint-carriage-motion should be called completely unconditionally, not even in shell buffers, but I could temporarily turn it off, using the variable in question, in shell or inferior Lisp buffers anyway, so that is no problem. But plenty of Emacs code would need to be changed if the above principles should be followed rigorously everywhere. Moreover, we could wind up with plenty of turn-this-function-off variables. Does comint-postoutput-scroll-to-bottom belong in the hook or should it too be called explicitly from code? Is it OK for customize-browse to unconditionally add ansi-color-process-output to the same global hook, just because I happen to consult documentation? (I do not mind about ansi-color-process-output itself, it causes no harm, but it is a good example.) I agree that the turn-off variable solution provides an adequate solution to the comint-ielm problem. The new feature is more convenient in that it only requires changes in the local specialized package rather than in both the specialized and the general package. However, it would make no sense to add a feature just for this one problem, which can indeed easily be solved in other ways. To summarize, I personally believe that there is a need for this feature because of the ways hooks are used in practice in Emacs, regardless of how they are theoretically supposed to be used. Sincerely, Luc.