user/dev discussion of public-inbox itself
 help / color / mirror / code / Atom feed
From: Eric Wong <e@80x24.org>
To: Kyle Meyer <kyle@kyleam.com>
Cc: meta@public-inbox.org
Subject: Re: more considerations in UI/UX...
Date: Wed, 23 Dec 2020 09:47:44 +0000	[thread overview]
Message-ID: <20201223094744.GA30957@dcvr> (raw)
In-Reply-To: <87ft3xgjse.fsf@kyleam.com>

Kyle Meyer <kyle@kyleam.com> 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.

  reply	other threads:[~2020-12-23  9:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-15 11:47 [PATCH/RFC 0/7] lei - Local Email Interface skeleton Eric Wong
2020-12-15 11:47 ` [PATCH 1/7] daemon: support --daemonize without Net::Server::Daemonize Eric Wong
2020-12-15 11:47 ` [PATCH 2/7] daemon: simplify fork() failure checks Eric Wong
2020-12-15 11:47 ` [RFC 3/7] lei: FD-passing and IPC basics Eric Wong
2020-12-15 11:47 ` [RFC 4/7] lei: proposed command-listing and options Eric Wong
2020-12-26 11:26   ` "extinbox" term - was: [RFC 4/7] lei: proposed command-listing Eric Wong
2020-12-28 15:29     ` Kyle Meyer
2020-12-28 21:55       ` Eric Wong
2020-12-29  3:01         ` Kyle Meyer
2020-12-15 11:47 ` [RFC 5/7] lei_store: local storage for Local Email Interface Eric Wong
2020-12-15 11:47 ` [RFC 6/7] tests: more common JSON module loading Eric Wong
2020-12-15 11:47 ` [RFC 7/7] lei: use spawn (vfork + execve) for lazy start Eric Wong
2020-12-15 12:05 ` more considerations in UI/UX Eric Wong
2020-12-23  5:42   ` Kyle Meyer
2020-12-23  9:47     ` Eric Wong [this message]
2020-12-23 15:49       ` Kyle Meyer
2020-12-26 11:13     ` [RFC] lei: rename proposed "query" command to "q", add JSON output Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://public-inbox.org/README

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201223094744.GA30957@dcvr \
    --to=e@80x24.org \
    --cc=kyle@kyleam.com \
    --cc=meta@public-inbox.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/public-inbox.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).