From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id E86E91F4B4; Wed, 23 Dec 2020 09:47:44 +0000 (UTC) Date: Wed, 23 Dec 2020 09:47:44 +0000 From: Eric Wong To: Kyle Meyer Cc: meta@public-inbox.org Subject: Re: more considerations in UI/UX... Message-ID: <20201223094744.GA30957@dcvr> References: <20201215120544.GA8927@dcvr> <87ft3xgjse.fsf@kyleam.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87ft3xgjse.fsf@kyleam.com> List-Id: Kyle Meyer wrote: > I'm still digesting this (and the follow-up thread), but all of this > looks really great and exciting. Great to know; it's been floating in the back of my mind for a few years. > Eric Wong writes: > > > * consistency/familiarity - steal ideas from other software > > built-in help, auto-pager/color, > > `q=' is stolen from web search engines, > > search term prefixes (f:, t:, ...) stolen from mairix > > > > Stuff I don't know but know other users use: Emacs / Gnus > > > > notmuch - I've only read the code since Maildir can't scale > > I use Gnus for NNTP (a mixture of public-inbox and Gmane stuff). In the > context of lei, I'm not sure there's a whole lot to borrow from Gnus. > > I also use notmuch (via its Emacs interface). As someone that will > probably write an Emacs interface for lei (as part of piem), an aspect > of notmuch that I'd be grateful to see in lei is a structured output > format for easier parsing and for conveying the thread layout. `notmuch > show' and `notmuch search' have json and S-expressions. I wouldn't > expect to see S-expressions coming out of lei :), but perhaps json would > be on the table for `lei show' and `lei query' given that it's planned > for $ls_format. Yes, leaving JSON out of "lei q(uery)" output was an oversight, and probably "show", too... I'm also wondering if there'll need to be multiple flavors of JSON output for compatibility with existing tools: "nm-json", "foo-json", "bar-json", etc.. (And JMAP support will be developed in parallel, too, so that'll need to be taken into account). S-expressions will probably have to wait a bit (I don't know Lisp at all :x), there's already a lot on the plate :) > Just for reference, here's an example of (heavily edited) `notmuch show' > output for this thread: > > $ notmuch show --entire-thread=true --body=false --format=json \ > id:20201215120544.GA8927@dcvr > [[[ > {"id": "20201215114722.27400-1-e@80x24.org", > "match": false, > "excluded": false, > "filename": ["..."], "filename" could be strange for us to implement, I suppose we could maintain a stable filename at /path/to/some/Maildir/cur/$GIT_OBJECT_ID:2, if needed. >From what I'm used to as a mairix user, it blows away the output folder every search (unless --augment is used); but consumers of nm-compatible JSON would have different lifetime expectations of the filename... > "timestamp": 1608032835, > "date_relative": "December 15", > "tags": [], > "crypto": {}, There'll need to be some configurable MIME type => text conversion mapping to translate encrypted emails, HTML parts, PDFs, and other random formats into something Xapian can index. Xapian omega already has something we can steal/copy from, I think. This should be configurable for public stuff, too. The rest of the output looks reasonable to pull out of over.sqlite3 and "tags" from Xapian. Thanks for the feedback.