Re: mutt/2038: empty filename parameter to $editor for HTML
The following reply was made to PR mutt/2038; it has been noted by GNATS.
From: TAKAHASHI Tamotsu <ttakah@xxxxxxxxxxxxxxxxx>
To: Mutt GNATS <bug-any@xxxxxxxxxxxxx>
Cc:
Subject: Re: mutt/2038: empty filename parameter to $editor for HTML
Date: Sun, 14 Aug 2005 08:38:08 +0900
* Sat Aug 13 2005 Alain Bench <veronatif@xxxxxxx>
> >Description:
>
> In $content_type="text/html" mode, and in the absence of a specific edit
> command for text/html in mailcap, Mutt fallbacks to $editor to compose an
> HTML mail. Bug: The temporary filename parameter given to $editor is the
> empty string. More info in July 2005 mutt-users thread "editor and
> content_type conflict?" beginning at msgid
> <20050704000403.GA26887@xxxxxxxxxxxxx>. Reporter Gergely was too lazy to
> compose a real bugreport.
The bug is in attach.c here:
: int mutt_edit_attachment (BODY *a)
: {
...
: char newfile[_POSIX_PATH_MAX] = "";
...
: if (rfc1524_mailcap_lookup (a, type, entry, M_EDIT))
: {
: if (entry->editcommand)
: {
: strfcpy (command, entry->editcommand, sizeof (command));
: if (rfc1524_expand_filename (entry->nametemplate,
: a->filename, newfile, sizeof (newfile)))
...
: }
: }
: else if (a->type == TYPETEXT)
: {
: /* On text, default to editor */
: mutt_edit_file (NONULL (Editor), newfile);
: }
: else
...
newfile is still "" when (!rfc1524_mailcap_lookup(...)) and
(a->type==TYPETEXT).
I think we should use a->filename if available, mktemp if not.
> Bug2: After composing a first text/html mail, the variable $content_type
> changes itself to "text".
Uggh, mutt_parse_content_type (in parse.c) has to have
(const char *, BODY *) type instead of (char *, BODY *),
and safe_strdup the char*.
Or, we should use safe_strdup'ed ContentType instead of
raw ContentType within ci_send_message (in send.c).
- mutt_parse_content_type (ContentType, msg->content);
+ char *ctype = safe_strdup (ContentType);
+ mutt_parse_content_type (ctype, msg->content);
--
tamo