949066 - Plain-Text Markup Should work even if the first or last character of the string is numeric (consider removing special-casing of alphabetical text in structs entirely, i.e. render all structs formatted irrespective of their inner text)

Status: RESOLVED WONTFIX

(Thunderbird :: General, defect)

Description

[David E. Ross]

Attachment: Fragment of a newsgroup posting demonstrating the problem.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Plain-text markups include the following:
*ABCDE* to display ABCDE in bold
/ABCDE/ to display ABCDE in Italics
_ABCDE_ to display ABCDE underlined

This does not work when the enclosed character string is all numeric.  See the attachment for an example.

Comment 1

[Magnus Melin [:mkmelin]]

It's intended, because math equations would be messed up.

Comment 2

[David E. Ross]

This is actually another example of bug #106028.

Comment 3

[Simon Montagu :smontagu]

This isn't a dupe of bug 106028. This is a request for a change in the syntax of structured plain text, but bug 106028 is a bug in the current implementation.

Comment 4

[Simon Montagu :smontagu]

Some comments from bug 106028 that belong here:

--- Comment #53 from David E. Ross <[e-mail]> 2013-12-14 19:12:51 PST ---
This bug actually applies only when either the first or last character of the
string is not a "Western" alphabetical character.  Thus, while the problem is
seen for the string überhaupt, it is not seen for the string xüberhaupt.  

The problem also appears when the first or last character is numeric or a
"special" character.  Thus, the problem appears with the following character
strings:  
  12345
  1b2c3d4e
  a1b2c3d4
  $1b2c3d4e
  a1b2c3d4#
but not with a1b2c3d4e.  

It was argued in a comment to bug #949066 that the handling of numeric
characters -- not applying the markup -- is not a problem, that it is
intentional so as not to affect mathematical equations.  That argument is
invalid.  My degree is in mathematics.  There are many equations and formulae
that have alphabetic terms without any numeric characters.

--- Comment #55 from Thomas D. <[e-mail]> 2013-12-15 03:11:56 PST ---
Created attachment 8347713 [details]
Testcase1.eml: Structs vs. Maths (showing that numbers should just be formatted
like any other structs)

Per Bug 949066 Comment 1, plain numbers in structs (more precisely, struct text
content where 1st character is numeric) are intentionally not formatted because
> math equations would be messed up.

(In reply to David E. Ross from comment #53)
> That argument is invalid.
+1

Testcase1.eml tries this hypothesis, and proves it wrong:

The only valid, numerical struct...
123 *345* 678
...can never be correct mathematical syntax (wrong spacing), so it should just
be formatted like any other alphabetical character struct (this bug).

Otoh, correct mathematical syntax will never be formatted as a struct (wrong
spacing again, correctly not recognized as a struct):
123 * 345 * 678
123*345*678
That's valid mathematical syntax, but not a valid struct - no problem again.

--- Comment #56 from Thomas D. <[e-mail]> 2013-12-15 03:43:11 PST ---
(In reply to Thomas D. from comment #55)

I've already shown in attachment 8347713 [details] that "structs vs. maths" is a myth, so
e.g. *123* should just be formatted bold the same way we format *foo*. This has
major implications on how we fix this bug, so let me add some more arguments
before conclusions:

Arguments supporting that numerical structs *123* should be formatted like
alphabetical structs *foo*

1) Valid struct syntax like *123* around numbers will always be invalid maths
syntax (wrong spacing, see attachment 8347713 [details]), so formatting that is perfectly
ok.

2) Valid maths syntax like 123 * 456 * 789 is always invalid struct syntax, so
it will not be formatted anyway (because it's not recognized as a struct,
regardless of alphabetic or numerical content). So again, no special rules for
numbers required.

3) Suppose there would be valid maths syntax that is also valid struct syntax,
and we'd actually format the number to be bold or italics - still no big deal:
When TB message reader displays a struct like 123 *456* 789 (invalid maths
syntax), the struct characters (*,/) are always preserved, so any potential
mathematical equation would still be correctly printed, albeit with a little
formatting - where's the problem?
You can even copy that and paste without formatting, or paste into text editor,
or paste into word and just remove formatting. No big deal.
But anyway, unless shown otherwise, this is hypothetical and cannot occur.

