[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#57400: 29.0.50; Support sending patches from VC directly
From: |
Eli Zaretskii |
Subject: |
bug#57400: 29.0.50; Support sending patches from VC directly |
Date: |
Tue, 04 Oct 2022 15:24:34 +0300 |
> From: Philip Kaludercic <philipk@posteo.net>
> Cc: larsi@gnus.org, 57400@debbugs.gnu.org, ane@iki.fi
> Date: Tue, 04 Oct 2022 10:40:23 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > 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.
Do you happen to know about such MUAs? mail-user-agent currently
supports just 4 MUAs: do any of them work like above?
We could bite the bullet and make this operation a property of
mail-user-agent, like 'composefunc' we already have (see the doc
string of define-mail-user-agent for the full list). But if
rfc822-goto-eoh can do the job, maybe it's "good enough"?
> > 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.
Well, moving one line after that, if this is the line you get to with
that function, is easy. Don't all MUAs have that line?
- bug#57400: 29.0.50; Support sending patches from VC directly, (continued)
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/03
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/10/04
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/04
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/10/04
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/04
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/04
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/10/04
- bug#57400: 29.0.50; Support sending patches from VC directly,
Eli Zaretskii <=
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/04
bug#57400: 29.0.50; Support sending patches from VC directly, Antoine Kalmbach, 2022/10/05
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/05
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/05
- bug#57400: 29.0.50; Support sending patches from VC directly, Lars Ingebrigtsen, 2022/10/05
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/05
- bug#57400: 29.0.50; Support sending patches from VC directly, Lars Ingebrigtsen, 2022/10/05
- bug#57400: 29.0.50; Support sending patches from VC directly, Robert Pluim, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Robert Pluim, 2022/10/06