There are mostly fair comments. I've had this patch for many years in
the middle of a patch queue and I'd forgotten it was still rough. I'll
withdraw this - I'm not going to find time for updating it.
* On 30 Aug 2016, Oswald Buddenhagen wrote:
> On Tue, Aug 30, 2016 at 04:34:37PM -0700, d...@bikeshed.us 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 <d...@bikeshed.us>
> > # 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.
--
David Champion • d...@bikeshed.us
