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 0BF8C431FAF for ; Wed, 18 Jan 2012 14:18:56 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 N5ORukdyjKbR for ; Wed, 18 Jan 2012 14:18:55 -0800 (PST) Received: from mail-qw0-f46.google.com (mail-qw0-f46.google.com [209.85.216.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 66FDB431FAE for ; Wed, 18 Jan 2012 14:18:55 -0800 (PST) Received: by qadc10 with SMTP id c10so2114467qad.5 for ; Wed, 18 Jan 2012 14:18:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type:content-transfer-encoding; bh=fDh4dTT/QhrE583M6qXS3PA/NWehF69wtNp/N1G0cbE=; b=mo3eiUDCzt+5Ii0AYDho2SElnQkOGvndoHQ6S1AqfBx4BGsF2dKBUGonhWRv9bUYpJ 6ZINuxJufW3l9rEUW+bKPrM8wF6C23Mpog1dDQOrdlDEZx0xMuvZGv67ezMnZNImJDlM lH/GIRXC9ub5MdaTS5fe+FV37W8GjabYcnoCs= Received: by 10.224.177.203 with SMTP id bj11mr24460380qab.37.1326925134799; Wed, 18 Jan 2012 14:18:54 -0800 (PST) Received: from localhost (wal122.wireless-pennnet.upenn.edu. [128.91.71.251]) by mx.google.com with ESMTPS id df3sm52783063qab.6.2012.01.18.14.18.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jan 2012 14:18:53 -0800 (PST) From: Aaron Ecay To: Pieter Praet , David Edmondson Subject: Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch' In-Reply-To: <87sjjdp1f1.fsf@praet.org> References: <87r4yza95m.fsf@praet.org> <1326732415-21894-1-git-send-email-pieter@praet.org> <87fwfd8h0i.fsf@praet.org> <87obu19pfo.fsf@praet.org> <87sjjdp1f1.fsf@praet.org> User-Agent: Notmuch/0.11+73~gd51b784 (http://notmuchmail.org) Emacs/24.0.92.2 (i386-apple-darwin10.8.0) Date: Wed, 18 Jan 2012 17:18:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Notmuch Mail 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: Wed, 18 Jan 2012 22:18:56 -0000 On Wed, 18 Jan 2012 14:48:02 +0100, Pieter Praet wrote: > My original intent of conserving a key(chord) [1] (which in > retrospect was a fairly pointless exercise in and of itself > [2,3]) seems to have inconspicuously morphed into an equally > questionable crusade [4] against the `cl' package. >=20 > As long there's other functions in Notmuch depending on > compile-time `cl', there's really no incentive whatsoever > to replace your perfectly fine solution. (This is not strictly related to the immediate issue of these patches, but now seems as good a time as any to discuss it.) Compile-time dependencies on =E2=80=98cl=E2=80=99 are absolutely not a prob= lem. Virtually every major elisp program depends on cl at compile time. Runtime dependencies are not allowed in code distributed with emacs because of RMS=E2=80=99s conservativism[1]. Since notmuch isn=E2=80=99t distributed with emacs and has no aspirations to ever be, the project could decide to require cl at runtime. Many elisp programs do. (A quick grep through my .emacs.d folder turns up anything.el and clojure-mode as two large/=E2=80=9Cmainstream=E2=80=9D proj= ects that do, as well as at least a dozen smaller utility files.) So many emacs users have cl loaded all the time when they are using emacs. But unless the project (i.e. us) decides explicitly =E2=80=9Cruntime cl is OK= =E2=80=9D (or perhaps =E2=80=9Cit is not=E2=80=9D), contributors will always go back and = forth over using it. To avoid patch and review churn, we ought to decide which of these we pick (and I vote for allowing runtime use.) Aaron Footnotes: [1] He specifically objects to the way that the cl package uses keyword arguments, calling it un-Elisp-like. He has resisted past efforts to merge cl functions into Elisp core, although they are slowly diffusing across the barrier. --=20 Aaron Ecay