Michael wrote: > > The text/math ambiguity is a major problem for higher-level user > interfaces like Scientific Word. If the user enters \gamma + 1 without > first starting a math formula, then the proper way for the software to > write it is: > > \textgamma \textplus 1 > > instead of > > $\gamma + 1$ but isn't this ambiguity already present anyway in TeX? and those interfaces have to deal with it? E.g., if you write 1+2 without explicitly marking it as a math formula you get a text string 1+2 not $1+2$ or to remind you about the nice little article by Don Knuth years back when he explained that he learned he was misusing the fact that digits in text and math when using CM fonts look the same so that his book Concrete math ended up looking horrible because there digits for text were coming from concrete roman while those in math where coming from the euler fonts. so i see no solution here for such systems other than forcing the user to explicitly mark math as being math. so from that perspective I see no argument against having the possibility to use keys generating 8bit characters to be used in text and math producing different glyphs. my argument why i do not want of offer something like this as a default is that: - it can't be explained which keys will work and which not (okay that is already difficult with claiming only visible ascii can be used in both by default, but the latter is far easier to explain) - we have no reliable solution unfortunately to resolve that \halign problem so far since Donald unfortunately has fail us :-) (so far that is) the first point in my opinion is important enough to make a new set of inputenc files all produce text only results. As long as the second one remains unresolved i do have even qualms about offering something like \DeclareInputTextAndMath for preamble or private packages use since it would mean one would need to explain why in certain situation one can get errors or worse (?) bad/incorrect typesetting results, but i guess for the benefit of languages like Russian or Greek which really do need such a feature it should probably be provided nevertheless. However i still would hope one could find a way to get rid of it somehow. > Nevertheless it seems clear that it would be better to have a separate > hash table for math commands and text commands. So \gamma could have one > definition in math and another one in text without the constant use of > \relax \ifmmode a\else b\fi. This of course is not possible in TeX 3.x; > perhaps in NTS or e-TeX or Omega. but that would not solve the problem either (though I agree it would perhaps be a good extension) since the problem with the \halign really is the timing: you see the \"a under the assumption that you are parsing for text mode so you expand whatever the internal form expands to, eg \OT1-cmd \"\OT1\", then you expand \OT1-cmd which i wont bother to write down here :-) and by the time you reach, say \accent and trigger the template's u-part your original \" is long gone; so if now the u-part puts a $ in front you are too late. frank