290274 - [mozTXTToHTMLConv] 'clever formatting' of plaintext strips caret from superscript display (x^2 => x2)

Status: RESOLVED FIXED

(MailNews Core :: Backend, defect)

Description

[John Pye]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319

I received an email with the text

length = 10 * "m^2" 

This was displayed in MailNews cleverly as

length = 10 * "m²"

(after the 'm' a superscript '2' instead of [carat] followed by '2')

This is fine for reading emails but if I COPY this text into my source code
editor, I still see the superscript '2', not the [carat] followed by '2', which
is what I need. 

Isn't the pricipal underlying the 'clever formatting' of plaintext email that
the plaintext shouldn't be altered, only formatted?

In that case, the 'clever formatting' version of 'x^2' should be x followed by
superscript carat followed by superscript '2'.

Reproducible: Always

Steps to Reproduce:
1. Send an email to your self containing the text: length = 10 * "m^2" 
2. Receive this email and observer superscript '2' and no carat
3. Copy the text from the email window into notepage, and note note missing carat.

Actual Results:  
No carat in pasted text

Expected Results:  
Carat should still be there - it is necessary for the meaning of the source
code. I don't want a '²' character.

Comment 1

[Mike Cowperthwaite]

(In reply to comment #0)
> This is fine for reading emails but if I COPY this text into my source code
> editor, I still see the superscript '2'

When I paste, I don't see the superscript '2' (0xB2), I see the plain ASCII '2'.


> Expected Results:  
> Carat should still be there - it is necessary for the meaning of the source
> code.

This seems a reasonable expectation; in the case of bold/italic 'struct' 
formatting, the '*' and '/' characters are even still visible in the bolded/
italicized text.  (Of course, someone opened a bug asking to suppress those 
characters in the display...)

Note that the superscripting display can be turned off, by turning off the 
display option for graphical smileys.

Comment 2

[John Pye]

(In reply to comment #1)
> 
> When I paste, I don't see the superscript '2' (0xB2), I see the plain ASCII '2'.

Sorry, you are right. I also get a plain ASCII '2'.

> in the case of bold/italic 'struct' 
> formatting, the '*' and '/' characters are even still visible in the bolded/
> italicized text.  (Of course, someone opened a bug asking to suppress those 
> characters in the display...)

Yes I noticed this about bold/italics. It's good that the '/', '_' and '*'
remain visible in the text, especially when quoting file/directory names. This
is what is needed with the carats as well, in my opinion.

> 
> Note that the superscripting display can be turned off, by turning off the 
> display option for graphical smileys.

I like having these graphical smileys etc, I just expect that the 'clever
formatting' doesn't change the way that the text copies when I take it to other
applications.

JP

Comment 3

[Mike Cowperthwaite]

*** Bug 305486 has been marked as a duplicate of this bug. ***

Comment 4

[Ben Bucksch (:BenB)]

> if I COPY this text into my source code editor

Workaround: Use "View Message Source" (you're a programmer after all)

> Isn't the pricipal underlying the 'clever formatting' of plaintext email that
> the plaintext shouldn't be altered, only formatted?

Not necessarily. In fact, what differentiates this particular code part from the others ( *bold* and URLS) is exactly that it substitutes = alters. If you don't like that, disable it.

> Expected Results:  
> Carat should still be there

No, that makes no sense to have ^ *and* superscript. Only fix would be to remove the feature.

> > Note that the superscripting display can be turned off, by turning off the 
> > display option for graphical smileys.

> I like having these graphical smileys etc, I just expect that the 'clever
> formatting' doesn't change the way that the text copies when I take it to
> other applications.

Well, you see, smiley *also* "change the way that the text copies" and alters the message as displayed. Same risk as here. That's exactly why they are combined.

Either "clever" and "pretty" or plain - your choice. The only possible fix here would be to remove the choice from all users. I personally don't care much about this particular instance, although it would be kind of a pity.

Comment 5

[Ben Bucksch (:BenB)]

FYI, the backend pref name is
mail.display_glyph

Comment 6

[Ben Bucksch (:BenB)]

preed blogged "
The other cool "Wow, it just works" Thunderbird feature I ran into that really impressed me was a message that had "^2" in it. Thunderbird (correctly) rendered this in the message as a superscript "2".
"

> Only fix would be to remove the feature.

Given that some people feel this is a cool feature, and it goes wrong only in egde cases, with workarounds, marking WONTFIX (in capacity of being the relevant coder).

Comment 9

[Szabolcs Horvát]

(In reply to comment #6)
> > Only fix would be to remove the feature.
> 
> Given that some people feel this is a cool feature, and it goes wrong only in
> egde cases, with workarounds, marking WONTFIX (in capacity of being the
> relevant coder).

Why WONTFIX? The problem is not that it is displayed as a superscript, but that it is *copied* without a caret. Smileys are also displayed in a "pretty" way, but they are copied in an ASCII representation.

It doesn't go wrong only in "edge" cases, most people who use this x^2 notation often, would also want to copy and paste it often. And many of them are not programmers (or willing to dig this deep to find out about mail.display_glyph), but LaTeX users or users of a computer algebra system, who may not even notice immediately what's going on, as some CASes also display x^2 as subscript (but copy it correctly).

Theoretically it is possible to _display_ it as superscript, but _copy_ it correctly, with the ^ character (there are many programs that can copy data differently than it is displayed), though I have no idea about how difficult this is to implement in Thunderbird. I just wanted to point out that the current behaviour of the program is objectively wrong, even if it is difficult to fix, and that the workaround is not at all easy to find (by Googling etc.)

Comment 10

[Ben Bucksch (:BenB)]

It is impossible to use the smiley trick (<img alt=":-)" src="smiley.png">) here.

The workaround is trivial and obvious: re-insert the ^ manually after copying. (*If* you notice it missing.)

Comment 11

[Günter Rote]

(In reply to comment #4)
> 
> Workaround: Use "View Message Source" (you're a programmer after all)

This does not always work. Some messages are "quoted-printable"
encoded, they contain all sorts of extra "=" symbols at line ends
and "=3D" where a simple "=" should be.

For the same reason, even saving to a file and copying from there
won't work.

> 
> > Expected Results:  
> > Caret should still be there
> 
> No, that makes no sense to have ^ *and* superscript. Only fix would be to
> remove the feature.

This is not true.
I have recently installed a new version of the emacs editor with
the auctex extension for TeX files, and it displays
a^2 with the 2 in the superscript font, but the ^ is still there.

So, apparently, there are people who think it makes sense
to have both the ^ and the superscript. (In a somewhat different
context, admittedly.)

I liked the "clever formatting" feature, (and
I find a-superscript-2 looks better without the caret), but
I have sadly turned it off (after a lot of struggle
and finally finding out what the name of the feature
really is, by a helpful hint from the bugzilla community,
shortly before the feature outsmarted me and
I considered switching to Outlook Express ;-),
because I don't want to hand-edit passages of text
after copying them.

(By the way, there is another "smart" work-around:
Use "Reply" and remove the "> " from each line.

Comment 12

[Günter Rote]

(In reply to comment #10)
> It is impossible to use the smiley trick (<img alt=":-)" src="smiley.png">)
> here.

What about the empty trick then?  (<img alt="^" src="empty.png">)

Comment 13

[John Pye]

I think that marking this WONTFIX is OUTRAGEOUS! It should be an absolute rule that 'smart formatting' does not change the content of the text that is copied to the clipboard. This works with quote markers (>) and it works with smileys. It should work with these superscripts, or the superscript feature should be killed. This is a silly aesthetic feature that is getting in the way of productive use of Thunderbird.

Comment 14

[Ben Bucksch (:BenB)]

> It should be an absolute rule that 'smart formatting' does not change the
> content of the text

No, I disagree, and I don't follow that rule. This is display, and we alter the message in many ways. Screaming at me and demanding will just make me mad.

> What about the empty trick then?  (<img alt="^" src="empty.png">)

That's a good idea. REOPENing. Fix is trivial.

Comment 15

[John Pye]

Scream scream! If the fix with the empty.png thing works, that would be wonderful, ideal. Thanks. JP

Comment 16

[Szabolcs Horvát]

> > What about the empty trick then?  (<img alt="^" src="empty.png">)
> 
> That's a good idea. REOPENing. Fix is trivial.

That's wonderful! Will this fix make it into the 2.0 series? 2.0.0.4?

Comment 17

[Ben Bucksch (:BenB)]

There is no fix and nobody intending to work on it.

Comment 18

[Ben Bucksch (:BenB)]

(Myself, I am very busy in another, commercial project.)

Comment 19

[Mike Hahn]

I disagree with the WONTFIX as well, that is at least for the cut and paste.  I send and receive randomly generated passwords on a regular basis.  I get calls and emails from users who's password contain this "feature", because they cannot login to our site by cutting and pasting or typing in the password.  The current method of display renders their password useless.  Trying to talk the users through the workaround is like trying to sharpen a bowling ball.  The argument for not fixing it is trivial.  Anyone who can read mathematical equations knows that m^2 is the same as m².   Yes, it looks pretty, but causes non propeller heads some problems.  With at least cut and paste fixed, the propeller heads would have their pretty formating, and the rest of us would have no issues with what was really sent.  Not to mention, no matter what the copied item is pasted to, if the editor / viewer / whatever supports this type of superscripting, it shows as such if not, it's still correct for that program.

Think about it. How much of the REAL user base is mathematically incline enough to even recognize what they're seeing as correct much less a "feature".

I respectfully request reconsideration. 

Thank You for your time.

Comment 20

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 21

[Patrick Reiter Horn]

Attachment: Adds a caret symbol with display-none so it copies correctly

This worked for me when I tried it... doesn't affect output, but fixes copy and paste.

Adding a blank image would be harder, so I just went with the simple CSS solution

Comment 22

[Tuukka Tolvanen (sp3000)]

> Adds a caret symbol with display-none so it copies correctly
> 
> This worked for me when I tried it... doesn't affect output, but fixes copy and
> paste.

That's bug 39098 so it may be unwise to rely on it, not that there's a whole lot of traction on it :)

Comment 23

[Dan Mosedale (:dmosedale, :dmose)]

If this were the last bug keeping Tb3 from shipping, we wouldn't hold Tb3 for this fix => not a blocker.

Comment 24

[John Pye]

Dan -- just in case you didn't notice Patrick's comment above, there was a fix proposed for this bug, and it has been causing a few people a reasonable amount of grief. Would be really great if the patch can be applied sooner rather than later...

Comment 25

[Dan Mosedale (:dmosedale, :dmose)]

True.  sp3000's point is valid as well, though.  I'm gonna delegate review on this to philor, as he tends to have well thought-out opinions on stuff like this.

Comment 26

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 291990 [details] [diff] [review]
Adds a caret symbol with display-none so it copies correctly

phil, if you're ok with this fix, feel free to mark sr=dmose as well.

Comment 27

[Ben Bucksch (:BenB)]

I think this is a WONTFIX. This is a feature, not a bug. It may be arguable, but so are smiley replacements, and they are popular. It exists since almost 10 years and annoyed very few people (10 million users, 1 vote for this bug), so I suggest to keep it.

Comment 28

[Dan Mosedale (:dmosedale, :dmose)]

Comment 19 is a reasonable use case.  The superscripting feature is nice, but having the feature break that use case in a way that's likely to be completely incomprehensible to the users it effects is Not OK. 

Comment 29

[Ben Bucksch (:BenB)]

Sorry, please ignore my last comment. I forgot the more recent discussion.

r=Ben

Comment 30

[Phil Ringnalda (:philor)]

Comment on attachment 291990 [details] [diff] [review]
Adds a caret symbol with display-none so it copies correctly

But, as per our IRC discussion, unless it runs into snags or winds up looking too ugly, I think we'd really rather use the empty image approach, instead of depending on the known bug that display:none gets copied, and if we do go with display:none, we shouldn't take it without a unit test that will remind us that we have to refix this once bug 39098 is fixed.

Comment 31

[Phil Ringnalda (:philor)]

Comment on attachment 291990 [details] [diff] [review]
Adds a caret symbol with display-none so it copies correctly

Patrick: still interested in working on a patch to do it with an image, so we don't have to fix it twice? Once I got over my fuzzy thinking about how it would work, I don't think it'll be that bad: one copy of the image in mailnews/, register a chrome://messagebody/content/ URI for it in mailnews/jar.mn and in mail/base/jar.mn, and you're set. As a bonus, since we switched from CVS to hg, adding a file without commit access is much easier than it would have been before.

Comment 32

[Szabolcs Horvát]

This bug has stayed unfixed for several years now, and obviously it is not really considered noteworthy (or a bug at all by some people).

I'd like to argue that fixing it would not be a negligible improvement by pointing out that:

1. From time to time, the issue keeps popping up on the Mathematica support mailing list.  (Most likely it affects Mathematica users more because they're used to seeing x^2 in both plaintext *and* formatted (superscripted) form, so a superscript in an email won't immediately alarm them.)

2. It is not at all obvious that the workaround is turning off emoticons.  (A superscript is not an emoticon.)  Some people still resort to the unwieldy solution of copying from the source of the mail.

3. This is the *only* pretty-formatting done by Tb that breaks copying.  Smileys, block quotes, etc. are all copyable.

A few recent references:

http://groups.google.com/group/comp.soft-sys.math.mathematica/browse_frm/thread/a107db5f575ad955/728dd9b33380e2b6

http://groups.google.com/group/comp.soft-sys.math.mathematica/browse_frm/thread/54feb2a4a4df80ab/9297407377834574

http://groups.google.com/group/comp.soft-sys.math.mathematica/browse_frm/thread/2ad06b4c9193ddac/d7005ebc08c9c1e3

Comment 33

[Tuukka Tolvanen (sp3000)]

Attachment: image alt thing

dunno, maybe everyone just turns those ghastly graphical smileys off the first thing -- that's what I do everywhere :)

here's my interpretation of comment 21, this seems to work. though I found the version with a three-line data:url in cpp more amusing...

Comment 34

[Ben Bucksch (:BenB)]

Tuukka, can we set the width to 0px or something, to make it invisible, but copied?
So, I'd rather avoid the img. But if you need to use it: isn't there some empty image already in the tree somewhere that you can reuse?

Comment 35

[Tuukka Tolvanen (sp3000)]

> Tuukka, can we set the width to 0px or something, to make it invisible, but
> copied?

yeah, there's +      "<img alt=\"^\" style=\"width:0;height:0\" "

> So, I'd rather avoid the img. But if you need to use it: isn't there some empty
> image already in the tree somewhere that you can reuse?

nothing quite appropriate popped up in a quick search http://mxr.mozilla.org/comm-central/find?string=trans.*png except perhaps in tests

Comment 36

[Ben Bucksch (:BenB)]

Yes, I meant a normal <span>, so that there's no need to load an image.

Comment 37

[John Pye]

I'd just like to :-) celebrate the 4 (2^2) year anniversary of this bug! :-P

Comment 38

[Phil Ringnalda (:philor)]

span is inline, it doesn't have width. If you make it <span style="display:inline-block;width:0;height:0;overflow:hidden">, then you've reinvented just making it visibility:hidden.

Comment 39

[Phil Ringnalda (:philor)]

Oh, nice, it's actually in netwerk, meaning that while I don't know how I'm supposed to apply that patch, I do know that the odds of landing it on 1.9.1 for Tb3 just plummeted.

Comment 40

[Tuukka Tolvanen (sp3000)]

Comment on attachment 380289 [details] [diff] [review]
image alt thing

yeah, depending from there on images somewhere like that did feel rather dodgy. also, the copying for the smileys depends on bug 39098 too so maybe it's unnecessarily ambitious to not rely on it for the caret as well. alternatively, there's also the amusing but at least self-contained
-    outputHTML.AppendLiteral("<sup class=\"moz-txt-sup\">");
+
+    // The ^ is made available for copying in the alt of an invisible image
+    outputHTML.AppendLiteral(
+      "<sup class=\"moz-txt-sup\">"
+      "<img alt=\"^\" style=\"width:0;height:0\" src=\""
+      "data:image/png,%89PNG%0D%0A%1A%0A%00%00%00%0DIHDR%00%00%00%01%00%00%00"
+      "%01%08%04%00%00%00%B5%1C%0C%02%00%00%00%0BIDAT%08%D7c%60%60%00%00%00%0"
+      "3%00%01%20%D5%94%C7%00%00%00%00IEND%AEB%60%82"
+      "\">");
;)

Comment 41

[Tuukka Tolvanen (sp3000)]

Attachment: overflow hidden thing

ok, so the hack in comment 38 sounds practical because it's self-contained, doesn't involve images, and I wouldn't consider it likely to ever become non-copyable (well, /maybe/ for 0x0 as opposed to, say, 1x1 or greater, but, um).

Comment 42

[Ben Bucksch (:BenB)]

Comment on attachment 380540 [details] [diff] [review]
overflow hidden thing

I agree.
r=BenB
(I'm the author of the code, and it's technically not mailnews, so I think I'm the best to review.)

If the bug 39098 ever gets fixed, and changes behavior here, we can still find another solution. Even during that time span, it is not harmful either, as it would just show the ^ that was in the original mail.

Comment 43

[John Pye]

This bug is still present in 2.0.0.22.

Comment 44

[Mark Banner (:standard8)]

As this is really a core bug, let's get it in a core component for proper tracking (especially if you want to try and get it into a branch).

Comment 45

[Ben Bucksch (:BenB)]

I don't think this is backport fudder.

All the mozTXTToHTMLConv bugs are in Mailnews Core, because that's where people look for them, because TB is the main / most prominent user.

Comment 46

[Neville Hillyer]

Here is an update for TB 3.1.1 - all platforms.

The bug is still with us and still causing frustration and loss of time, see:
http://forums.mozillazine.org/viewtopic.php?f=39&t=1952783

Here is what I did:

1 - Sent a test message to myself with emoticons off

2 - Took a snapshot of reply - see attached

3 - Turned emoticons on

4 - Took another snapshot of the same reply - see same attached.

Hence the emoticons option toggles the carat display behaviour.

It is a pity that a gismo is allowed to stop TB performing its core task properly.

Perhaps somebody will find a way to fix this soon.

Comment 47

[Neville Hillyer]

Attachment: carat demonstration

Comment 48

[rsx11m]

I'm wondering why this feature is tied to the emoticons settings rather than
the mail.display_struct preference, which would be the more logical choice as
it's on the level of smart display of plain-text pseudo formats...

(In reply to comment #42)
> If the bug 39098 ever gets fixed, and changes behavior here, we can still find
> another solution.

That was checked in per http://hg.mozilla.org/mozilla-central/rev/0c440c656ada thus the patch here shouldn't work any more.

Comment 49

[Ben Bucksch (:BenB)]

> attachment 459889 [details]

Looks nice, thank you.

> I'm wondering why this feature is tied to the emoticons settings rather than
> the mail.display_struct preference

"struct" is for "structural formatting", i.e. bold, italics etc..
The main differentiator I used, however, was that structs do not alter the msg characters, they only add formatting, and do not remove or add chars.
The smileys (emoticons) replace characters.
The ^ superscript removes a character.
So, people who are somehow offended by the idea that we "alter" the msg can disable smileys, but keep structs. Similarly, people who like smileys but have no idea why stars shall mean bold and don't like that idea can disable structs.

Comment 50

[rsx11m]

Thanks, makes sense after reading it, though it's hard to discover that one
has to uncheck the emoticons box in order to get rid of the superscript.

Comment 51

[Günter Rote]

I have no strong opinion about "where" the sub/superscript replacement setting should be located. Perhaps it should be yet another independent setting. This would allow to have it *turned off by default*.
The difference between an emoticon and a ^ or _ sign which has disappeared is that even the casual user will see the emoticon, whereas just "hiding" characters from view is potentially harmful, as mentioned several times above.
(I have no idea how many users would actively switch on the cool m^2 to m² conversion when given the choice.)

Comment 52

[Neville Hillyer]

Please excuse my ignorance of the emoticons/^ discussion below but can somebody explain to a simple Engineer why emoticons have to alter email text content? Is there some other way to satisfy all?

Comment 53

[Ben Bucksch (:BenB)]

Isn't that obvious? Because we replace :-) = : - ) with an image. Obviously, nobody complains about *that*, so people are not being very rational when they argue "don't change the msg".

Comment 54

[Neville Hillyer]

To somebody who uses email without trivial decoration it was not obvious.

Are you saying that there is a conversion list of character combinations to images which is automatically invoked without any warning to users?

If so no wonder users who spent days trying to get to the bottom of their apparent mail corruption are so upset.

Whoever makes such damaging (to TB's reputation) bizarre decisions?

Comment 55

[Ben Bucksch (:BenB)]

Comment on attachment 380540 [details] [diff] [review]
overflow hidden thing

no longer applicable as discussed above (due to bug 39098 being fixed).

Comment 56

[Ben Bucksch (:BenB)]

See comment 40 and comment 38.

Comment 57

[Ben Bucksch (:BenB)]

Comment on attachment 380540 [details] [diff] [review]
overflow hidden thing

Sorry for the confusion. I tested this patch, and it does still work, despite bug 39098 being fixed, so this seems the way to go.

The patch is fine with me, and I'm the author of the source file, but asking biesi to review.

Comment 58

[rsx11m]

>+      "<sup class=\"moz-txt-sup\">"
>+      "<span style=\"display:inline-block;width:0;height:0;overflow:hidden\">"
>+      "^</span>");

This probably still works despite bug 39098 because it's not hiding visibility of the caret but it's just clipping it. Good move in this case. :-)

Comment 59

[Ben Bucksch (:BenB)]

Yes, it does (with c-c/m-c), I just tested it.

Comment 60

[Mark Banner (:standard8)]

Comment on attachment 380540 [details] [diff] [review]
overflow hidden thing

Honza, biesi is apparently not reviewing at the moment, would you be able to review this?

If it needs tests let me know, and I'll see if I can find someone to do some. If there's any existing tests to base it on that you know of, that would be useful as well.

Comment 61

[Honza Bambas (:mayhemer)]

I'll take a look, how urgent this is?

Comment 62

[Mark Banner (:standard8)]

(In reply to comment #61)
> I'll take a look, how urgent this is?

Not urgent, I'm not sure if we'll get it in before 4.0, but IMO it can wait (though I'd like to get it reviewed in reasonable time, i.e. a month tops).

Comment 63

[Mark Banner (:standard8)]

Honza: ping for review.

Comment 64

[Honza Bambas (:mayhemer)]

Comment on attachment 380540 [details] [diff] [review]
overflow hidden thing

Smart.  My tests show there is probably no need for height:0.  Also maybe put opening <sup> after your new <span></span>?  Just remarks, r+ w/o those changes as well.

r=honzab.

Comment 65

[Honza Bambas (:mayhemer)]

About to land this?

Comment 66

[Ludovic Hirlimann [:Usul]]

(In reply to comment #65)
> About to land this?

Who are you asking the question to ?

Comment 67

[Honza Bambas (:mayhemer)]

Probably Mark.  Is any reason NOT to land this?

Comment 68

[Mark Banner (:standard8)]

(In reply to comment #67)
> Probably Mark.  Is any reason NOT to land this?

I think we can land it (I'd actually forgotten about it).

Comment 69

[John Pye]

Please 'land' it!

Personally I would rather see the ^2 --> ² killed, becuase it is cosmetic and demonstrably interferes with 'real work'. There is a unicode superscript-2 character in any case, so this tweak is not even facilitating something that can't be done another way.

Comment 70

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/mozilla-central/rev/44617683f1a5

Comment 71

[[e-mail]]

(In reply to comment #69)
> Personally I would rather see the ^2 --> ² killed, becuase it is cosmetic
> and demonstrably interferes with 'real work'. There is a unicode
> superscript-2 character in any case, so this tweak is not even facilitating
> something that can't be done another way.
It's not just ^2, the code approximately matches this regexp:
/[\da-z\)\]}]^-?\d+(\.\d+)*(?![\da-z])/i
(yes, that * should be a ? but the code isn't that clever)

Comment 72

[Ben Bucksch (:BenB)]

< (yes, that * should be a ? but the code isn't that clever)

You mean we're taking 10^15 as well? That's intentional.

Comment 73

[John Pye]

Seems that we might also be taking x^-333.3.3.31415926538 as well, but not x^3a.

Comment 74

[Ben Bucksch (:BenB)]

> Seems that we might also be taking x^-333.3.3.31415926538 as well

Correct. I didn't care, because I didn't think that would cause problems.

> but not x^3a.

That, in fact, I intentionally didn't take, because it was too likely to be a false positive. E.g. x^a is just as meaningful mathematically, but can just as well mean something else entirely.

In any case, this bug is fixed.

Comment 75

[John Pye]

So I should look out for this fix when Thunderbird 3.4 comes out, is that correct?