unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
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
Subject: Re: comint-carriage-motion causes severe problems.
Date: Wed, 3 Jul 2002 20:18:55 -0500 (CDT)	[thread overview]
Message-ID: <200207040118.UAA22469@eel.dms.auburn.edu> (raw)
In-Reply-To: <200207032111.g63LBAv25925@rum.cs.yale.edu> (monnier+gnu/emacs@rum.cs.yale.edu)

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.

  reply	other threads:[~2002-07-04  1:18 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 [this message]
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
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=200207040118.UAA22469@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 \
    --cc=rms@gnu.org \
    /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).