Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 592496DE0130 for ; Tue, 7 Jun 2016 03:28:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=-0.000, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNg-MgxmGQDZ for ; Tue, 7 Jun 2016 03:28:44 -0700 (PDT) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id D6E266DE00DA for ; Tue, 7 Jun 2016 03:28:43 -0700 (PDT) Received: from remotemail by fethera.tethera.net with local (Exim 4.84) (envelope-from ) id 1bAEFJ-0006Dk-7q; Tue, 07 Jun 2016 06:28:29 -0400 Received: (nullmailer pid 16855 invoked by uid 1000); Tue, 07 Jun 2016 10:28:40 -0000 From: David Bremner To: Sanjoy Mahajan , Allan Streib , notmuch@notmuchmail.org Subject: Re: Bug/Issue: References header doesn't wrap in emacs package In-Reply-To: <87d1ntg1a2.fsf@insight.mit.edu> References: <87612qwh04.fsf@viking.dsc.soic.indiana.edu> <87si5t1nhu.fsf@zancas.localnet> <878u7k21d8.fsf@zancas.localnet> <87d1ntg1a2.fsf@insight.mit.edu> User-Agent: Notmuch/0.22+28~gb9bf3f4 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 07 Jun 2016 07:28:40 -0300 Message-ID: <87vb1l9tt3.fsf@zancas.localnet> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.20 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, 07 Jun 2016 10:28:52 -0000 Sanjoy Mahajan writes: > I'm not sure whether fixing it in emacs is right. The command 'notmuch > reply' is itself (with the sexp or json formats) generating the too-long > References: header. Shouldn't it generate an RFC-compliant message? > > Or should the json/sexp formats remain agnostic about line length, > because wrapping doesn't make sense with key/value pairs? In that case, > I agree that message-mode should fix any long lines. For me the main issue is that the references header is editable by the user before sending. So some input sanitization is needed at the sending stage. d