unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
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
Subject: Re: comint-carriage-motion causes severe problems.
Date: Thu, 4 Jul 2002 15:19:30 -0500 (CDT)	[thread overview]
Message-ID: <200207042019.PAA23314@eel.dms.auburn.edu> (raw)
In-Reply-To: <200207041824.g64IO8i06426@aztec.santafe.edu> (message from Richard Stallman on Thu, 4 Jul 2002 12:24:08 -0600 (MDT))

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.

  reply	other threads:[~2002-07-04 20:19 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-02  0:35 comint-carriage-motion causes severe problems Luc Teirlinck
2002-07-02  1:32 ` Miles Bader
2002-07-02  8:33   ` Kai Großjohann
2002-07-02  8:46     ` Miles Bader
2002-07-02 15:34       ` Stefan Monnier
2002-07-02 16:18         ` Luc Teirlinck
2002-07-03 20:57           ` Richard Stallman
2002-07-03 21:11             ` Stefan Monnier
2002-07-04  1:18               ` Luc Teirlinck
2002-07-04 15:43                 ` Stefan Monnier
2002-07-04 16:56                   ` Luc Teirlinck
2002-07-04 17:04                     ` Stefan Monnier
2002-07-04 17:18                       ` Kai Großjohann
2002-07-04 17:31                       ` Luc Teirlinck
2002-07-04 18:21                       ` Miles Bader
2002-07-04  1:38               ` Luc Teirlinck
2002-07-04  3:49               ` Luc Teirlinck
     [not found]               ` <200207040337.WAA22499@eel.dms.auburn.edu>
     [not found]                 ` <200207041531.g64FVRp29714@rum.cs.yale.edu>
2002-07-04 16:07                   ` Luc Teirlinck
2002-07-04 18:24               ` Richard Stallman
2002-07-04 20:19                 ` Luc Teirlinck [this message]
2002-07-05 22:07                   ` Richard Stallman
2002-07-05  0:47                 ` Luc Teirlinck
2002-07-05 22:07                   ` Richard Stallman
2002-08-07  1:16                 ` Luc Teirlinck
2002-08-07 20:58                   ` Richard Stallman
2002-08-07 22:19                     ` Luc Teirlinck
2002-08-07 22:27                       ` Luc Teirlinck
2002-08-09  2:47                       ` Richard Stallman
2002-08-18  2:39                     ` Luc Teirlinck
2002-08-18  3:01                       ` Luc Teirlinck
2002-08-18  3:59                         ` Luc Teirlinck
2002-08-19  5:04                       ` Miles Bader
2002-07-02 17:08         ` Luc Teirlinck
2002-07-02 19:45   ` Richard Stallman
2002-07-03  0:02     ` Miles Bader
2002-07-03  0:06     ` Miles Bader
2002-07-04  7:07       ` Richard Stallman
2002-07-03  1:51     ` Luc Teirlinck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200207042019.PAA23314@eel.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=Kai.Grossjohann@CS.Uni-Dortmund.DE \
    --cc=emacs-devel@gnu.org \
    --cc=miles@lsi.nec.co.jp \
    --cc=monnier+gnu/emacs@rum.cs.yale.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).