If I write $m<n$ in a question, the preview sees the less-than and interprets it as the begining of an XML tag. I have to write it as an HTML entity to get things going. Surely this is not intended?
$\begingroup$ $\endgroup$
Add a comment |
1 Answer
$\begingroup$ $\endgroup$
5 Because TeX is parsed on the client side after Markdown is processed on the server side, and the current behavior is any unsupported HTML tags will be removed on the server side (even they are not closed), so this is indeed the intended behavior.
One simple workaround is to add a space between the < and n.
$m< n$$m< n$
- $\begingroup$ If this is indeed intended behaviour, then the intention should be changed: otherwise this is simply silly. Someone (client side javascript handling the editor/the server/...) should escape the <: expecting the user the use of HTML entities or magical spaces is broken. $\endgroup$Mariano Suárez-Álvarez– Mariano Suárez-Álvarez2010-09-21 16:30:57 +00:00Commented Sep 21, 2010 at 16:30
- 3$\begingroup$ @Mariano: It has been proposed before, but the proposal is ignored because majority of the sites don't have the TeXification phase which makes the code-formatting solution invalid. You may want to bump it if this is important. $\endgroup$2010-09-21 17:42:20 +00:00Commented Sep 21, 2010 at 17:42
- 1$\begingroup$ @Kaestur: Bugs that are a consequence of the incompatible design of two interacting subsystems should not be considered to be "by design" of the whole system. That should be reserved for behavior that is an explicit design decision of the whole system (not a fluke of subsystem interaction). If someone is designing a newer software platform they may wish to ignore "by-design" questions but probably do want to review problems like this when considering new designs. $\endgroup$Bill Dubuque– Bill Dubuque2010-09-25 20:43:54 +00:00Commented Sep 25, 2010 at 20:43
- $\begingroup$ @Bill: I suggested it for sake of consistency with this bug report on meta, which KennyTM marked
status-bydesignwith a similar explanation. I don't have a strong opinion myself on whether this classification is good, but to me, it makes sense to treat both of these bugs the same way. $\endgroup$2010-09-25 21:03:32 +00:00Commented Sep 25, 2010 at 21:03 - 1$\begingroup$ @Kaestur: That too is a similar problem and, as I argued, should not be considered to be "by design". If you wish to collect such bugs into the same class then then a new tag should be created that accurately reflects this category. Writing off bugs as "features" is never a good idea. Having worked heavily on a mathematical software system that evolved over a few decades (Macsyma), I know this from (sometimes painful!) experience. $\endgroup$Bill Dubuque– Bill Dubuque2010-09-26 17:34:01 +00:00Commented Sep 26, 2010 at 17:34