emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comint-carriage-motion causes severe problems.


From: Luc Teirlinck
Subject: Re: comint-carriage-motion causes severe problems.
Date: Thu, 4 Jul 2002 19:47:38 -0500 (CDT)

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]