Closed Bug 30484 Opened 25 years ago Closed 24 years ago

RFE: customization of quoted-text preface in replies

Categories

(MailNews Core :: Composition, enhancement, P3)

enhancement

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 13818

People

(Reporter: thedragon, Unassigned)

Details

(Keywords: helpwanted)

Communicator and currently Mozilla place a simple "So and so wrote:" above 
quoted text in replies and, I believe, forwarded messages. There are various 
circumstances in which it would be nice to have more information, most 
crucially dates. There are advantages and disadvantages to actual text-string 
customization; just a few checkboxes might be a better choice; there was no 
consensus in the newsgroup (n.p.m.ui) discussion on the subject. I am pasting 
below the pertinent parts of the newsgroup thread:


--------
Matthew Thomas wrote:
> Dan Ridley wrote:
> > In fact, there are several elements of quoting that I'd like to
> > see improve: I'd like to be able to customize the "So and so
> > wrote:" text (for instance, "So and so wrote, 2000-Mar-01" or
> > "So and so wrote, in thread 'Using ideas from Tog'").
> 
> Yes, that's one feature that users of other clients have 
> enjoyed, but I don't actually think it's a good idea to
>  include it. There are two reasons for this. The first is
> that presenting information other than the sender (and
>  perhaps the date) is usually a waste of time and readability,
> because other such information is available from the message
> headers and surrounding messages anyway (except in that rare
> event where a person sends a reply to someone other than the
> original sender or group).

Is this actually a rare event? I do it quite frequently (think "executive
summary"), but I may be unusual in this.

I am also specifically thinking here of quoting multiple messages in a
single reply. This isn't suited to Usenet particularly well, but in intranet
discussions and some of the mailing lists I'm on, we frequently need to
regroup and consolidate some of the threads. Quoting from a half-dozen
different threads, people and times and starting a new thread with it can be
very handy.

> In addition, when people start customizing their headers to `The
> dice were cast, the sky thundered, and Dan Ridley warbled on about 
> "Re: Using ideas from Tog" in netscape.public.mozilla.ui ...', then
> that just makes life more difficult for those people who are trying
> to do a Deja search for messages which are actually *about* `dice'.

Or just trying to read the message. (Visions of eight-line attributions
attached to "Me too!" come to mind.)

So: point taken. How about a couple of checkboxes in Prefs (with suggested
default values shown):

 [x] Attribute quoted text
   [x] Include date
   [ ] Include thread
     {[x] Except in newsgroups}

(That last because many people read newsgroups threaded and far fewer read
POP/IMAP mail threaded. Also, the curly brackets around the same are an
attempt to indicate that it is disabled, since "Include Thread" is not
checked.)
Oops -- missed a message. This is also from the newsgroup:
---------
Daggi Elehu wrote:
> In this regard wouldn't it be nice to be able to specify language. I
> still think being able to write "&Name wrote on &date" in a stringbox is
> preferable. There are always going to be people that want 7-line long
> attributions, but that doesnt mean we shouldn't give serious users this
> feature. 
> 
> Actually, I was thinking about connecting this to the adressbook so that
> the composer would use different setting depending on intended receiver.
> This is extending the "Except in newsgroup" functionality. 
> This way you can reply in one language to some ng's and another to the rest, 
> and of course this might be even better in ordinary mail.
I give a negative vote for this `feature'. Reasons:

* Making quote attribution, as a whole, an option has miniscule usefulness. All
  it provides is a means for a few people (those who deselect the option) to
  annoy a lot of people (those who have to read attribution-less messages and
  wonder who wrote the quoted text).

* `Except in newsgroups' won't work consistently, and neither will specifying
  options depending on the recipient. This is due to a combination of three
  factors.
  (1) The user can add recipients/newsgroups to, and/or remove
      recipients/newsgroups from, a message after they start editing the contents
      (which may include editing the attribution preface).
  (2) Mozilla cannot change the message contents after the user starts typing,
      otherwise the user would get throughly annoyed at the software's
      interference in their writing.
  (3) Mozilla cannot change the message contents after the user clicks Send,
      otherwise it would be misrepresenting what the user actually wrote -- and
      that would be unforgivable.

* Even if specifying different attribution options for different recipients could
  work, it would require Mozilla to generate multiple copies of the message for
  different recipients. For messages which were BCCed to dozens of people, this
  would consume a lot of bandwidth and address book I/O.

* `There are always going to be people that want 7-line long attributions, but
  that doesnt mean we shouldn't give serious users this feature' doesn't really
  make sense to me, because serious users would be the type who prefer simple
  attributions anyway. Complex attributions take time both to set up and to read,
  which reduces the productivity both of those senders who use them and those
  recipients who have to read messages using them.
cc: phil - helpwanted?
This is a valid RFE so I'm confirming it
Status: UNCONFIRMED → NEW
Ever confirmed: true
-> helpwanted. I don't think this feature is very interesting, compared to the
mountain of other helpwanted bugs.
Assignee: ducarroz → nobody
Keywords: helpwanted

*** This bug has been marked as a duplicate of 13818 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
verified as duplicate.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.