Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 3E9CA431E64 for ; Mon, 9 Jul 2012 22:10:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaPdwjlbrO8V for ; Mon, 9 Jul 2012 22:10:10 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 84D1E431FBF for ; Mon, 9 Jul 2012 22:10:10 -0700 (PDT) Received: by obbup19 with SMTP id up19so17448987obb.26 for ; Mon, 09 Jul 2012 22:10:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Fg2Uwhh5zA8nEdMi2pcJI2a18tVrMZvYYmn8oBVGHnM=; b=CLzFdsI/6mzwIOdahpHC3Nru60PSAuB4eqi+GZogwO9HPQe70z3Zl+9Be+TFZIECab KLGdxvghbmewMZ3Oo/EABeWwTqSyHvx8udJv65d4WdgNeM7Bdf56Sf0S/bNmphoKkXh4 LNUUlwXGlfWkAWVOQCozvYHUKu3NJDu/GGr8Mj2NEbNHXV1gtghmLeoyifwgmnWWdKGG gv3IXsEG/PmWxsCwm4WDBeQ7t6SHzVxEbIh3dbqnDGFR/P7HXi/iM5c4wURodkOgIJ6T 9GlRj0YUEWrIG2TpeELAWXcqJOx/uD1xeRj+7aIopOvNGxHq7RP+FoalmOKYydJUNAIo vJzw== MIME-Version: 1.0 Received: by 10.60.29.169 with SMTP id l9mr45156010oeh.14.1341897009938; Mon, 09 Jul 2012 22:10:09 -0700 (PDT) Received: by 10.76.10.102 with HTTP; Mon, 9 Jul 2012 22:10:09 -0700 (PDT) Received: by 10.76.10.102 with HTTP; Mon, 9 Jul 2012 22:10:09 -0700 (PDT) In-Reply-To: <20120710014946.GB7332@mit.edu> References: <37899e28dbf67e4620a53279a869be3174c02d6f.1339775602.git.jani@nikula.org> <20120710014946.GB7332@mit.edu> Date: Tue, 10 Jul 2012 08:10:09 +0300 Message-ID: Subject: Re: [PATCH 1/3] emacs: add no-display arg to notmuch-hello-refresh-hook From: Jani Nikula To: Austin Clements Content-Type: multipart/alternative; boundary=e89a8ff256669a3fba04c472beb9 X-Gm-Message-State: ALoCoQn99NemvpcM0NwaszaY+zElx/HEYIgy/U6R0zI6Qxi4q4+Cy98ageesncHD47kcMsYveDRn Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 05:10:11 -0000 --e89a8ff256669a3fba04c472beb9 Content-Type: text/plain; charset=UTF-8 On Jul 10, 2012 4:49 AM, "Austin Clements" wrote: > > Quoth Jani Nikula on Jun 15 at 6:53 pm: > > Add no-display arg to notmuch-hello-refresh-hook to allow each hook to > > decide what is appropriate when no-display is t, which is typically > > the case when called non-interactively. This is used by the following > > patch. > > > > This breaks existing hooks people might have, which will now need to > > accept the argument. > > > > Signed-off-by: Jani Nikula > > This seems like an overloaded use of no-display. If I'm reading the > code right, no-display indicates whether or not the notmuch-hello > buffer should be switched to and seems like a workaround for some > particular corner-case (I'm not even sure what). This seems like a > strange condition to predicate a hook on (but maybe I just don't > understand). What condition, abstractly speaking, is > notmuch-hello-refresh-status-message trying to run under? IIUC, no-display is useful for calling refresh from outside of emacs, e.g. from post-new hook in an automated fashion, so you can have an up-to-date buffer when you switch to it. There's no point in displaying the refresh message when you don't also switch to the buffer, is there? And this way you'll get the diff between the manual (through user interaction) refreshes of the buffer, not between two cron jobs. J. --e89a8ff256669a3fba04c472beb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 10, 2012 4:49 AM, "Austin Clements" <amdragon@mit.edu> wrote:
>
> Quoth Jani Nikula on Jun 15 at =C2=A06:53 pm:
> > Add no-display arg to notmuch-hello-refresh-hook to allow each ho= ok to
> > decide what is appropriate when no-display is t, which is typical= ly
> > the case when called non-interactively. This is used by the follo= wing
> > patch.
> >
> > This breaks existing hooks people might have, which will now need= to
> > accept the argument.
> >
> > Signed-off-by: Jani Nikula <jani@nikula.org>
>
> This seems like an overloaded use of no-display. =C2=A0If I'm read= ing the
> code right, no-display indicates whether or not the notmuch-hello
> buffer should be switched to and seems like a workaround for some
> particular corner-case (I'm not even sure what). =C2=A0This seems = like a
> strange condition to predicate a hook on (but maybe I just don't > understand). =C2=A0What condition, abstractly speaking, is
> notmuch-hello-refresh-status-message trying to run under?

IIUC, no-display is useful for calling refresh from outside of emacs, e.= g. from post-new hook in an automated fashion, so you can have an up-to-dat= e buffer when you switch to it. There's no point in displaying the refr= esh message when you don't also switch to the buffer, is there? And thi= s way you'll get the diff between the manual (through user interaction)= refreshes of the buffer, not between two cron jobs.

J.

--e89a8ff256669a3fba04c472beb9--