> {{{
> It's in the description of the bug that to get it one doesn't leave
> the blank line.
>
> And it is surely a bug. Of course an RFC requires that in the
> *finished product* there be a blank line between the headers and the
> body. But when one is in one's editor, with $edit headers on, that is
> *not* the finished product. E.g., Not all the headers make it into
I have to disagree.
Instead of starting from the scratch...
* Compose with "unset edit_headers"; edit the message; finish editing.
* You are about to sent it so that the whole thing will become "finished
product" (your words).
* You change your mind and type ":set edit_headers" and edit the
message.
* You will see that you have a "blank line" between headers and body.
- Could you disregard this and start editing the /message/ from the
blank line?
Remember, you have introduced "finished vs unfinished product" into
mutt syntax; there is no such type of message text in any part of mutt
source or manual /and/ not in any RFC document.
Now, lets go back to your /way/ of composing...
* You have already set "set edit_headers" in your .muttrc and you don't
have any variables that create body text (e.g. signatures)
* You type "mutt [email protected]" and directly start composing
* Even though you observe that mutt /intentionally/ added a blank line
(RFC 2822->RFC 5322) at the end of headers you /wish/ to start editing
on that very blank line!
- So, how could you judge that this /way/ of composing habit is a bug?
Why don't just press enter and /then/ start typing on that blank line?
> the editor. Also, there may yet be quoted-printable or format-flowed
> or other encoding to be applied by mutt once the editor is exited.
> Also, attachments (and their framing text) don't appear in the editor.
>
> It's mutt's job to transform what's in the editor into the finished
> product, or a piece of the finished product, and so it's mutt's job to
> insert the blank line if necessary.
As is obvious from above, mutt does its job very well that in
set_headers mode, mutt
a) gives a boundary between headers and body
b) rewrites the headers with human readable format when it leaves
composing:
(<Field name>:<Field body> --> <Field name>:<Space><Field body>)
c) detects potential <Field names> and treats those lines as header
(i.e. lines starting with <US-ASCII characters[33-126]> + ':')
d) rewrites FWS (Folding White Space); i.e. while still inside the
headers, if a line start with FWS, add that line to the last header
line.
e) and probably many more header manipulation...
While doing these mutt might detect "non-header-line" where it marks
that line as start-of-body. This is where your habit fails:
You type "<ascii>:<non-ascii>" (see 'b' and 'c' above)
instead of typing "<enter><ascii>:<non-ascii>"
Therefore it is NOT mutt's job to prepare itself for every habit of
composing but it is the responsibility of user to adapt himself/herself
to standards.
And about your suggestion:
if the line starts with "<ascii>:<space><any text>" -> HEADER
if the line starts with "<ascii>:<any text>" -> BODY
You really have to read this
https://tools.ietf.org/html/rfc5322#page-8
... A field body may be composed of printable US-ASCII
characters as well as the space (SP, ASCII value 32) and
horizontal tab (HTAB, ASCII value 9) characters (together known
as the white space characters, WSP).
i.e. your suggestion still creates a header line; and please at this
point lets not go back to "finished vs. unfinished product".
To mutt-dev:
I suggest a minor change in the manual.txt
(sorry I haven't built 1.5.22 yet):
Section 6.1
...
After getting recipients for new messages, forwards or replies,
Mutt will then automatically start your $editor on the message
body. If the $edit_headers variable is set, the headers will be
- at the top of the message in your editor.
+ at the top of the message in your editor and one should start
+ composing the message on a new line after the blank line at the
+ end of headers.
cheers,
Sinan.
> }}}
