From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id aM37Nz3TBWDUMQAA0tVLHw (envelope-from ) for ; Mon, 18 Jan 2021 18:28:13 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 8OS/Mz3TBWBVMAAAbx9fmQ (envelope-from ) for ; Mon, 18 Jan 2021 18:28:13 +0000 Received: from mail.notmuchmail.org (nmbug.tethera.net [IPv6:2607:5300:201:3100::1657]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (2048 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 4CDB29402B3 for ; Mon, 18 Jan 2021 18:28:13 +0000 (UTC) Received: from nmbug.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id 9054D29DE5; Mon, 18 Jan 2021 13:28:07 -0500 (EST) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by mail.notmuchmail.org (Postfix) with ESMTP id A09B01FF9D for ; Mon, 18 Jan 2021 13:28:04 -0500 (EST) Received: by fethera.tethera.net (Postfix, from userid 1001) id 395A25FF47; Mon, 18 Jan 2021 13:28:04 -0500 (EST) Received: (nullmailer pid 1703735 invoked by uid 1000); Mon, 18 Jan 2021 18:28:02 -0000 From: David Bremner To: David Edmondson , notmuch@notmuchmail.org Subject: Re: [RFC PATCH] show: Add support for -format=raw -body=false In-Reply-To: References: <20210117183710.29850-1-dme@dme.org> <87mtx6gn97.fsf@tethera.net> Date: Mon, 18 Jan 2021 14:28:02 -0400 Message-ID: <87eeiigkwd.fsf@tethera.net> MIME-Version: 1.0 Message-ID-Hash: UC4V25Q6R5VOQ4UQ6NRNVYVYH4QJQGEK X-Message-ID-Hash: UC4V25Q6R5VOQ4UQ6NRNVYVYH4QJQGEK X-MailFrom: david@tethera.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.1 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.90 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 2607:5300:201:3100::1657 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Queue-Id: 4CDB29402B3 X-Spam-Score: -1.90 X-Migadu-Scanner: scn0.migadu.com X-TUID: XI2B2kTQLrAF David Edmondson writes: > On Monday, 2021-01-18 at 13:37:08 -04, David Bremner wrote: > >> David Edmondson writes: >> >>> Similar to other formats, allow the body to be omitted when outputting >>> raw messages. >>> >>> This can be used by UI code to get the full headers of a message >>> without the need to consume the body, which may be large. >> >> I guess I'm a bit confused why this is for "raw" format, and not >> "text". Are you proposing that we have two ad-hoc output formats for >> consuming by scripts and other tools that don't want JSON or SEXP? > > "text" is a strange archaic output format, the rationale for which seems > lost in time :-) Yeah, at one time I wanted to get rid of it, but inter alia the vim bindings use(d?) it. > I wanted to get the Autocrypt or Face headers, so ended up using > "--format=raw", but then end up with the entire message, which can be > megabytes large. With the emacs UI, that means pulling all of that data > into a buffer, just to ignore it. Ok thanks for explaining the use case. > Now, it would be nice to be able to say something like... > > notmuch show --format=sexp --body=false \ > --headers=received-by,face,x-face \ > id:foo > > ...to get some extra headers in the sexp output, but I didn't look at it > yet. There was a series at id:20191122230730.35712-2-johan.parin@gmail.com that got stalled due to (I think) some issues with passing around configuration information. > > The proposed change seems like a simple, obvious improvement that is > entirely in-line with the existing interface and implementation. Is > there any reason not to do it? I'm just nervous about more legacy formats. I think we will get the arbitrary headers thing working eventually, but I can see it might take some time.