Re: JSON field names in terminal/pager output

[Eric Wong <e@80x24.org>]

Kyle Meyer <kyle@kyleam.com> wrote:
> Eric Wong writes:
> 
> > Are "f", "s", "t", "c" acceptable field names to show in JSON
> > output?  (instead of from/subject/to/cc)
> 
> In my view they are, and, as you mention next, I like that they align
> with the search prefixes.
> 
> > Anyways, the current JSON output looks something like the
> > following, comments inline
> >
> > [{
> [...]
> 
> Nice.

Btw, I remember there's several JSON streaming formats.  I think
"JSONL" aka "NDJSON" aka "LDJSON" is the best for interopability
with tools like jq(1) and will be the default format when stdout
is to a pipe or regular file.

"Concatenated JSON" may be nice for pretty-printing

<RS>-delimited JSON is gross, but there's an RFC behind it...

cf.  https://en.wikipedia.org/wiki/JSON_streaming

> 
> >   "references": [
> >     "<20210105090437.22801-1-e@80x24.org>",
> >     "<20210105090437.22801-5-e@80x24.org>"
> >   ],
> >
> >   # we don't actually support searching on rereference, yet;
> >   # not sure if it's needed since we already do thread # expansion
> 
> Is "thread # expansion" the "num -> tid -> nums" mapping done by Over's
> expand_thread()?  And, from the CLI, that will be triggered by
> `thread|t', right?

Yup.  It works well for single sources (and even a single
extindex), but not when combinining multiple inboxes/extindices
since THREADID ({tid}) is per-inbox/extindex.  So extra dedupe
work needs to be done...

So searching across externals needs to be parallelized.  I'm
thinking SOCK_SEQPACKET Unix sockets is ideal for local
externals and hope it's usable in the modern *BSDs.

And SIGPIPE on pager exit needs to get delivered in a timely
fashion, too... (yes, little things like that really bug me :x)