From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: add-hook and defvar Date: Mon, 23 Feb 2015 05:00:56 +0000 Message-ID: References: <87y4nqopup.fsf@panthera.terpri.org> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c356049e4041050fba498d X-Trace: ger.gmane.org 1424667676 28076 80.91.229.3 (23 Feb 2015 05:01:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Feb 2015 05:01:16 +0000 (UTC) Cc: emacs-devel To: Robin Templeton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 23 06:01:16 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YPl8r-0008LG-1u for ged-emacs-devel@m.gmane.org; Mon, 23 Feb 2015 06:01:13 +0100 Original-Received: from localhost ([::1]:42075 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPl8q-00080R-8c for ged-emacs-devel@m.gmane.org; Mon, 23 Feb 2015 00:01:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPl8d-0007zV-LJ for emacs-devel@gnu.org; Mon, 23 Feb 2015 00:01:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YPl8c-00057m-6x for emacs-devel@gnu.org; Mon, 23 Feb 2015 00:00:59 -0500 Original-Received: from mail-la0-x236.google.com ([2a00:1450:4010:c03::236]:36767) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPl8b-00057g-Qz for emacs-devel@gnu.org; Mon, 23 Feb 2015 00:00:58 -0500 Original-Received: by labgq15 with SMTP id gq15so16334838lab.3 for ; Sun, 22 Feb 2015 21:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GkAQaUCHRxLJdW4pb9liBmhpf9GHPkfg5uLMo0Fvq88=; b=hp2bJJg+XLsjoK47LN2mIooe8IQPM6vzz24rmVL35bMuFnKqhGUfGGrQLziTGZs6iW jsikFYYBg3hs++0q8lIXpihmXc9m+s31gbFKcNHoHRsYHrkA0PY4L41iHwwa2RHTMD9C cgz63vUX/2h3FnkHk94EYo5kJp3jufVr01JzLMFXwv/sfB6srlx3cLWi0bvZz5OHRhwO RiQHasoLG8CnWBm09XltUfHQtxR/PTVgJxM2WlX5/9O1m6XFZX4eOaAvooUw3+OBglck FW0ygbrErL5XdMABKYcZbrc3y+CwgRZ+XLk71kY7JUHAOS5Q1X66JNghY619ZmFa1MUX jnfQ== X-Received: by 10.152.42.238 with SMTP id r14mr8191646lal.13.1424667656993; Sun, 22 Feb 2015 21:00:56 -0800 (PST) Original-Received: by 10.112.49.9 with HTTP; Sun, 22 Feb 2015 21:00:56 -0800 (PST) Original-Received: by 10.112.49.9 with HTTP; Sun, 22 Feb 2015 21:00:56 -0800 (PST) In-Reply-To: <87y4nqopup.fsf@panthera.terpri.org> X-Google-Sender-Auth: dxJfZSX9jIu_sSdS-tIGz-h8YYI X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::236 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:183414 Archived-At: --001a11c356049e4041050fba498d Content-Type: text/plain; charset=UTF-8 On Feb 21, 2015 8:35 PM, "Robin Templeton" wrote: > > Artur Malabarba writes: > > > While it's nice that `add-hook' tries to do the right thing even when > > the variable isn't defined yet, that's a bit of a false assurance. > > Although it's documented in the docstring, it seems undesirable that > > it sets the variable. This means that if the hook's defvar were to > > specify an initial value, this value won't take effect because of that > > preceding `add-hook' invocation. > > This seems like a bug in the program defining the hook variable, not a > problem with `add-hook' per se; programs should always allow for the > possibility that the user has set their own value for a variable and > that the default value in the defvar form is ignored. The problem is not that the hook will stop working if it gets overriden, it's more about the fact that the the user probably doesn't know that `add-hook' is actually behaving like `override-hook'. I've been a user/developer for years and I only just found out this year. The fact that add-hook works even before the variable is defined gives the impression that it's always safe to use. But it's actually quite the opposite. It would have just been better if it behaved like all other functions of this type, throwing an error if the variable isn't defined. >I would expect the > program to call `add-hook' itself if the default hook functions were > important. I'm not too worried about hook-functions that are vital, as the developer can always just move these out of the hooks. But I am worried that the developer trying to provide default behaviour for hooks has no sage way of doing that. If the program calls add-hook as you suggest, then the user who actually *wants* to completely override the hook (by using `setq') won't be able to, because you're manually adding these other values to it. Defining a variable with an initial value is the standard way of offering a default behaviour. And it's a problem that such a widely used function doesn't play well with that. > Another potential problem is that `add-hook' followed by `run-hooks' > will do nothing if the hook variable has not been defined. Yes, but isn't it a bug to run-hooks a variable that wasn't explicitly defined? > If the > behavior of `add-hook' were changed, I would prefer it if it simply > required the variable to be defined; that would avoid the above > disadvantages, would make it consistent with functions like > `add-to-list', and would normally ensure that the hook is initialized as > expected. I'm fine for that too. We could also provide a new function like add-to-hook in order to provide backwards compatibility, and slowly obsolete add-hook. --001a11c356049e4041050fba498d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Feb 21, 2015 8:35 PM, "Robin Templeton" <robin@terpri.org> wrote:
>
> Artur Malabarba <bruce= .connor.am@gmail.com> writes:
>
> > While it's nice that `add-hook' tries to do the right thi= ng even when
> > the variable isn't defined yet, that's a bit of a false a= ssurance.
> > Although it's documented in the docstring, it seems undesirab= le that
> > it sets the variable. This means that if the hook's defvar we= re to
> > specify an initial value, this value won't take effect becaus= e of that
> > preceding `add-hook' invocation.
>
> This seems like a bug in the program defining the hook variable, not a=
> problem with `add-hook' per se; programs should always allow for t= he
> possibility that the user has set their own value for a variable and > that the default value in the defvar form is ignored.

The problem is not that the hook will stop working if it get= s overriden, it's more about the fact that the the user probably doesn&= #39;t know that `add-hook' is actually behaving like `override-hook'= ;. I've been a user/developer for years and I only just found out this = year.

The fact that add-hook works even before the variable is def= ined gives the impression that it's always safe to use. But it's ac= tually quite the opposite. It would have just been better if it behaved lik= e all other functions of this type, throwing an error if the variable isn&#= 39;t defined.

>I would expect the
> program to call `add-hook' itself if the default hook functions we= re
> important.

I'm not too worried about hook-functions that are vital,= as the developer can always just move these out of the hooks. But I am wor= ried that the developer trying to provide default behaviour for hooks has n= o sage way of doing that.

If the program calls add-hook as you suggest, then the user = who actually *wants* to completely override the hook (by using `setq') = won't be able to, because you're manually adding these other values= to it.

Defining a variable with an initial value is the standard wa= y of offering a default behaviour. And it's a problem that such a widel= y used function doesn't play well with that.

> Another potential problem is that `add-hook' follow= ed by `run-hooks'
> will do nothing if the hook variable has not been defined.

Yes, but isn't it a bug to run-hooks a variable that was= n't explicitly defined?

> If the
> behavior of `add-hook' were changed, I would prefer it if it simpl= y
> required the variable to be defined; that would avoid the above
> disadvantages, would make it consistent with functions like
> `add-to-list', and would normally ensure that the hook is initiali= zed as
> expected.

I'm fine for that too. We could also provide a new funct= ion like add-to-hook in order to provide backwards compatibility, and slowl= y obsolete add-hook.

--001a11c356049e4041050fba498d--