Could you please elaborate on "how" and "why"

How:
- Do you intend to edit the raw message text (inc. headers)
- How does trojita know when to send the mail? (When the process terminates? What if the user invokes an editor that just opens a tab in an existing process? How to abort sending?)
- How to deal with corrupted messages (eg. if you removed the FROM field)? Auto-amending? Representation?
- How would you "attach" mails (basically: write multipart messages yourself and cnp hand-generated base64 encoded data there)?

Why:
Leaving the idea of manipulating headers (for whatever reason) aside: why?
The composer allows you to paste as quotes, recipient completion, auto saving, correct wrapping ...
-> What benefit do you seek in the other editor (or iow: what's improvable about the composer)?
There's a pending patch on dynamic wrapping that I seriously need to revisit ;-)

Hello Thomas, and thanks you for your quick reply.

Why this could be a good idea? There are a number of advantages about
using an external editor. For example, when using vim one has access to
modal mode navigation, spell checking and keyboard shortcuts.
Specialized text editors are powerful tools, and it is worthless to try
to add all the functionalities of an advanced editor into the editor
provided by Trojita. Therefore, I believe that may be a good idea to
edit Trojita messages using an external editor.

I expect to edit only the message body using an external editor.
Therefore, the generation of headers would be a task of Trojita.

As I said, Kmail has this feature, and it is the only I miss. The rest
of Trojita is just perfect :-). In Kmail, when one tries to write a new
message, the Kmail editor is opened and the external editor is
executed at the same time. The external editor opens a temporary file,
where the message body will be written. When the external text editor is
closed, the text from the temporary file is loaded into the Kmail
editor. Then, the user may attach files using the Kmail editor, write
the subject, the TO field, and send the message.

A video may be a better explanation
https://youtu.be/yIuD2PsJT-8

I'm writing this reply as a very happy vim user who likes the advanced features which a reasonable text editor provides. I understand that there are tens of years behind such an editor's development, and I have no intention of duplicating this in Trojita, of course. (But it would be nice to, e.g., optionally integrate with FakeVim from QtCreator :). )

I also miss mi editor's spellchecker, sure.

However, there are special rules about how an e-mail message should look like; there are conventions about how to work with quotations and how to compose format=flowed e-mails. Trojita is far from bug-free in this context, but at least it tries to preserve reasonable formatting of e-mail messages. A text e-mail body part is nowadays not just a block of text, there are some pieces of metadata which are effectively attached to each paragraph (is it flowed?, what's the level of quoting?). If we want to launch an external editor, it would have to pass these metadata back to Trojita "somewhow". One possibility is to require the editor to always produce an end result which conforms to RFC3676, but that is a very, very unreasonable expectations because someone *will* use an editor which fails to do so. Doing this correctly requires a level of domain-specific knowledge from the end user, which is a bad thing, IMHO.

(In reply to Jan Kundrát from comment #3)

> I also miss mi editor's spellchecker, sure.

http://wiki.qt.io/Spell-Checking-with-Hunspell

 
> However, there are special rules about how an e-mail message should look
> like

From the description and video, this seeks to automate
* launch "text editor™"
* write mail in "text editor™"
* copy text into mail composer
* close "text editor™"
* finally process mail in composer

The kmail implementation looks "incomplete" (re-edit?), but, though suboptimal for preserving the mail body in a conversation, the manual process cannot be "prevented" anyway.

My position would be to improve the mail composer to lower the need to use an external editor (if trojita would depend on KDE, I'd opt for simply using a kate part) and iff we integrate external editors (to improve the non-preventable manual process) to do it "better".

Shortcomings in what I saw:

- mail composer is editable while the ext. editor is up
  -> what happens on concurrent input? merge? what if the merge fails, does the user get a merge resolution request? ;-)
   => lock the composer (ie. *hide* the body editor)

- there's no real connection between the composer and the external editor window (what belongs to what)
   -> this is "fixable" on at least X11 (we turn the composer into a transient for the editor window or xembed the latter), but we'll need xlib/xcb code for this...

- user must not forget to save in the external editor before closing it (no idea how to fix that, but well, a user problem ;-)

(In reply to Thomas Lübking from comment #4)

> The kmail implementation looks "incomplete" (re-edit?), but, though
> suboptimal for preserving the mail body in a conversation, the manual
> process cannot be "prevented" anyway.

You can re-edit a message in Kmail. When the "text editor™" is closed and the message is loaded into the composer, if you try to edit the message again, the "text editor™" is opened with the message.

The same applies for conversations. When you click on the "Reply" button, the conversation is loaded into the "text editor™".

Another video showing how to re-edit, and what happens if you try to close the composer while the "text editor™" is running: https://youtu.be/k3ytViakXMg

> My position would be to improve the mail composer to lower the need to use
> an external editor (if trojita would depend on KDE, I'd opt for simply using
> a kate part) and iff we integrate external editors (to improve the
> non-preventable manual process) to do it "better".

I use vim and one of its advantages is the use of plugins to improve the user experience. Therefore, improving the mail composer would not be as close as using a "text editor™". 
Once you start using a "text editor™", going back to a simpler editor is quite difficult. I call this the "Vim Abstinence Syndrome" ;-)

> Shortcomings in what I saw:
> 
> - mail composer is editable while the ext. editor is up
>   -> what happens on concurrent input? merge? what if the merge fails, does
> the user get a merge resolution request? ;-)
>    => lock the composer (ie. *hide* the body editor)

When Kmail is configured to use a  "text editor™", the composer is blocked until the "text editor™" is closed. The message "External editor was started" appears at the bottom of the composer. Thus, concurrent input is not possible.

> - user must not forget to save in the external editor before closing it (no
> idea how to fix that, but well, a user problem ;-)

That's a user problem. Or a "text editor™" problem; it should warn the user when it is being closed.

Trojitá is no longer maintained, please switch to a maintained alternative like https://apps.kde.org/kmail2/

Sorry for the inconveniences.