105511 - word and character (line?) count feature

Status: NEW

(MailNews Core :: Composition, enhancement)

Description

[sujay]

need word count feature per Rafael's feature request document

Comment 1

[sujay]

bulk move to Future...sorry for the spam

Comment 2

[Ian Pottinger]

adding self to cc list

Comment 3

[Rick Timmis]

Hi We've have recently deployed Mozilla in a Coorporate enviroment on Red Hat.
30 Users 5 Days a week using Mail, Navigator and Address Book.
One of the things we could really do with is a word count feature in Email.
Thanks I have added myself to the cc list on this one.

Comment 4

[Rafael Ebron (:rebron)]

Agree that this would be cool in Mail/News compose.  Could be a status menu
while typing, i.e.

Word Count: 120

Comment 5

[Kathleen :Brade]

reassign to new placeholder

Comment 6

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Taking.

Comment 7

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

forgot to tag, sorry for spam.

Comment 8

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 9

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 10

[Karsten Düsterloh]

Still valid RFE, with occasional dupes on the mail side.

Comment 12

[john]

The later noted bug 709434 suggests a broader enhancement, to include character count [a sensible change, in the world where 140 or 160 characters are relevant -- sms Texts sent by email].   I would include "character" in this enhancement request, and would change the title, here to reflect that...

Also that bug 709434 is in the Thunderbird world, with its own flags, UI/QA contacts, and component identification, and parties of interest.  Also, there, flags would have different relevance?  Will any of this make a difference, or are the core programming elements of message composition in identical states [current code and planned changes], as between Thunderbird and Seamonkey?

Comment 13

[Lee_Dailey]

howdy y'all,

since bug 709434 was duped to this one, would someone please change this to include both word count AND character count?

take care,
lee

Comment 15

[Lee_Dailey]

howdy Ludovic Hirlimann,

since you have duped bug 769859 to this one, would you please change the bug title to reflect the combo of word AND char counts? something similar to the title from bug 709434 seems reasonably appropriate.

take care,
lee

Comment 16

[john]

Wishing I was wise enough in patch creation to handle this...   In lieu, is anyone taking this on for character counts ?

Comment 17

[john]

After writing an email and watching the check-for-attachment fire, when I typed the "g" in "attaching" in the email...

I realized that the code for character counting could be buried inside / around the code for checking for attachments.  Something is going on, character by character, obviously.   Or the code is very similar, substituting a character-count and relevant messages, for the attachment language and its popup.

I tried wandering around the code, saw this area, but, frankly I am lost:
https://mxr.mozilla.org/comm-release/source/mail/components/compose/content/MsgComposeCommands.js#1811
and at
Line 1891 et seq.

Anyone with skill: does this ring a bell and interest ?

Comment 19

[rsx11m]

Bug 961992 - RFE: When writing a message, can the status line display the line-number and character number? - would extend the scope of this bug. I'm wondering though what the semantics of "line" and "character within line" are in an HTML message which is highly variable in spacing, depending on the window width (and eventually how the recipient displays the message). Even with plain-text messages, flowed formatting allowing to rewrap the message may make the term "line" ambiguous (and there are a couple of fringe cases where the line breaks in a plain-text message differ in how they wrap during composition vs. how the message is actually sent).

Comment 20

[john]

See my comment 12, identifying "count" to include anything that goes out to an SMS Txt recipient.   Though I wonder what end-of-line characters are relevant in an SMS txt message.  <CR> or <LF> or both?  Which EOL characters are part of the body, as generated by TBird Mail?  I can imagine that different wireless providers do different things with them: whether they (both) are counted within message length for truncation purposes; which character triggers the new line, and; on and on.   Noting: any nearly correct count would be helpful when composing...

Note, also, a fix path? at comment 17

Comment 21

[rsx11m]

(In reply to john ruskin from comment #20)
> See my comment 12, identifying "count" to include anything that goes out to
> an SMS Txt recipient.   Though I wonder what end-of-line characters are
> relevant in an SMS txt message.  <CR> or <LF> or both?  Which EOL characters
> are part of the body, as generated by TBird Mail?

Neither, at least for HTML; the paragraphs (e.g., <p> or <h[1-6]> headers) or explicit <br> line breaks could be used, but that's not equal to what bug 961992 was asking for. Or, line breaks in the sense of the plain-text message part in disregard of any rewrapping, which may work for plain-text composition but may be confusing when composing in HTML mode as there is no visible equivalent.

I'm wondering if bug 961992 is actually a true duplicate of this one, though the mechanisms of using the status bar to show that may be the same. It's talking about the /position/ while writing the message whereas my understanding of the initial description here is that the /length/ is what's sought for. Of course, some hybrid "Paragraph 4, line 17, column 45 - 56 words, 678 characters" could provide the full information in the status bar with those items shown as applicable.

Comment 22

[Ronen Hod]

My use case is sending a plain-text mail to Linux people.
It is a good practice not to exceed character 72 (or 80), and currently, I do not know how to control it.
So counting visible characters since the last newline will do.
The same applies to line numbers. count the newlines that I typed.

Comment 23

[rsx11m]

(In reply to Ronen Hod from comment #22)
> My use case is sending a plain-text mail to Linux people.
> It is a good practice not to exceed character 72 (or 80), and currently, I
> do not know how to control it.

Ok, but the default for mailnews.wraplength is already 72, and this is where you should see "soft" line breaks added. As I said, with flowed formatting the recipient's e-mail client is allowed to rewrap the lines to the actual window width, thus it appears that they may be longer than they were sent.

You can switch off this feature in Edit > Preferences > Advanced > General > Config Editor, setting mailnews.display.disable_format_flowed_support to true and mailnews.send_plaintext_flowed to false.

> So counting visible characters since the last newline will do.
> The same applies to line numbers. count the newlines that I typed.

Yes, without rewrapping by flowed format or HTML rendering this would be straight-forward in terms of semantics (nevertheless tied to the global counting of characters and words initially requested here).

Comment 24

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.