bug#57400: 29.0.50; Support sending patches from VC directly

[Philip Kaludercic <philipk@posteo.net>]

Philip Kaludercic <philipk@posteo.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Philip Kaludercic <philipk@posteo.net>
>>> Cc: larsi@gnus.org,  57400@debbugs.gnu.org,  ane@iki.fi
>>> Date: Tue, 04 Oct 2022 07:10:15 +0000
>>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>>> >> +            (compose-mail addressee
>>> >> +                          (or (plist-get patch :subject)
>>> >> +                              (concat
>>> >> +                               "Patch for " ;guess
>>> >> +                               (file-name-nondirectory
>>> >> +                                (directory-file-name
>>> >> +                                 (vc-root-dir)))))
>>> >> +                          nil nil nil nil
>>> >> +                          `((exit-recursive-edit)))
>>> >> +            (message-goto-body)
>>> >
>>> > compose-mail doesn't necessarily invoke message.el functions, so
>>> > message-goto-body is not necessarily appropriate here.
>>> 
>>> Oh, I thought it was because `submit-emacs-patch' did the same.  Again,
>>> do you have any suggestions what else could be done to keep this
>>> generic?
>>
>> Can you ask more specific questions?  Are you looking for a generic
>> way of doing what message-goto-body does?  
>
> Kind of, I would like to have some function that would place the point
> at the beginning of the message body, no matter what MUA is used.  From
> what I see, the implicit assumption always is that a message is composed
> in a single buffer where the headers are written out at the beginning of
> the buffer, then there is some kind of to detect the end of the headers,
> followed by the body.  But what if a MUA wants to use a separate buffer
> for the headers and the body, placing them in two separate windows?
> What if the headers aren't shown at all?  If I want to handle the
> situation generically, it seems like I would have to take all the design
> decisions into consideration.

Another issue is how attachments are made:  mml-attach-* is part of Gnus
and inserts literal text that some MUAs interpret, but is this something
that all MUAs have to do?

>>                                            If so, would
>> rfc822-goto-eoh do the job?
>
> It doesn't seem to do the same, as in message-mode, it jumps to the
> beginning of the "--text follows this line--" line, not to the line
> after it.