Re: rendering and generating text/markdown parts

[Dylan Baker]

Quoting Daniel Kahn Gillmor (2017-08-11 16:05:56)
> On Fri 2017-08-11 15:02:44 -0700, Dylan Baker wrote:
> 
> > Natively no. I have a fairly minor patch to alot that would make it work if 
> > the
> > type was text/markdown instead of text/plain.
> 
> huh, i tried to set Content-Type: text/markdown in emacs mml-mode by
> just fiddling with the header but mml apparently believed that it knew
> better than i did what Content-Type header to send and sent out
> text/plain anyway :/
> 
> > I have another patch that makes this render correctly as markdown, but it 
> > breaks
> > lots of other text/plain emails that use characters in a way that they look 
> > like
> > markdown to cmark, but aren't actually markdown.
> 
> yeah, i agree we should *not* try to apply these filters to anything not
> marked explicitly as text/markdown.
> 
> > I think if we're going to have a message format we should use text/markdown 
> > or
> > text/commonmark, or text/x-(markdown|commonmark) rather than text/plain as 
> > the
> > format. While it's safe to read markdown as plain text (it was originally 
> > used
> > that way anyway), it's not safe to assume that all text is valid markdown.

Someone on LWN noted that "x-" has gone out of style (officially with an RFC and
everything), so I think "text/commonmark", to distinguish it from other flavors
of markdown.

> 
> Absolutely agreed.
> 
> > elinks with "-dump-color-mode 1" did a pretty good job of formatting the 
> > html that
> > came out of cmark. I've attached that if anyone wants to see it.
> 
> Interesting, it does look plausible, though i confess i don't like the
> idea of needing a two-stage pipeline. seems like a lot of attack surface
> and moving parts :/
> 
>  --dkg

cmark does have a mode to disable a bunch of "dangerous" stuff, like javascript
and css, and some other things. I think it would be better if there was native
support to avoid the multipart pipeline.

For alot, there is a python library for common mark I haven't looked at too
closely, but it's ported from JavaScript, and libraries that are ports from
other languages usually feel clunky. I'm hoping to be pleasantly surprised,
otherwise I may look into writing python bindings for the C library.

For emacs, it would probably mean writing a parser in elisp.

Dylan


signature.asc
Description: signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: rendering and generating text/markdown parts

[Daniel Kahn Gillmor]

On Fri 2017-08-11 15:02:44 -0700, Dylan Baker wrote:

> Natively no. I have a fairly minor patch to alot that would make it work if 
> the
> type was text/markdown instead of text/plain.

huh, i tried to set Content-Type: text/markdown in emacs mml-mode by
just fiddling with the header but mml apparently believed that it knew
better than i did what Content-Type header to send and sent out
text/plain anyway :/

> I have another patch that makes this render correctly as markdown, but it 
> breaks
> lots of other text/plain emails that use characters in a way that they look 
> like
> markdown to cmark, but aren't actually markdown.

yeah, i agree we should *not* try to apply these filters to anything not
marked explicitly as text/markdown.

> I think if we're going to have a message format we should use text/markdown or
> text/commonmark, or text/x-(markdown|commonmark) rather than text/plain as the
> format. While it's safe to read markdown as plain text (it was originally used
> that way anyway), it's not safe to assume that all text is valid markdown.

Absolutely agreed.

> elinks with "-dump-color-mode 1" did a pretty good job of formatting the html 
> that
> came out of cmark. I've attached that if anyone wants to see it.

Interesting, it does look plausible, though i confess i don't like the
idea of needing a two-stage pipeline. seems like a lot of attack surface
and moving parts :/

 --dkg


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: rendering and generating text/markdown parts

[Dylan Baker]

One of the alot devs here,

Natively no. I have a fairly minor patch to alot that would make it work if the
type was text/markdown instead of text/plain.

I have another patch that makes this render correctly as markdown, but it breaks
lots of other text/plain emails that use characters in a way that they look like
markdown to cmark, but aren't actually markdown.

I think if we're going to have a message format we should use text/markdown or
text/commonmark, or text/x-(markdown|commonmark) rather than text/plain as the
format. While it's safe to read markdown as plain text (it was originally used
that way anyway), it's not safe to assume that all text is valid markdown.

elinks with "-dump-color-mode 1" did a pretty good job of formatting the html 
that
came out of cmark. I've attached that if anyone wants to see it.

Dylan

