Wordwrap in the Mail/News Editor Sucks!!!
Russ Allbery
Dan Mosedale <dm...@netscape.com> writes:
> The fact that a line is quoted with a ">" does not make it acceptible
> for it to be wider than 80 columns, because it (generally speaking)
> screws people using text-mode readers. The quoted text should be
> wrapped using some function that heuristically decides to do so with a
> fill-prefix of ">" or "> " or some such. Yes, I know this is hard, but
> getting it wrong some of the time is better than the behavior you
> describe, which involves getting it wrong all of the time.
This should only ever be done under the direct control of the user and
absolutely never should be done automatically. Otherwise, you will make
it impossible for users to follow up to and correctly quote articles that
legitimately should not be wrapped, such as code excerpts with long lines.
> Additionally, the people should be able to override the function with
> javascript code of their own devising, so that stuff like SuperCite is
> possible.
Yes to the idea, *sigh* to the dreck SuperCite kicks out pre-lobotomy.
--
Russ Allbery (r...@stanford.edu) <URL:http://www.eyrie.org/~eagle/>
Mark Evans
Jamie Zawinski (j...@netscape.com) wrote:
:
: I know what the right way to fix this for all interested parties is; the
: UI isn't really all that complicated, but it has yet to be implemented.
:
: And it's about time, dammit.
:
: Here is how it should be:
:
: 1: The plain-text message composition window:
:
: A: Text must visibly soft-wrap at a configurable column (say, 72)
: regardless of the width of the window.
In addition the configuration must recognise that 80 is a "hard" limit.
e.g. attempting to set column width greater that 80 should mean that it
gets set to 80, (or 78 or 79).
: B: Lines that begin with ">" at the beginning of a line must make
: that line be exempt from this wrapping: they must not wrap at
: all, and a horizontal scrollbar must appear on the window if
: necessary.
The logic should be more that lines which are being quoted should not
be wrapped. Also it might be a good idea to ensure that the quote
prefix (e.g. "> ") is not easily deletable (Otherwise careless editing
could cause all sorts of mess). Probably the best option while editing
is to insert a non ASCII code/string (to be replaced by a human readable
prefix). This means that things can be arranged so that the quote prefix
cannot be either deleted or inserted in the editor.
: ("Beginning of line" means "after hard-line-break", not "in
: the first column", because a wrap-induced soft-break that
: leaves ">" in the first column shouldn't trigger this
: behavior.)
:
: C: The ">" lines should be in another color/face, to make it
: apparent that they're behaving specially.
This to be user configurable, enabling a user to choose the options
which contrast best.
: D: The font used for editing must be fixed width, even on the Mac.
This applies to both quoted and new text. Also if different fonts are
used they should be (and appear as) the same width. Options such as
bold, italic and colour may be better than two different fonts.
: E: Bonus points if typed URLs are highlighted (selectable?) in
: the same way that they are when messages are displayed.
Possibly associated with a warning not to rely on the recipient
(especially with a news posting) being able to "just click" here.
:
: F: Bonus points if the wrapping column is some kind of visible
: "slider" at the top of the window, with a number next to it,
Don't you mean a ruler :)
Obvious preferences would be to allow it to be put at top, bottom or
both.
: with a big red "stop" mark at 79. This would eliminate the
: need for the "wrap long lines" preference on the composer.
:
: 2: The HTML message composition window:
:
: A: It must deal with whatever complicated issues there are related
: to citations, and to their editing.
:
: B: It must generate HTML that is as readable "in the raw" as
: possible, and hopefully, as conformant to the HTML spec as
: possible, since we really get beaten up about that in the
: mail/news world way more than in the web-page world.
One quite simple thing is to make it very difficult to send HTML (as
well as various other strange formats) to a random email address/newsgroup.
For the former the address book mechanism would appear to be most useful.
--
Mark Evans
St. Peter's CofE High School
Phone: +44 1392 204764 X109
Fax: +44 1392 204763
TenThumbs
Jamie Zawinski <j...@netscape.com> wrote:
> I agree with this in principle, but it's a two-edged sword.
>
> [omitted]
>
> I know what the right way to fix this for all interested parties is; the
> UI isn't really all that complicated, but it has yet to be implemented.
>
> And it's about time, dammit.
>
> Here is how it should be:
>
> 1: The plain-text message composition window:
>
> A: Text must visibly soft-wrap at a configurable column (say, 72)
> regardless of the width of the window.
>
> B: Lines that begin with ">" at the beginning of a line must make
> that line be exempt from this wrapping: they must not wrap at
> all, and a horizontal scrollbar must appear on the window if
> necessary.
>
> ("Beginning of line" means "after hard-line-break", not "in
> the first column", because a wrap-induced soft-break that
> leaves ">" in the first column shouldn't trigger this
> behavior.)
>
That should read "lines that begin with a string that match this regular
expression..." which will handle "^: ", "^| " as well as "^> " and anything else
some weird program comes up with; but not "^From ". This must be a user pref but
doesn't have to be in the ui.
> C: The ">" lines should be in another color/face, to make it
> apparent that they're behaving specially.
>
Make that color/face/size.
> [omitted]
>
> We first discussed doing this stuff before 2.0 shipped, and I consider
> it a disaster of moderately epic proportions that we made it all the
> way to 4.0 (and without a doubt, 5.0) without the text/plain editor
> having improved in any appreciable way. We can't let this continue!
> We *really* need to fix it this time around. This time for sure.
>
You left out the most important thing: the ability to import a text file into
the window. Importing HTML fragments would be nice but is probably hard.
Phil Peterson
Jamie Zawinski (j...@netscape.com) wrote:The editor folks spent some time on that in 4.0. It was way worse, for readability, in 4.0 betas.
: B: It must generate HTML that is as readable "in the raw" as
: possible,
and hopefully, as conformant to the HTML spec as
: possible, since we really get beaten up about that in the
: mail/news world way more than in the web-page world.
One quite simple thing is to make it very difficult to send HTML (as
well as various other strange formats) to a random email address/newsgroup.
For the former the address book mechanism would appear to be most useful.
- If the message contains no HTML
- If all the recipients are known to like HTML, send it in text/html only
- If all the recipients are not known to like HTML, send it in text/plain only
- If the message contains HTML
- If all the recipients are known to like HTML, send it in text/html only
- If all the recipients are not known to like HTML, observe the user's prefs, which can be set to:
- Ask me what to do (the default)
- Convert to text and send as text/plain only
- Send as text/html anyway
- Send as multipart/alternative with a text/plain and text/html part
Of course, this leaves the decision with the sender, and it might be interesting to explore leaving the decision with the recipient, so that the HTML-to-plain-text converter could be run on incoming mail. Personally, I'd be happy to run the converter in the other direction, and not see any more prehistoric-looking fixed font messages wrapped with a 40 column text editor, but that's just my personal bias.
-- Phil.
TenThumbs
Jamie Zawinski wrote:
>
> TenThumbs wrote:
> >
> > > B: Lines that begin with ">" at the beginning of a line must make
> > > that line be exempt from this wrapping:
> >
> > expression..." which will handle "^: ", "^| " as well as "^> " and anything else
> > some weird program comes up with;
>
> message*) all that matters is the citation character that *you* are
> using, not the citation character that some random program out on the
> net is using. It's the text that you cited that matters, not the random
> crap inside that citation, that you have to match.
>
Actually yes. I want to be able to read someone else's mail and/or news message
and have the citation font/color/size stuff work. I can't control what someone
else's program does.
> However, I am strongly opposed to making Mozilla configurable to ever
> generate a different citation than exactly the string "> ", but let's
> not argue about that now (it's trivial compared to the other issues.)
>
This is only important when you compose a reply not when reading. I don't have
a problem with a "> " only on compose.
Jamie Zawinski
TenThumbs wrote:
>
> Actually yes. I want to be able to read someone else's mail and/or news message
> and have the citation font/color/size stuff work. I can't control what someone
> else's program does.
But I was talking only about the message composition tool.
The message display tool is a totally different beast with very
different constraints (for example, it's not a text editor...)
--
Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
Jungshik Shin
In <3587cbf7...@news.mozilla.org>, TenThumbs wrote:
: Jamie Zawinski <j...@netscape.com> wrote:
:> We *really* need to fix it this time around. This time for sure.
: You left out the most important thing: the ability to import a text file into
: the window. Importing HTML fragments would be nice but is probably hard.
Yes, it's very important to have the ability to import a text file
into the window. For the past two or three years, I suggested this a few
times via a couple of different channels , but it never made itself into
Mozilla. Currently Mozilla offers only attaching text/plain, but
sometimes people want to import text into the composition window for
further editing.
Jungshik Shin
TenThumbs
Jamie Zawinski <j...@netscape.com> wrote:
> TenThumbs wrote:
> >
> > Actually yes. I want to be able to read someone else's mail and/or news message
> > and have the citation font/color/size stuff work. I can't control what someone
> > else's program does.
>
> But I was talking only about the message composition tool.
> The message display tool is a totally different beast with very
> different constraints (for example, it's not a text editor...)
True but I suspect they will both share some common components; e.g., they both
have to display a citation. I just want to make sure no functionality is lost.
Mark Evans
Jamie Zawinski (j...@netscape.com) wrote:
: TenThumbs wrote:
: >
: > > B: Lines that begin with ">" at the beginning of a line must make
: > > that line be exempt from this wrapping:
: >
: > That should read "lines that begin with a string that match this regular
: > expression..." which will handle "^: ", "^| " as well as "^> " and anything else
: > some weird program comes up with;
:
: No, actually not, because in this case (since you're *composing a
: message*) all that matters is the citation character that *you* are
: using, not the citation character that some random program out on the
: net is using. It's the text that you cited that matters, not the random
: crap inside that citation, that you have to match.
I still feel it makes more sense to add a control character which means
"indent the line 2 spaces, display in contrasting font and don't attempt
to change anything".
Then when editing has finished you subsitute "> " (or whatever).
Akkana
> In <3587cbf7...@news.mozilla.org>, TenThumbs wrote:
> : You left out the most important thing: the ability to import a text file into
> : the window. Importing HTML fragments would be nice but is probably hard.
Coming soon to a mozilla near you. And yes, it's long overdue.
...Akkana
Martin T. Kutschker
Jamie Zawinski wrote:
>
> Here is how it should be:
>
> 1: The plain-text message composition window:
>
> A: Text must visibly soft-wrap at a configurable column (say, 72)
> regardless of the width of the window.
Yes!!!
> B: Lines that begin with ">" at the beginning of a line must make
> that line be exempt from this wrapping: they must not wrap at
> all, and a horizontal scrollbar must appear on the window if
> necessary.
Maybe the quote character could be changed for each mail (defaulting to ">" as
some users use characters like ":" &c.
Agreement on all other points.
> 2: The HTML message composition window:
>
> A: It must deal with whatever complicated issues there are related
> to citations, and to their editing.
>
> B: It must generate HTML that is as readable "in the raw" as
> possible, and hopefully, as conformant to the HTML spec as
> possible, since we really get beaten up about that in the
> mail/news world way more than in the web-page world.
In particular I wish it wouldn't insert so many
And it should be able to deal with pre-formatted text like my signature. I have
failed to make send it as simple as
<PRE>
sig
</PRE>
It insisted on inserting a <PRE> _plus_ s on every line but strangely
still made line-breaks at 72 characters which broke up the sig because of the
<PRE> tags.
> 3: There must be a way to switch between the two modes, without
> having to delete the window first!
>
> Obviously this can be a lossy transformation, and maybe the user
> should be made to confirm, but it should be possible to make the
> switch without creating a new window and cutting-and-pasting.
And of course the two modes should work on a per receiver basis. I thought it
should work in NN4.0 but I guess I never figured it out how. My wish is to
disable HTML mails except for a few ones.
Masi
+----------------------------------------------------------------------+
| Martin Thomas Kutschker /\ "Nonetheless I shall grant thy prayer, |
| _____||_ and thou shall go to Eilinel, |
| _________/ | and be set free from my service." |
------------ \________________________________________+
ew...@bellatlantic.net
Jamie Zawinski wrote:
>
> B: Lines that begin with ">" at the beginning of a line must make
> that line be exempt from this wrapping: they must not wrap at
> all, and a horizontal scrollbar must appear on the window if
> necessary.
Well, I don't want this to be a major ordeal. Actually for simplicity I
think the ">" lines could be treated the same as any other line -- as
long as the wrapping is visible in real-time during message composition.
If some ">>>" lines wrap over and have to be cleaned up I don't think
that would surprise anyone. I just don't want the other kind of surprise
I get now.
Thanks...
Daniel Veditz
> : message*) all that matters is the citation character that *you* are
> : using, not the citation character that some random program out on the
> : net is using. It's the text that you cited that matters, not the random
> : crap inside that citation, that you have to match.
>
> I still feel it makes more sense to add a control character which means
> "indent the line 2 spaces, display in contrasting font and don't attempt
> to change anything".
>
> Then when editing has finished you subsitute "> " (or whatever).
No, the quoted text needs to be fully editable--including the citation
character. Netiquette encourages "trimming" and that sometimes involves
rearranging the line breaks.
-Dan Veditz
Daniel Veditz
Martin T. Kutschker wrote:
>
> Jamie Zawinski wrote:
> >
> > 3: There must be a way to switch between the two modes
> > having to delete the window first!
>
> should work in NN4.0 but I guess I never figured it out how. My wish is to
> disable HTML mails except for a few ones.
It is a matter of religion with some that mail programs should NEVER
generate two different messages with the same message ID. Furthermore if
you receive a mail with several people listed in the CC: those people
should all have gotten identical copies of the message.
Our compromise in 4.0 was to create a mode where you can send both text
and HTML versions in the same message, but that has several
disadvantages as well.
If anyone wants to drag out the "sending HTML mail" flame-war please
start a new thread so the people who aren't interested can killfile it.
-Dan Veditz
Mark Evans
Daniel Veditz (dve...@netscape.com) wrote:
However in far more cases allowing such "full" editing can lead to
posts where it is unclear which lines are being quoted, bogus citations,
"stealing" of original text, etc. Either accidentaly by a "newbie"
who dosn't undestand what they are doing or by someone deliberatly
attempting to disrupt.
Erik Moeller
Jamie Zawinski wrote in message <358715C1...@netscape.com>...
> B: Lines that begin with ">" at the beginning of a line must make
> that line be exempt from this wrapping: they must not wrap at
> all, and a horizontal scrollbar must appear on the window if
> necessary.
Why should we still rely on the old ">" quoting technique anyway? I know,
I'm using it myself here, but I could also have quoted you like this:
B: Lines that begin with ">" at the beginning of a line must make that
line be exempt from this wrapping: they must not wrap at all, and a
horizontal scrollbar must appear on the window if necessary.
I.e. ignore the line breaks in the quoted text, reformat the text for 64
characters screen width (64 = 72-8) and indent it using Tabs. Multiple
spaces between the text should be ignored, preceding spaces should be used
as an additional indention for
- the beginning line if it is used in the first line of a quoted
paragraph
- all lines if the whole paragraph is indented
You could also specify a minimum width for text to be summarized into a
paragraph, i.e. reformatted.
Some examples:
Source text:
Hello, my name is Jimmy Pop and I'm a dumb white guy.
Target text:
Hello, my name is Jimmy Pop and I'm a dumb white guy.
Source text:
Hello, my name is Jimmy Pop and I'm a dumb white guy.
I'm not old or new but middle school fifth grade like junior high.
Target text (indented twice, but reformatted):
Hello, my name is Jimmy Pop and I'm a dumb white guy. I'm not old or
new
but middle school fifth grade like junior high.
Source text:
Hello, my name is Jimmy Pop and I'm a dumb white guy.
I'm not old or new but middle school fifth grade like junior high.
Target text (normally indented and reformatted):
Hello, my name is Jimmy Pop and I'm a dumb white guy. I'm not old or new
but
middle school fifth grade like junior high.
Source text:
- Check for new mail
- Call Mandy
- Go shopping
Target text (because of minimum width under, say, 20 characters, each line
is treated separately):
- Check for new mail
- Call Mandy
- Go shopping
Of course, a more advanced feature would be to specify the dash as a
numbering character. If it occurs at least twice at the beginning of
consecutive lines, each "dashed" line is treated as part of the numbering.
But why do all this? Simple, because it would finally eliminate all the
wrapping problems that come with normal quoting. For example, when I have
text that is quoted like this:
> Hello, my name is Jimmy Pop.
> And I'm a dumb white guy.
It looks like this in reformatted form.
> Hello, my name is Jimmy Pop. > And I'm a dumb white guy.
Really ugly.
Also, of course, if the quoted lines are longer than 78 chars, you get
problems with quoting.
> No matter what we do, if we have a line which is a long as this one, with
the regular technique, we'll always wrap the window border at some point.
> Which really doesn't look good. Of course you can use horizontal
scrollbars, but that's a real nightmare for serious text processing. What
did this guy write? Let me scroll to pixel position 1602 ..
Of course, we could save us a lot of work by simply using <BLOCKQUOTE>, but
unfortunately, HTML is not a mail/news standard yet. And neither M$ nor NS
showed good reasons why it should be. (Instead M$ included great templates
for writing birthday cards. YUCK! Have these guys ever been productive in
their whole lives?)
I hope that everything is wrapped correctly in this posting. If there are
any problems of understanding, just ask.
Best Regards,
Erik Moeller
Joel York
Mark Evans wrote:
> Daniel Veditz (dve...@netscape.com) wrote:
> : No, the quoted text needs to be fully editable--including the citation
> : character. Netiquette encourages "trimming" and that sometimes involves
> : rearranging the line breaks.
> However in far more cases allowing such "full" editing can lead to
> posts where it is unclear which lines are being quoted, bogus citations,
> "stealing" of original text, etc. Either accidentaly by a "newbie"
> who dosn't undestand what they are doing or by someone deliberatly
> attempting to disrupt.
So make (yet another) option that initialli disallows editing. This will
protect newbies from being stupid. If you're looking to find a way to
prevent someone (who knows what they're doing) from being disruptive,
you're looking at the wrong area. There will always be mailers that let
people do whatever they want. Things should work so that intelligent
people can do what they want to want to do easily and quickly. As jwz
pointed out elsewhere, html mail is where we should spend effort getting
citations correct.
Joel
Henrik Lynggaard Hansen
Jamie Zawinski wrote:
> Erik Moeller wrote:
> >
>
>
> > Of course, we could save us a lot of work by simply using <BLOCKQUOTE>
>
> There are proposals around for how to do well-structured citations and
> references inside text/html messages, and Mozilla should use those when
> generating HTML messages.
great
>
>
> But for text/plain messages, Mozilla should use ">" as the citation
> character, and should not make any attempt to make that customizable.
> Because when people get creative with how they do their citations,
> everyone else loses, so we should do nothing to encourage this behavior.
Is it allowed to quote like this ? (it was standard in old fido days, so why
hasn't people kept the habit ?
JZ>But for text/plain messages, Mozilla should use ">" as the citation
JZ>character, and should not make any attempt to make that customizable.
if so, let us have a option to use that style
Mark Evans
Erik Moeller (noel...@aol.com) wrote:
: Jamie Zawinski wrote in message <358715C1...@netscape.com>...
:
: > B: Lines that begin with ">" at the beginning of a line must make
: > that line be exempt from this wrapping: they must not wrap at
: > all, and a horizontal scrollbar must appear on the window if
: > necessary.
:
: Why should we still rely on the old ">" quoting technique anyway? I know,
So that people using different software are presented with something
readable. As I said before it make more sense to prefix a control character
in the file which gets passed to the editor.
: I.e. ignore the line breaks in the quoted text, reformat the text for 64
: characters screen width (64 = 72-8) and indent it using Tabs. Multiple
Tabs are frowned on in usenet posts for the same reason as lines over
80 characters. The behaviour is undefined.
: spaces between the text should be ignored, preceding spaces should be used
: as an additional indention for
:
: - the beginning line if it is used in the first line of a quoted
: paragraph
: - all lines if the whole paragraph is indented
And how is this going to handle multiply quoted text? Note also that
the more the quoted text is "messed arround" with the more possible it
is that (accidentaly or deliberatly) it will end up saying something
different.
Encouraging people to do anything other than trimmage of quoted text
will result in all sorts of problems and potential flame wars.
: Of course, we could save us a lot of work by simply using <BLOCKQUOTE>, but
: unfortunately, HTML is not a mail/news standard yet. And neither M$ nor NS
You mean *fortunatly* a great many people do NOT use web browsers to read
email and news.
Mark Evans
Joel York (jo...@anywaretechnology.com) wrote:
:
: people do whatever they want. Things should work so that intelligent
: people can do what they want to want to do easily and quickly. As jwz
: pointed out elsewhere, html mail is where we should spend effort getting
: citations correct.
Disgree here. Except for users who only email others known to be running
a non textual email system and who never post to usenet, the reply (and
followups) people generate should be textual.
This also applies where the original is non text.
For usenet the following really needs to apply.
Text with MIME headers arround : remove them when generating a follow up.
Copies with HTML and text : ignore the HTML when generating a follow up.
Raw BASE64 : convert to text and prefix a warning line.
HTML only : ditto.
The only situation HTML citations would be needed is it the case of
someone receiving an HTML email and replying to the original sender.
(i.e. if a reply to field is set one an HTML reply should only be
generated where an address book entry exists for that address.)
The wrong thing to do IMHO is to simply citate blindly in the format
of the original message. Non-text messages have no place on usenet or
mailing lists (except binary groups and there is a very good argument
that these are obsolete). If some moron has posted a non-text message
(which may not be obvious to a user of a package which can decypher it)
then the mistake should not compounded by follow ups in strange formats.
Everyone (including Mozilla users) can read and understand text.
Curtis (Jewell) Whalen
Mark Evans wrote in message <6mt7o5$f5...@secnews.netscape.com>...
>Joel York (jo...@anywaretechnology.com) wrote:
>:
>: people do whatever they want. Things should work so that intelligent
>: people can do what they want to want to do easily and quickly. As jwz
>: pointed out elsewhere, html mail is where we should spend effort getting
>: citations correct.
>
>Disgree here. Except for users who only email others known to be running
>a non textual email system and who never post to usenet, the reply (and
>followups) people generate should be textual.
>
>This also applies where the original is non text.
>
>For usenet the following really needs to apply.
>Text with MIME headers arround : remove them when generating a follow up.
Disagree with this - what about different character sets (for example, I
write in Latin-3 in my own Perl "edit and send" script because I want to
use the Esperanto characters?)
Keep the character set the same at least!
--Curtis
Mark Evans
Curtis (Jewell) Whalen (curtis_wha...@geocities.com) wrote:
:
: Mark Evans wrote in message <6mt7o5$f5...@secnews.netscape.com>...
Ok, but MIME headers arround 7 bit text are utterly stupid. Might not
be a bad idea for the program to scan the text to see if the MIME
headers agree with the text. Using MIME headers when they are not
needed is an issue for newsreaders which use an external program
to display MIME messages.
The important thing IMHO is to ensure that posts are legible and
appear without (especially) prefix and suffix "garbage" on other
newsreaders. There is nothing wrong with using MIME where it is
sensible to use it, e.g. a post in a langauge which uses a non ASCII
character set.
Ejon7
Jamie Zawinski wrote:
>
> (Followups set to netscape.public.mozilla.mail-news.)
>
> Greg Stark wrote:
> >
> > No really, he's right. The composer window should show exactly what
> > will be sent, including wrapping to 72 columns, including signature,
> > everything.
> >
> > Anything else just skewers hapless users who don't even realize
> > they're committing netiquette violations or don't realize the columns
> > aren't going to line up when the last minute changes are done behind
> > their back before sending.
>
> I agree with this in principle, but it's a two-edged sword. In Mozilla
> 2.0, the composition window did word wrap, and when the message was
> sent, it inserted hard newlines into the message exactly where on-screen
> wrapping occurred. Sounds perfect, right? Well, what happened was,
> most people ended up sending hundred-column messages, because a common
> habit was apparently to maximize (or otherwise widen) the window while
> editing (probably in order to make the cited text be readable.)
>
> In 3.0, I changed it so that it always wrapped at 72 columns regardless
> of window width, and that worked better. And it was really the only
> thing that could have been done at the time, since rewriting the entire
> composition window (i.e., reimplementing the text field on all three
> platforms) was just not an option due to time constraints. It was the
> best solution available (since turning off word-wrapping altogether was
> not an acceptable option to any non-Unix users.)
>
> For the rationale behind what 3.0 did (which is mostly-but-not-quite
> what 4.0 does) see
> http://home.netscape.com/eng/mozilla/3.0/relnotes/unix-3.02.html#Message
>
> I know what the right way to fix this for all interested parties is; the
> UI isn't really all that complicated, but it has yet to be implemented.
>
> And it's about time, dammit.
>
>
> 1: The plain-text message composition window:
>
> A: Text must visibly soft-wrap at a configurable column (say, 72)
> regardless of the width of the window.
>
shouldn't that be the "user configurable quoted message delimiter"?? ;-)
Jungshik Shin
In <6nd7ht$nc...@secnews.netscape.com>, Mark Evans wrote:
: Curtis (Jewell) Whalen (curtis_wha...@geocities.com) wrote:
: :
: : Mark Evans wrote in message <6mt7o5$f5...@secnews.netscape.com>...
: : >For usenet the following really needs to apply.
: : >Text with MIME headers arround : remove them when generating a follow up.
: :
: : Disagree with this - what about different character sets (for example, I
: : write in Latin-3 in my own Perl "edit and send" script because I want to
: : use the Esperanto characters?)
: Ok, but MIME headers arround 7 bit text are utterly stupid. Might not
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Conternt-Transfer-Encoding: 7bit
I agree that the above header is certainly redundant(although not
harmful to any sensibly written news/mail readers). However, these
headers below should be present.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf7
Conternt-Transfer-Encoding: 7bit
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Conternt-Transfer-Encoding: 7bit
Jungshik Shin