4) How likely is it for users to send mathematical equations in a plaintext
message, given that there are dozens of tools out there to produce nice
graphical equations with proper display of fractions etc.? Sorry, but imho the
scenario of mathematical equations in plaintext emails belongs to the realm of
plaintext myths, of which there are far too many around TB, and mostly told by
the very same few plaintext lovers against better evidence. Times have changed.
Mathematical equations are much more likely to be found in appropriate file
attachments.

5) On the other hand, given 1), there's actually a pretty high chance that
numerical structs like *123* are intentionally used as structs by those users
who actually use structs. So for that much more plausible scenario, we
currently fail (this bug), which is also ux-inconsistent because there's just
no convincing reason why number structs should not be formatted.

q.e.d.

--- Comment #57 from Thomas D. <[e-mail]> 2013-12-15 04:59:35 PST ---
(In reply to Thomas D. from comment #56)

> Arguments supporting that numerical structs *123* should be formatted like alphabetical structs *foo*

(In reply to David E. Ross from comment #53)
> There are many equations and formulae that have alphabetic terms without any numeric characters.

6) Given that many mathematical equations and formulae use alphabetic terms
(even without any numeric characters), current algorithm (if it were applicable
to valid maths, see 1) would only exclude a small and rather random subset of
mathematical expressions from formatting by structs (why numbers only?). That's
also ux-inconsistent. Assuming we'd rather keep structs than cater for
*invalid* maths syntax (see 1), again, structs win because excluding only one
half (or less) of mathematical expressions would not make much sense.

--- Comment #58 from Thomas D. <[e-mail]> 2013-12-15 05:06:14 PST ---
This bug violates ux-consistency as explained in comment 53 to comment 57 for
numeric structs like *123*, and by analogy, for structs with leading/trailing
international or special characters, too - no reason to exclude such structs
from formatting.

--- Comment #59 from Thomas D. <[e-mail]> 2013-12-15 12:02:13 PST ---
(In reply to Thomas D. from comment #56)
> I've already shown in attachment 8347713 [details] that "structs vs.
> maths" is a myth, so e.g. *123* should just be formatted bold the same way
> we format *foo*. This has major implications on how we fix this bug

As shown in testcase1.eml, attachment 8347713 [details], comment 56 and comment 57,
it's wrong and unnecessary to ignore structs with leading/trailing numeric
character (e.g. *123* or *10EUR* or *EUR 10*) and treat them differently from
alphabetical structs (e.g. *foo*).

Per this bug, it's also wrong to ignore structs with leading/trailing
international/special characters (e.g. *écriture*, *$1 US*, *13 Ιαν*) and treat
them differently from simple ASCII alphabetical structs (e.g. *foo*).

*** Conclusion (wrt fixing this bug): ***

For formatted rendering of structs, the type of the leading/trailing character
of the inner text is irrelevant. We can just remove the entire special-casing
of alphabetical characters vs. numeric characters, and render all structs
correctly formatted as they occur, regardless of the character type of the
first or last character. (I can't think of any leading/trailing character that
should cause the user's struct formatting intention to be ignored, can you?)

So we no longer need complicated functions like isUnicodeAlpha() to verify the
nature of leading/trailing characters inside structs; iow, this bug no longer
depends on Bug 415209.

As a nice side-effect, removing the special-casing of numeric characters,
currently realized as incomplete special-casing of alphabetical characters,
will also simplify the code and improve performance. And we'll allow our
international users to enjoy Ben's struct algorithms.
Looks like a win-win for everyone. :)

--- Comment #60 from David E. Ross <[e-mail]> 2013-12-15 14:20:14 PST ---
I have also determined that at least some special characters (e.g., $, #)
appearing first or last in a string cause the markup to be ignored.  Thus, the
problem is seen with the following despite the fact that the first and last
alphanumeric characters are alphabetic and not numeric:  
  *a1b2c3d4e$*
  *a1b2c3d4e#*
  *$a1b2c3d4e*
  *#a1b2c3d4e*
I decline to test other special characters.  

I must concur with the conclusion stated in comment #59, especially the
sentence:  
> For formatted rendering of structs, the type of the 
> leading/trailing character of the inner text is irrelevant.

Comment 5

[Ben Bucksch (:BenB)]

See comment 1

Comment 6

[Thomas D. (:thomas8)]

(In reply to Ben Bucksch (:BenB) from comment #5)
> See comment 1:
> > It's intended, because math equations would be messed up.

Ben, pls read comment 4 with extensive proof why one-line comment 1 does not apply, confirmed by a person with a degree in mathematics so he surely must know.

Unless you can show the maths equations this will mess up, and how exactly they are "messed up", this is a bug, and many users have complained about this ux-inconsistent behaviour, as seen on twin bug 106028.

Comment 7

[Ben Bucksch (:BenB)]

First off, Thomas D., please do not reopen a bug that a developer closed.

This bug is too broad, and would lead too many false positives, and will not be fixed.

We can discuss about numbers, in another bug.

Comment 8

[Ben Bucksch (:BenB)]

I've filed bug 950605 about digits.

Comment 9

[Ben Bucksch (:BenB)]

xref bug 950606 to recognize *less* special characters than we do now.

Comment 10

[Thomas D. (:thomas8)]

(In reply to Ben Bucksch (:BenB) from comment #8)
> I've filed bug 950605 about digits.

The logic of filing a new bug for the very same issue of this bug completely escapes me, given that
- the entire discussion about digits is documented in bug 106028 and here
- just tweaking two words of this bug's summary could have morphed this bug back into its original intention concerning digits in structs:
Plain-Text Markup Should work even if the first or last character of the string is /numeric/
- briskly closing bugs with a two-liner and without further input from anyone except Ben himself, nor any further discussion, does not look like a nice, wise, and cooperative way of handling real user problems and find creative, and balanced solutions to these ux-problems

Comment 11

[Thomas D. (:thomas8)]

(In reply to Ben Bucksch (:BenB) from comment #7)
> First off, Thomas D., please do not reopen a bug that a developer closed.

Dear Ben, pls look at my bmo profile and activity log, to see that we are working very much on the same level as long-term experienced volunteer contributors, and that I know exactly what I'm doing in bug triage, and why some of the general rules like "don't reopen closed bugs" do no longer apply to me for those very few cases where I actually reopen closed bugs when there's extensive evidence that they have been closed prematurely. Interestingly, premature closure often involves bugs concerning code that you wrote. And fwiw, given that I've both written and practically reviewed code which has landed in TB, I'm also a developer albeit on a limited scale so you've obviously done more coding in terms of quantity and sophistication (while I've done more bug triage in TB). Let's just say that TB is now a volunteer team effort, and you are just another experienced volunteer contributor like me (albeit with different focus), so let's be cooperative and listen to what our users and other contributors have to say in a respectful and open-minded way.

Comment 12

[Thomas D. (:thomas8)]

> This bug is too broad, and would lead too many false positives, and will not
> be fixed.

These are the so-called "false positives" that Ben is talking about:

(In reply to Ben Bucksch (:BenB) from comment bug 106028, comment 63)
> I *do not* want numbers or other special symbols after * to be recognized as
> structs. There is a too high risk of false positives, e.g. in ASCII art or
> other strings of special characters.

a) Can you please provide real-life testcases where structs formatting would "break" ASCII art?
b) Can you please provide examples of false positives from "other strings of special characters"?

Imho, ASCII art is a complete non-argument, and I'll explain why.

Arguments why the usecase of ASCII art is irrelevant for this bug (request to render structured plaintext formatting without looking at the type of the first character of struct's inner text, for the sake of ux-consistency):

1) For users of plaintext email, how frequent is the scenario of sending ASCII art in the main message text, compared to sending structured plaintext in the message text? Here's my estimate:
ASCII art: 3%
Structured plaintext: 97%
It's very likely that users of plaintext messages use structured plaintext, but I don't believe there's any significant number of such users who'll send ASCII art anywhere near that frequently.
Iow, scenario of ASCII art is an edge case of an edge case so the occurence of that scenario is insignificant, and scenario of structured plaintext occurs far more frequently in real life (see 18 duplicates of bug 106028).

2) The technical probability of structured plaintext actually "breaking" ASCII art is very low.
That ASCII art would need to exactly use the very few patterns that we currently recognize as structs. Again, pls provide testcases or examples. And I'm not aware that TB has a defined feature of "rendering ASCII art unformatted in message viewer", but we do have an explicit and useful feature of "rendering structured plaintext formatting".

3) Following that logic, rendering *any* structured plaintext has the potential of breaking ASCII art, so TB's current algorithm should already expose that problem. ASCII art consists of well - any ASCII characters, including alphabetical. So any struct around alphabetical characters might, in theory, "break" ASCII art. Only that it doesn't happen in real life, and almost nobody would care even if it did. If structs would actually "break" ASCII art for any significant number of users or scenarios, I'm surprised we do not have a single bug complaining about that.
In line of such arguments, we would have to abolish the entire feature of structs recognition to ensure that ASCII art in message body is always preserved exactly. Nonsense.

4) For small sketches of ASCII art, users will know which structs can spoil it. For big pictures rendered as ASCII art, they are probably better off in their own text file attachment anyway (which might help to ensure rendering fixed-width, whereas for plaintext messages with ASCII art, most of today's mailers will render that variable width, which will distort the ASCII art anyway).

5) There's certainly more, if we think a bit harder.

So there's evidence that the main reason for closing this bug wontfix does not apply or at least is still under discussion, and I've provided further important evidence to that end.

In my capacity as one of TB's main long-term bug triagers, I will therefore reopen this bug for public discussion so that we can clarify this further rather than closing prematurely. Furthermore, as explained in comment 10, bug 950605 does not add any value over this bug (on the contrary), so for all practical purposes of efficient bug management, bug 950605 is a duplicate of this bug. There is no point in starting the whole discussion again on yet another bug, just to please Ben.

Ben, pls note that closing this bug again without further discussion will be in violation of the etiquette:

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
> 2. Changing fields
> No whining about decisions. If a respected project contributor has marked a bug as INVALID,
> then it is invalid. Someone filing another duplicate of it does not change this. Unless you
> have further important evidence, do not post a comment arguing that an INVALID or WONTFIX bug
> should be reopened.

I'm a respected project contributor and long-term experienced bug triager and I explicitly mark this bug VALID until further discussion with further important evidence shows otherwise.

Comment 13

[Thomas D. (:thomas8)]

CC Bwinton for UX input - 
Pls read Comment 4 which has extensive evidence why this is useful and required for ux-consistency.

Comment 15

[Blake Winton (:bwinton) (:☕️)]

I'm not entirely sure what sort of input I can provide here, other than having a set of test cases, and what we expect them to turn into, would be awesome.

Also, I strongly suspect that the "maths" argument is already kind of messed up due to things like "5*a*b", and perhaps we want to figure out something better to do there, instead of adding special cases to the struct parsing.

Comment 16

[Thomas D. (:thomas8)]

(In reply to Blake Winton (:bwinton) from comment #15)
> I'm not entirely sure what sort of input I can provide here, other than
> having a set of test cases, and what we expect them to turn into, would be
> awesome.
> 
> Also, I strongly suspect that the "maths" argument is already kind of messed
> up due to things like "5*a*b"

+1. Here's a testcase proving that "maths" vs. "structs" is nothing but a myth:
attachment 8347713 [details]
For further details why maths is irrelevant for structs parsing, see comment 4.

> , and perhaps we want to figure out something
> better to do there, instead of adding special cases to the struct parsing.

+1

Blake, thanks, that's helpful input already, because it indicates the general direction this should take:

Away from the current algorithm of special-casing all sorts of structs parsing on dubious reasons and differentiations that no user will ever understand, towards a unified and consistent UX of struct parsing.

So indeed, while allowing numbers in structs to be rendered with formatting is desirable, it's just half the way. So according to :bwintons input to avoid adding special cases, I'm reopening the discussion to also deal with all those other so-called "special" cases which currently fail, because it's essentially the same discussion.

Here's a simple proposal for "something better" which completely avoids "adding special cases to the struct parsing":

We should just *remove all of the current special casing* which is based on different types of characters in the inner text of structs.

The current algorithm ignores any structs whose inner text starts or ends with so-called "special" characters which are not so special after all, like $, é, numbers, etc. The same characters will be accepted when they are *inside* the text, adding more UX confusion.

Current algorithm:

These structs correctly render bold:
*foo#bar*
*téléphone*
*A4 Sheet*
*bring 10$ plus food*

These similar structs fail:
*#foobar*    leading "special" character (non-alphabetical)
*éléphant*   leading international character (bug 106028 seeks to special-case loads of international characters so that they render correctly)
*4 Sheets*   leading numeric character (this bug)
*10$*        leading numeric plus trailing "special" character

More structs that fail (and Ben wants to make even more of these fail in bug 950606):
*(wtf!)*
*I really hate inconsistent design!*
*Good design needs user input, design principles, good reasons and
cooperation!*
M$ really make *$$$*

Many users complain about these failures (see bug 106028 with 17 duplicates), because there's no apparent reason why these should fail while similar text is rendered correctly (violating ux-consistency).

The most comprehensive and ux-consistent solution is to stop special-casing any text type found in structs, because users have no way of understanding why *foo* works but *123* or *$ 10* fails.
Iow, just always render structured plaintext as formatted irrespective of it's text content.

Which would also simplify the underlying struct algorithm a lot, and improve performance as we'd no longer check for thousands of different alphabetical characters in extended character sets.
Furthermore, it's also in line with user expectations as witnessed in 18 duplicates (filed over a long period of time) of twin bug 106028, including this bug.

Comment 17

[Ben Bucksch (:BenB)]

> we are working very much on the same level

No, we're not. I wrote and own this code. Check bugzilla rules.

When I closed this bug, it was
"Plain-Text Markup Should work even if the first or last character of the string is not alphabetic"
and that *is* WONTFIX.

If you keep making a mess in bugs, by making lots and very long comments, and morphing bugs to different meanings, and reopening bugs that developers closed (all of which you routinely do with a passion and unparalleled conviction and sense of right), I'll get your bugzilla privs revoked, because all of that is making bugs totally useless.

And because you made this bug useless with your spam, it stays WONTFIX. I'm totally sick of it. I've tried see your point and to find a sensible solution in bug 950605, and you're making it totally impossible to have any reasonable discussion, with the way you act. You're bringing me awfullly close to ignoring all Thunderbird bugs, because you're ruining them all, even those where I own the code. No place is safe from you. I've had enough.

Comment 18

[:aceman]

(In reply to Ben Bucksch (:BenB) from comment #17)
> > we are working very much on the same level
> No, we're not. I wrote and own this code. Check bugzilla rules.
Actually I'd like to hear about this more. How much do the devs own any code and where is this written. Thanks.

Comment 19

[Thomas D. (:thomas8)]

(In reply to Ben Bucksch (:BenB) from comment #17)
> > we are working very much on the same level
> 
> No, we're not. I wrote and own this code. Check bugzilla rules.

I know them. And I know the community, and the community knows me, just as they know you.
Ben, you wrote this code, and that's appreciated, but you don't own it in a sense of absolute control and one-man-ownership where you can take all the decisions without consulting the community.
In fact, by submitting your code to Thunderbird, you've probably agreed to some sort of open licencing.
You are not even a module owner in TB - I do not see your name in any of these:
https://wiki.mozilla.org/Modules/MailNews_Core
https://wiki.mozilla.org/Modules/Thunderbird

> When I closed this bug, it was
> "Plain-Text Markup Should work even if the first or last character of the
> string is not alphabetic"
> and that *is* WONTFIX.

That's not just WONTFIX only because /you/ want that.
Bugzilla rules explicitly say that bugs can be reopened when there's new evidence.

I've provided evidence why most of your reasons for wontfix do not apply. On almost all other bugs, people just answer to constructive input from others, and we find a solution in a friendly and open discussion. In your bugs, you are mostly just ignoring what others are saying, and if you don't agree with the general direction of the discussion, you just close the bug without any adequate response to what has been said. 

> If you keep making a mess in bugs, by making lots and very long comments,

Ben, I've told you before, your general wording about my work ("making a mess") is inappropriate and it certainly violates the spirit of bugzilla rules.
I readily admit that some of my comments, especially on "your" bugs, have a tendency of being too long, but long is not wrong in itself. Sometimes long is required to get the details right.
And one-liners a la "this will not be fixed" (because Ben says so) are certainly not helpful to improve Thunderbird.

> and morphing bugs to different meanings,

Morphing bugs is a normal part of bug triaging. Nothing wrong with that, if the reasons are spelled out and it's done transparently based on the actual development in the bug.

> and reopening bugs that developers
> closed (all of which you routinely do with a passion and unparalleled
> conviction and sense of right),

Ben, stop falsely accusing me of "routinely reopening bugs that developers closed". It's just not true. In more than 6 years of bug triage, there's perhaps a handful (5) bugs that I have reopened. I do so only after detailed scrutiny of the topic, and definitely only with extensive reason why. As a matter of fact, I think I've only ever reopened two or three bugs which /you/ closed prematurely because you realized the discusssion was not going /your way/. You are trying to create the impression that I just walk around and randomly reopen bugs. Stop that, it's "abusing people" which is definitely against bugzilla rules.

> I'll get your bugzilla privs revoked,

Ben, I've heard that nonsense from you before, and it's just ridiculous. 
I'm a long-term respected contributor in many areas of Thunderbird including bug triage, ux, developing, mentoring new developers, user support, documentation, etc. Check out my bmo profile and activity log.

Instead of such empty threats, I'd appreciate if you could answer to my arguments on the subject matter which I've so painstakingly prepared so that we can cooperatively discuss the issues at hand with more perspective and without prejudice.

> because all of that is making bugs totally useless.

Wrong tone. No content on the subject matter.
Strangely, I've succeeded to get traction on many age-old bugs (including some of yours), and many people are happy about my work. Just learn to face discusssions and explain your reasons in detail so that they are intellegible to everyone.

> And because you made this bug useless with your spam, it stays WONTFIX. I'm
> totally sick of it. I've tried see your point and to find a sensible
> solution in bug 950605,

I don't see what's sensible about sidelining the existing discussion on the subject matter here and force others to restart from scratch just to please your ego and give you a sense of more control and ownership. Furthermore, your personal bias against that bug is on record.

> and you're making it totally impossible to have any
> reasonable discussion, with the way you act. You're bringing me awfullly
> close to ignoring all Thunderbird bugs,

I sometimes wonder how that might change the working atmosphere on what you consider "your" bugs to the better. But to be fair, given your skills and contributions to Thunderbird, I'd much prefer to cooperate with you and use your coding skills to improve those areas of code that you wrote and know about.

> because you're ruining them all,

Wrong tone, "abuse of people" (netiquette). Suppose I could not get away with 12700+ activities on TB bugs if it was all about "ruining them all". I still need to cut myself shorter, yes.
But open discussion is *crucial* for OSS. It's also actively encouraged in BMO rules:

> Constant and intense critique is one of the reasons we build great products. It's harder to
> fall into group-think if there is always a healthy amount of dissent. We want to encourage
> vibrant debate inside of the Mozilla community, we want you to disagree with us, and we
> want you to effectively argue your case. 

That's exactly what I do. Just be more respectful, respond appropriately and be a bit more patient instead of just brushing things away without sufficient comment and closing down those bugs prematurely, and we get rolling.

> even those where I own the code. No place is safe from you. I've had enough.

It's true that I'm trying to move things in Thunderbird for the common good.
It's also true that I can insist when others ignore important arguments, and some of my comments are too long (especially on "Ben's" bugs, where I feel more need to get the points very clear). I never insist without evidence and detailed arguments for my position.
But I think you're the only one who perceives me and open discussion as a threat.

I've had advice from others that it's better to just walk away from "your" bugs because you are not able to accept open discussion and constructively engage with any other opinion except your own. I've even had advice from others that to get things done, I should just open new bugs about problems in your code and just get them fixed without getting you onboard and in the way. Iow, others are just giving up, which does not mean they agree with you. Unfortunately I'm neither willing nor able to do that, because I strongly believe in cooperative approach for the common good, to improve Thunderbird and ensure its survival. Moreover, I dislike vain arguments without substance and differentiation.

Just for illustration of how intense, critical and constructive cooperation can work, please have a look at bug 521158, which was filed by me and I was one of the main mentors for reviewing patches to provide feedback. It took us 170 comments to land the patch. There was constructive input from several contributors including :bwinton as ux lead. There are long comments of mine. With benefit of hindsight, not all of them are 100% correct, but they were easily corrected because others just picked up the good which was there and added their own input. I presented my arguments for discussion, I insisted sometimes, and I listened carefully. There was compromise on every side. We splitted out other bugs by agreement. Not everybody was happy all the time, but everybody was respectful all the time, and everybody was very happy about the final result which was great because it was created in a truly cooperative and creative spirit, under the assumption that every input is worth serious and open-minded consideration. Which is the exact opposite of WONTFIX without any real discussion, because some developer wrongly assumes that he "owns this code" (comment 17). No you don't.

Comment 20

[Thomas D. (:thomas8)]

I would be interested to hear from Blake how he feels about this:

:bwinton (UX lead) requests test cases for this bug and more input from others to
> figure out something better to do there, instead of adding special cases to the struct parsing.
In line with that, comment 4 suggests to try and remove special casing from structs parsing.

After that, Ben Bucksch just unilaterally closes down this bug and with it the entire existing discussion about it, starting from comment 4.

(In reply to Blake Winton (:bwinton) from comment #15)
> I'm not entirely sure what sort of input I can provide here, other than
> having a set of test cases, and what we expect them to turn into, would be
> awesome.
> 
> Also, I strongly suspect that the "maths" argument is already kind of messed
> up due to things like "5*a*b", and perhaps we want to figure out something
> better to do there, instead of adding special cases to the struct parsing.

(In reply to Ben Bucksch (:BenB) from comment #17)
> > we are working very much on the same level
> 
> No, we're not. I wrote and own this code. Check bugzilla rules.
> 
> When I closed this bug, it was
> "Plain-Text Markup Should work even if the first or last character of the
> string is not alphabetic"
> and that *is* WONTFIX.

Comment 21

[Ben Bucksch (:BenB)]

As the component's author and maintainer, I try to keep a balance between the different viewpoints. This is difficult, because they are all different and often mutually exclusive, but each fiercely held. See e.g. bug 950606 comment 2. I'm trying to maintain a balance between them, not just the people commenting here, but everybody out there. As such, I am under fire from everybody who has a strong opinion about this. In the first years, I tried to discuss these on a rational level, but it was fruitless and just led to more fighting, so I stopped. Nobody can be 100% happy, due to the different viewpoints. I do think that we found a good balance, that most users on both ends of the line are mostly fine with what we do.

I just try to maintain the balance, the component and the relevant bugs. But I can't do that when I'm not respected as able to make decisions and when one person starts an "edit war", no matter who it is.

Comment 22

[Blake Winton (:bwinton) (:☕️)]

Blake is not a community moderator, and kind of wishes you could both figure out a way to get along without flooding his inbox with bugzilla comments.  He also likes talking about himself in the third person.  ;)

Perhaps it would be useful to take the discussion of what markup we want to support to tb-planning, to get opinions from the entire community.  (It would also have the nice side-benefit of resetting the tone of the discussion, to one that's constructive and informational instead of inflammatory and confrontational.)

Comment 23

[Mark Banner (:standard8)]

Ben & Thomas: I think you have both been violating our etiquette, and I would report both of you. I think, however, that you can both do better.

Keeping on-topic within a bug, and having smaller focused bugs, is much easier to deal with, and I agree with Ben's suggestions here for how to handle these bugs.

Like Blake, I think the way forward here is to take the discussion out of bugzilla, and let it be a wider discussion. I would suggest that the introduction to this would be to define (e.g. on a wiki page) the list of what & how we handle (and don't handle) what we have today, and why it has been that way. This could lead into a better more structured discussion about what to change, if anything.