Re: [PATCH] cli/show: add --format=pretty

2021-07-05 Thread Hannu Hartikainen
Hi!

Thanks for starting discussion on the matter. Do feel free to tell me if
I have the completely wrong idea about project goals.

On Sun, 04 Jul 2021 11:38:45 -0300, David Bremner  wrote:
> This is not really directed at Hannu, but at the notmuch community. As
> you can imagine I'm not super enthusiastic an every growing number of
> output formats to maintain.

I can appreciate that. I've maintained open source software before and I
know people come up with the weirdest feature requests that simply don't
fit the scenario I'm building the software for. If this text format that
I personally like to use isn't good for the project, it definitely
should not be merged.

What do you see as the mission statement for notmuch-cli? I'd like to
make it ergonomic enough to be usable without a MUA, and it's really
close already. But if notmuch-cli is meant to be something completely
different I might just have my own set of patches or consider starting
my own project.

> One thing the old format did not do, but a generically useful on the
> command-line format probably should is deal with signature verification
> and decryption. There is obviously potential for visual spoofing, but
> maybe color can help.

I'm pretty sure you can embed ANSI escapes in email and
they'll be displayed by `notmuch show` as color in a typical terminal.
Not sure if anyone should be worried about attacks specifically against
notmuch users, though.

> In my experience, notmuch show --format=raw works pretty well
> for this. There was an issue with encoded line endings but that is fixed
> in git 2.32. What advantage does this new format bring for patches?

--format=pretty is not any better than --format=raw for use with git-am
but the point is that it's as good. I have the shell alias ns="notmuch
show --format=pretty" and I can use something like `ns tag:unread` for
reading and `ns id:some-id | git am` for applying patches. I personally
really, really like simple things that work for multiple purposes.

For human consumption the pretty format is nicer than the raw format,
and it also supports showing multiple messages.

Hannu
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: bug#49380: 27.1; is mm-inline-message supported outside Gnus?

2021-07-05 Thread Lars Ingebrigtsen
David Bremner  writes:

> I should have been more precise. I'm calling it indirectly via
> mm-display-part, which is useful in the case where someone attaches a
> message/rfc822 part to their message. In principle notmuch can (and in
> the general case does) render the part directly, but in certain odd
> fall-back cases it is handy to give a visual representation of the part
> in the buffer without parsing etc.. ourselves.  So the user does have a
> mail reader, namely notmuch. In fact I can almost make it work by
> forcing the buffer back into notmuch-show-mode after calling
> mm-display-part, but that has some side-effects I'd prefer to avoid.

Yes, that was what I was thinking about -- the rendered embedded message
can't be easily interacted with without the mail reader being able to
hook into the rendering.  I mean, it's a kinda semi-recursive thing: You
want to be able to use (some of) the mail reader's commands to respond
to the embedded message.  Which is why `mm-inline-message' calls the
Gnus functions here.

But perhaps the function should be rewritten to call a (say)
`mm-inline-message-setup-function', bound by the caller?  Then both Gnus
and notmuch could use the function.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org