Why does mml-attach-file put the attachment at the very end of the message...

Why does mml-attach-file put the attachment at the very end of the message...

[Marcin Borkowski]

...instead of right before the sigdashes?

If there is no particular reason, I propose a patch below.  My use case
is a function that cycles through a few possible signatures, where at
one point I delete everything after the sigdashes.

--8<---------------cut here---------------start------------->8---
diff -c --label /usr/local/share/emacs/25.0.50/lisp/gnus/mml.el.gz --label \#\<buffer\ mml.el.gz\> /tmp/jka-com2530smv /tmp/buffer-content-2530r6E
*** /usr/local/share/emacs/25.0.50/lisp/gnus/mml.el.gz
--- #<buffer mml.el.gz>
***************
*** 1374,1380 ****
       (list file type description disposition)))
    ;; If in the message header, attach at the end and leave point unchanged.
    (let ((head (unless (message-in-body-p) (point))))
!     (if head (goto-char (point-max)))
      (mml-insert-empty-tag 'part
  			  'type type
  			  ;; icicles redefines read-file-name and returns a
--- 1374,1382 ----
       (list file type description disposition)))
    ;; If in the message header, attach at the end and leave point unchanged.
    (let ((head (unless (message-in-body-p) (point))))
!     (when head
!       (goto-char (point-max))
!       (search-backward "-- \n" nil t))
      (mml-insert-empty-tag 'part
  			  'type type
  			  ;; icicles redefines read-file-name and returns a

Diff finished.  Mon Oct 26 09:29:32 2015
--8<---------------cut here---------------end--------------->8---

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Why does mml-attach-file put the attachment at the very end of the message...

[Marcin Borkowski]

Ah, small correction: I should have said "\n-- \n" instead of "-- \n",
of course.  Here it is:

--8<---------------cut here---------------start------------->8---
diff -c --label /usr/local/share/emacs/25.0.50/lisp/gnus/mml.el.gz --label \#\<buffer\ mml.el.gz\> /tmp/jka-com2530smv /tmp/buffer-content-2530r6E
*** /usr/local/share/emacs/25.0.50/lisp/gnus/mml.el.gz
--- #<buffer mml.el.gz>
***************
*** 1374,1380 ****
       (list file type description disposition)))
    ;; If in the message header, attach at the end and leave point unchanged.
    (let ((head (unless (message-in-body-p) (point))))
!     (if head (goto-char (point-max)))
      (mml-insert-empty-tag 'part
  			  'type type
  			  ;; icicles redefines read-file-name and returns a
--- 1374,1382 ----
       (list file type description disposition)))
    ;; If in the message header, attach at the end and leave point unchanged.
    (let ((head (unless (message-in-body-p) (point))))
!     (when head
!       (goto-char (point-max))
!       (search-backward "\n-- \n" nil t))
      (mml-insert-empty-tag 'part
  			  'type type
  			  ;; icicles redefines read-file-name and returns a

Diff finished.  Mon Oct 26 09:29:32 2015
--8<---------------cut here---------------end--------------->8---


On 2015-10-26, at 09:30, Marcin Borkowski <mbork@mbork.pl> wrote:

> ...instead of right before the sigdashes?
>
> If there is no particular reason, I propose a patch below.  My use case
> is a function that cycles through a few possible signatures, where at
> one point I delete everything after the sigdashes.
>
> --8<---------------cut here---------------start------------->8---
> diff -c --label /usr/local/share/emacs/25.0.50/lisp/gnus/mml.el.gz --label \#\<buffer\ mml.el.gz\> /tmp/jka-com2530smv /tmp/buffer-content-2530r6E
> *** /usr/local/share/emacs/25.0.50/lisp/gnus/mml.el.gz
> --- #<buffer mml.el.gz>
> ***************
> *** 1374,1380 ****
>        (list file type description disposition)))
>     ;; If in the message header, attach at the end and leave point unchanged.
>     (let ((head (unless (message-in-body-p) (point))))
> !     (if head (goto-char (point-max)))
>       (mml-insert-empty-tag 'part
>   			  'type type
>   			  ;; icicles redefines read-file-name and returns a
> --- 1374,1382 ----
>        (list file type description disposition)))
>     ;; If in the message header, attach at the end and leave point unchanged.
>     (let ((head (unless (message-in-body-p) (point))))
> !     (when head
> !       (goto-char (point-max))
> !       (search-backward "-- \n" nil t))
>       (mml-insert-empty-tag 'part
>   			  'type type
>   			  ;; icicles redefines read-file-name and returns a
>
> Diff finished.  Mon Oct 26 09:29:32 2015
> --8<---------------cut here---------------end--------------->8---
>
> Best,



-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Why does mml-attach-file put the attachment at the very end of the message...

[Alexis]

Marcin Borkowski <mbork@mbork.pl> writes:

> ...instead of right before the sigdashes?
>
> If there is no particular reason, I propose a patch below.  My 
> use case is a function that cycles through a few possible 
> signatures, where at one point I delete everything after the 
> sigdashes.

i never use sigdashes in emails, and prefer any attachments to be 
the very last thing in the email, i.e. after my sig.


Alexis.

Re: Why does mml-attach-file put the attachment at the very end of the message...

[Marcin Borkowski]

On 2015-10-26, at 09:51, Alexis <flexibeast@gmail.com> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> ...instead of right before the sigdashes?
>>
>> If there is no particular reason, I propose a patch below.  My 
>> use case is a function that cycles through a few possible 
>> signatures, where at one point I delete everything after the 
>> sigdashes.
>
> i never use sigdashes in emails, and prefer any attachments to be 
> the very last thing in the email, i.e. after my sig.

And in your case the proposed patch would just do it since you don't use
sigdashes, `search-backwards' would not move the point.

> Alexis.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Why does mml-attach-file put the attachment at the very end of the message...

[Alexis]

Marcin Borkowski <mbork@mbork.pl> writes:

> And in your case the proposed patch would just do it since you 
> don't use sigdashes, `search-backwards' would not move the 
> point.

That assumes i never use the sequence "\n-- \n" (or something 
similar) in the body of my email, which is not the case. i would 
prefer it if your patch made this new behaviour customisable.  (i 
don't necessarily mind what the default is, although if your 
desired behaviour becomes the default one, i would suggest it 
should be noted in NEWS)

OT, iiuc, the preference is for patches to be in unified diff 
format. (Please someone correct me if this is wrong!)


Alexis.

Re: Why does mml-attach-file put the attachment at the very end of the message...

[Katsumi Yamaoka]

On Mon, 26 Oct 2015 09:33:23 +0100, Marcin Borkowski wrote:
> !     (when head
> !       (goto-char (point-max))
> !       (search-backward "\n-- \n" nil t))

This makes the signature unseen to not a few recipients (except
Emacs users).  IOW, many mail programs aren't fully MIME compliant;
they assume MIME-parts other than the first one all not inlinable
attachments.  It's too bad, though.

Regards,

Re: Why does mml-attach-file put the attachment at the very end of the message...

[Marcin Borkowski]

On 2015-10-26, at 10:36, Katsumi Yamaoka <yamaoka@jpl.org> wrote:

> On Mon, 26 Oct 2015 09:33:23 +0100, Marcin Borkowski wrote:
>> !     (when head
>> !       (goto-char (point-max))
>> !       (search-backward "\n-- \n" nil t))
>
> This makes the signature unseen to not a few recipients (except
> Emacs users).  IOW, many mail programs aren't fully MIME compliant;
> they assume MIME-parts other than the first one all not inlinable
> attachments.  It's too bad, though.

I see.  This probably makes my suggestion unreasonable at best.

BTW, does that mean that if I inline the attachment (which I do
frequently), some people might not see anything after that?

And now I've got a question: how can I reliably find the part
responsible for the attachment (sorry, I don't know the correct term for
it) in the buffer?

> Regards,

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Why does mml-attach-file put the attachment at the very end of the message...

[Andreas Schwab]

Marcin Borkowski <mbork@mbork.pl> writes:

> And now I've got a question: how can I reliably find the part
> responsible for the attachment (sorry, I don't know the correct term for
> it) in the buffer?

If you are in the body then mml-attach-file always puts the attachment
at point.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Why does mml-attach-file put the attachment at the very end of the message...

[Marcin Borkowski]

On 2015-10-26, at 12:02, Andreas Schwab <schwab@suse.de> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> And now I've got a question: how can I reliably find the part
>> responsible for the attachment (sorry, I don't know the correct term for
>> it) in the buffer?
>
> If you are in the body then mml-attach-file always puts the attachment
> at point.

I know that from reading the source of `mml-attach-file'.  But it
doesn't help at all.  Assume that I already have an attachment
/somewhere/ in the email (never mind how it got there - probably by
means of `gnus-dired-attach').  How can I find that place?

> Andreas.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Why does mml-attach-file put the attachment at the very end of the message...

[Katsumi Yamaoka]

On Mon, 26 Oct 2015 11:37:52 +0100, Marcin Borkowski wrote:
> BTW, does that mean that if I inline the attachment (which I do
> frequently), some people might not see anything after that?

AFAIK, at least MS outlook, one of the most popular mailers,
doesn't display image/*, text/*, etc. inline even if they are
specified inline; all those are only buttonized.  People can
click and view them of course, though.

> And now I've got a question: how can I reliably find the part
> responsible for the attachment (sorry, I don't know the correct term for
> it) in the buffer?

Well, all MIME parts except for the first text part will get
attachments that aren't inlined in Windows' mail programs, I
think.

Regards,

Re: Why does mml-attach-file put the attachment at the very end of the message...

[Andreas Schwab]

Marcin Borkowski <mbork@mbork.pl> writes:

> I know that from reading the source of `mml-attach-file'.  But it
> doesn't help at all.  Assume that I already have an attachment
> /somewhere/ in the email (never mind how it got there - probably by
> means of `gnus-dired-attach').  How can I find that place?

Look for the mml tag?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

RE: Why does mml-attach-file put the attachment at the very end of the message...

[Drew Adams]

> AFAIK, at least MS outlook, one of the most popular mailers,
> doesn't display image/*, text/*, etc. inline even if they are
> specified inline; all those are only buttonized.  People can
> click and view them of course, though.

Not true.  If the image is "inserted" into the message content,
i.e., it appears inlined, as expected.  If the image file is
sent as an attachment then it does not.

There might be a setting that affects the behavior; dunno.
But this is what I see, without having changed any such
setting.

To insert an image in line, at the cursor position:

1. The message must be HTML, not plain-text.
2. Use menu Insert > Picture.

Re: Why does mml-attach-file put the attachment at the very end of the message...

[Eli Zaretskii]

> From: Alexis <flexibeast@gmail.com>
> Date: Mon, 26 Oct 2015 20:28:33 +1100
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> OT, iiuc, the preference is for patches to be in unified diff 
> format. (Please someone correct me if this is wrong!)

Some (many?) people indeed prefer that, but I don't mind any of these
two formats.  IMO, FWIW, YMMV.

Re: Why does mml-attach-file put the attachment at the very end of the message...

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> BTW, does that mean that if I inline the attachment
> (which I do frequently), some people might not see
> anything after that?
>
> And now I've got a question: how can I reliably find
> the part responsible for the attachment (sorry,
> I don't know the correct term for it) in the buffer?

This book is old (ancient) but if you are into this
kind of details it is a treasure:

    @book{internet-message,
      title      = {The Internet Message: Closing the Book with Electronic Mail},
      author     = {Marshall Rose},
      publisher  = {Prentice-Hall},
      year       = 1993,
      ISBN       = {0-13-092941-7},
    }

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Why does mml-attach-file put the attachment at the very end of the message...

[Nicolas Richard]

Marcin Borkowski <mbork@mbork.pl> writes:

> BTW, does that mean that if I inline the attachment (which I do
> frequently), some people might not see anything after that?

FWIW it happenned to me : I sent an inlined attachment then went on with
my email, and some of the recipients saw --in their client, I don't know
what it was-- a mail truncated at the place where the attachment was. Of
course this went unnoticed for a few days...

-- 
Nicolas Richard