On Tue, Aug 30, 2016 at 04:34:37PM -0700, [email protected] wrote:
> OPS | 3 +
> compose.c | 165
> ++++++++++++++++++++++++++++++++++++++++++++++++++++
> doc/manual.xml.head | 17 +++++
> functions.h | 3 +
> 4 files changed, 188 insertions(+), 0 deletions(-)
>
>
> # HG changeset patch
> # User David Champion <[email protected]>
> # Date 1472600048 25200
> # Tue Aug 30 16:34:08 2016 -0700
> # Node ID a347a5b31a5a032d4b3753045c9fc1a73f6023f8
> # Parent b8cc2b58219505f3d5f348a7dece9a3e1a3a96ee
> Adds compose menu bindings for grouping and moving attachments.
>
this whole patch looks more like a work in progress than something that
should be submitted.
> +/* need to redo using mutt_gen_attach_list() */
> +
>
then do so ;)
> + /* for first match, set group desc according to match */
> +# define ALTS_TAG "Alternatives for \"%s\""
>
i18n? or is this just the mime structure?
the define is ugly and looks way out of place. should use a static const
char [] in the scope below. the compiler can still optimize the
strlen().
> + if (!group->description)
> + {
> + p = bptr->next->description;
> + if (!p)
> + p = bptr->next->filename;
> + if (p)
> + {
> + group->description = safe_calloc(1,
> + strlen(p) + strlen(ALTS_TAG) + 1);
> + sprintf(group->description, ALTS_TAG, p);
> + }
> + }
> +
> +<para>
> +Beware that such messages cannot be postponed. Once two attachments are
> +grouped as alternatives, they must be sent or lost.
> +</para>
> +
- why?
- do you really think this is an acceptable limitation for general use?
i don't even see any code which would alert the user about attempting
an operation that apparently leads to data loss.
how about adding an "ungroup" action? the necessity to discard the
attachments and start from scratch when one makes a mistake isn't very
user-friendly.
