unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
* Emacs notmuch extracts text attachments as if they had Windows (CRLF) encoding
@ 2021-10-13 13:54 Martin Jambor
  2021-10-14 12:36 ` Tomi Ollila
  0 siblings, 1 reply; 3+ messages in thread
From: Martin Jambor @ 2021-10-13 13:54 UTC (permalink / raw)
  To: notmuch

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

Hi,

I have stumbled upon strange behavior of emacs-notmuch.  When I extract
(some?) plain text attachments into files using notmuch-show-save-part
(by pressing ".s"), the file they end up in has Windows encoding of line
ends (CRLF) even though both the machine used to send and receive the
email are Linux ones.

I can reproduce the issue with the attached example email.  Emacs
notmuch extracts the attachment into a windows encoding file while mutt
or metamail does not.

Can anyone else reproduce this behavior?  Any ideas how to fix it?

Thanks a lot,

Martin




[-- Attachment #2: 1633684554.29424_1.virgil.gz --]
[-- Type: application/x-gzip, Size: 1805 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Emacs notmuch extracts text attachments as if they had Windows (CRLF) encoding
  2021-10-13 13:54 Emacs notmuch extracts text attachments as if they had Windows (CRLF) encoding Martin Jambor
@ 2021-10-14 12:36 ` Tomi Ollila
  2021-10-14 15:35   ` Martin Jambor
  0 siblings, 1 reply; 3+ messages in thread
From: Tomi Ollila @ 2021-10-14 12:36 UTC (permalink / raw)
  To: Martin Jambor, notmuch

On Wed, Oct 13 2021, Martin Jambor wrote:

> Hi,
>
> I have stumbled upon strange behavior of emacs-notmuch.  When I extract
> (some?) plain text attachments into files using notmuch-show-save-part
> (by pressing ".s"), the file they end up in has Windows encoding of line
> ends (CRLF) even though both the machine used to send and receive the
> email are Linux ones.
>
> I can reproduce the issue with the attached example email.  Emacs
> notmuch extracts the attachment into a windows encoding file while mutt
> or metamail does not.
>
> Can anyone else reproduce this behavior?  Any ideas how to fix it?

Are you talking about this attachment in the gzipped email content:

  ---1609908220-525021627-1633684545=:5930
  Content-Type: text/plain; charset=US-ASCII; name=status
  Content-Transfer-Encoding: BASE64
  Content-Description: test
  Content-Disposition: attachment; filename=status

  U3RhdHVzDQo9PT09PT0NCg0KVGhlIEdDQyBkZXZlbG9wbWVudCBicmFuY2gg
  ...
  NTgzMS5odG1sDQo=

  ---1609908220-525021627-1633684545=:5930--

I manually extracted the BASE64 content, it does have the 
CRLF line endings...

>
> Thanks a lot,
>
> Martin

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Emacs notmuch extracts text attachments as if they had Windows (CRLF) encoding
  2021-10-14 12:36 ` Tomi Ollila
@ 2021-10-14 15:35   ` Martin Jambor
  0 siblings, 0 replies; 3+ messages in thread
From: Martin Jambor @ 2021-10-14 15:35 UTC (permalink / raw)
  To: Tomi Ollila, notmuch

Hi,

On Thu, Oct 14 2021, Tomi Ollila wrote:
> On Wed, Oct 13 2021, Martin Jambor wrote:
>
>> Hi,
>>
>> I have stumbled upon strange behavior of emacs-notmuch.  When I extract
>> (some?) plain text attachments into files using notmuch-show-save-part
>> (by pressing ".s"), the file they end up in has Windows encoding of line
>> ends (CRLF) even though both the machine used to send and receive the
>> email are Linux ones.
>>
>> I can reproduce the issue with the attached example email.  Emacs
>> notmuch extracts the attachment into a windows encoding file while mutt
>> or metamail does not.
>>
>> Can anyone else reproduce this behavior?  Any ideas how to fix it?
>
> Are you talking about this attachment in the gzipped email content:
>
>   ---1609908220-525021627-1633684545=:5930
>   Content-Type: text/plain; charset=US-ASCII; name=status
>   Content-Transfer-Encoding: BASE64
>   Content-Description: test
>   Content-Disposition: attachment; filename=status
>
>   U3RhdHVzDQo9PT09PT0NCg0KVGhlIEdDQyBkZXZlbG9wbWVudCBicmFuY2gg
>   ...
>   NTgzMS5odG1sDQo=
>
>   ---1609908220-525021627-1633684545=:5930--
>
> I manually extracted the BASE64 content, it does have the 
> CRLF line endings...
>

Thanks for looking into it.  I guess that explains it then.  Apparently
the behavior of mutt (and possibly other email clients) is to convert
the format to the local one. I did not expect metamail to do that,
though.

Thanks again,

Martin

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-10-14 15:35 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-13 13:54 Emacs notmuch extracts text attachments as if they had Windows (CRLF) encoding Martin Jambor
2021-10-14 12:36 ` Tomi Ollila
2021-10-14 15:35   ` Martin Jambor

Code repositories for project(s) associated with this inbox:

	notmuch.git.git (no URL configured)

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).