Quoting Daniel Kahn Gillmor (2017-08-10 21:41:52)
> Using `Content-Type: text/markdown`
> ---
> 
> [Over on LWN, some discussion came up about rendering and generating
> text/markdown variants of e-mails](https://lwn.net/Articles/730277/)
> 
> This is similar to (but maybe simpler than) [a proposal that was
> discussed on the alot bug tracker earlier this
> year](https://github.com/pazz/alot/issues/1051).
> 
> I thought i'd drop this mail as a marker for the start of a longer
> discussion if anyone wants to try to take it further.
> 
> Next Steps
> --
> 
> I think this mail is (hopefully) actually composed correctly as
> text/markdown.
> 
> Does anyone's MUA render it properly?  Anyone want to post screenshots
> or other renderings?
> 
> Anyone have suggestions about message composition in markdown?
> 
>--dkg
> 
Using Content-Type: text/markdown 
  
 
   
   [1]Over on LWN, some discussion came up about rendering and 
generating   
   text/markdown variants of e-mails   
 
 
   
   This is similar to (but maybe simpler than) [2]a 
proposal that was   
   discussed on the alot bug tracker earlier this 
year. 
 
   
   I thought i'd drop this mail as a marker for the start of a longer
   
   discussion if anyone wants to try to take it further. 
   
 
   
Next Steps   
   
 
   
   I think this mail is (hopefully) actually composed correctly as   
   
   text/markdown.
   
 
   
   Does anyone's MUA render it properly? Anyone want to post screenshots 
or 
   other renderings? 
   
 
   
   Anyone have suggestions about message composition in markdown?
   
 
   
--dkg
   

References

   Visible links
   1. https://lwn.net/Articles/730277/
   2. https://github.com/pazz/alot/issues/1051


signature.asc
Description: signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch search does not work with search term 'id:'

[David Bremner]

Jörg Volbers  writes:


> This is the ID which I am using for testing:
>
> E5-a1wt6bgr-elaine/2/42589-dc960...@nlsender05.ui-portal.com
>
Can you try

NOTMUCH_DEBUG_QUERY=y notmuch search 
id:E5-a1wt6bgr-elaine/2/42589-dc960...@nlsender05.ui-portal.com

and report the output after "Final query is:"

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch search does not work with search term 'id:'

[Jörg Volbers]

Quoting the argument does not change anyting -- which makes sense, 
since searching for the id does work well when using "notmuch show 
--format=raw". So it's not a quoting issue.


BTW, the error also shows up if I just omit the option 
"format=raw" in notmuch show.


This is the ID which I am using for testing:

E5-a1wt6bgr-elaine/2/42589-dc960...@nlsender05.ui-portal.com

Jörg


Tomi Ollila  writes:

On Fri, Aug 11 2017, Jörg Volbers wrote: 

Hello, 

I have problems searching for a message by its id. 

If I call notmuch-show, everything works fine; actually this is 
used by the emacs frontend: 

'notmuch show --format=raw id:<.>' 

If I try to search for this mail with notmuch-search, I get no 
result: 

notmuch search -- id:<> 

Any ideas? 


put search terms inside single quotes. i.e. notmuch search -- 
'id:<>' 

Tomi 



Best, Jörg 

--  http://www.joergvolbers.de 
https://fu-berlin.academia.edu/jvolbers 


--
http://www.joergvolbers.de
https://fu-berlin.academia.edu/jvolbers


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch search does not work with search term 'id:'

[Tomi Ollila]

On Fri, Aug 11 2017, Jörg Volbers wrote:

> Hello,
>
> I have problems searching for a message by its id.
>
> If I call notmuch-show, everything works fine; actually this is 
> used by the emacs frontend:
>
> 'notmuch show --format=raw id:<.>'
>
> If I try to search for this mail with notmuch-search, I get no 
> result:
>
> notmuch search -- id:<>
>
> Any ideas?

put search terms inside single quotes. i.e. notmuch search -- 'id:<>'

Tomi

>
> Best,
> Jörg
>
> -- 
> http://www.joergvolbers.de
> https://fu-berlin.academia.edu/jvolbers
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

notmuch search does not work with search term 'id:'

[Jörg Volbers]

Hello,

I have problems searching for a message by its id.

If I call notmuch-show, everything works fine; actually this is 
used by the emacs frontend:


'notmuch show --format=raw id:<.>'

If I try to search for this mail with notmuch-search, I get no 
result:


notmuch search -- id:<>

Any ideas?

Best,
Jörg

--
http://www.joergvolbers.de
https://fu-berlin.academia.edu/jvolbers


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: associating a property with a subpart of a message

[Daniel Kahn Gillmor]

On Tue 2017-08-08 14:02:56 -0400, David Bremner wrote:
> A hybrid option would be to use a hash of the file + 1.2.1.1. address
> scheme. My thinking here is a bit vague, but I can imagine such has hash
> being useful either for content addressible mailstore, or for
> disambiguating message-id collisions.

hm, interesting.  That would mean that you'd basically never get to
confidently reuse properties (because every copy of a mail you get
likely differs by some received headers), whereas for some normal mails
where you get multiple copies if you were just hashing the part then
you'd get the same thing.  otoh, if you're going to hash a part, that
raises the question of whether you're hashing the headers as well as the
body of that part, and its possible that those headers are being
rewritten someplace.

I suppose the other approach would be to just opportunistically try the
cached data as long as the message-id is the same thing, though.

is there an easy way to get the hash of the file that contains the
message from notmuch automagically?  do we need to worry about mbox
files as well?

I welcome any other ideas or suggestions!

  --dkg


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch