On 2016-09-08, Enrico Forestieri wrote: > On Thu, Sep 08, 2016 at 10:13:27PM +0000, Guenter Milde wrote:
>> On 2016-09-08, Enrico Forestieri wrote: >> > On Thu, Sep 08, 2016 at 04:42:30PM +0000, Guenter Milde wrote: >> >> I don't want blurring the distinction of text-mode and math-mode commands. >> > I don't understand this argument. >> For me (and others), LyX is also a way to learn LaTeX. Typing LaTeX macros >> in LyX that work in LyX but not in TeX is counter-productive in this case. > Come on! If you really put forward that argument I can say that by > looking at the source pane you get the same result. And you have to look > at it, otherwise you can miss that lyx was inserting \ensuremath, for > example, explicitly or not. Yes, for me the hidden insertion of \ensuremath is already a step in the wrong direction. Correcting it becomes more difficult with more "helpfull" additions. >> > If you enter a text-mode command >> > directly in a latex equation, you get the same kind of error. You >> > have to insert it in a proper environment for it to work and you >> > could still do it in lyx. Now, you have to do it for avoiding >> > the error, while, with the patch, lyx will do it for you. >> However, this is inconsistent: >> * if I insert a literal degree-sign from the keyboard into mathed, LyX >> wraps it in \text while inserting, > Yes, this was my doing after you insisted so much that at the end > I surrendered and changed this from the previous behavior of "silently" > wrapping it in \lyxmathsym. I will never do again the same error. This behaviour is in LyX 2.1 and was there already before our discussion started. (It is also "too helpfull" by wrapping any non-ASCII in \text, even if there is a math-expansion in lib/unicodesymbols. If it really was your addition, I would appreciate if you could fix it. See http://www.lyx.org/trac/ticket/9616 >> * if I write \textdegree in mathed, LyX wraps it when exporting (after your >> patch). > Maybe I should go back and reconsider the insertion of the literal > degree-sign in explicit \text. This would be a sensible compromise (see below). >> >> It is far more difficult to restore this distinction after starting to >> >> support commands in the wrong mode with "silent additions". >> > LyX is full of silent additions aimed at avoiding the occurrence of >> > errors. I don't buy the argument that a further inset has to be >> > explicitly inserted. >> Silent "helpers" all too often stay in the way when doing something the >> original author did not think of... > Yes, I agree in principle, but not in this case. Naturally. You are the original author --- not thinking about the use cases you don't think about ;-) >> > If you copy and paste an equation outside of lyx, the >> > "silent additions" are also provided, so they are not so silent. >> Really? With an integral in "mathed text" I got: >> * in the source pane: $A=\text{\ensuremath{\int}d}x$ >> * copying the complete mathbox: A=\text{\ensuremath{\int}d}x >> * copying from inside the math-box: \text{\int d}x > This is really strange. I did the same, progressively reducing the > selection from outside to inside I obtain: > 1) A=\text{\ensuremath{\int}d}x > 2) =\text{\ensuremath{\int}d}x > 3) =\text{\ensuremath{\int}d} > 4) \text{\ensuremath{\int}d} > 5) \ensuremath{\int}d > So, it seems that I cannot reproduce. This also depend on the target of the copy. Here, with LyX 2.1 under Linux, I get the follwing: 1. copy the complete mathed box and a) paste in LyX text: the mathed box is duplicated. b) paste in LyX mathed: I get a mathed box that looks the same but \ensuremath is added in the LyX source c) paste in a text editor: \ensuremath is added \text{\ensuremath{\int}} 2. copy from inside the mathed box (this may be all content or just a part of) and a) + paste in LyX text: blue underlined text: \int\text{\int} +1 the content is converted to text. It can be reconverted to math by selecting and pressing Ctrl-M The conversion is helpfull in many instances. It would even be better, if this could be achieved by the usual way to dissolve an inset -- pressing backspace when the cursor is at the first position of the inset. -1 the language of the text is set to "english". This is a bug (which of course only becomes visible in non-English documents). -1 the conversion is no valid LaTeX. b) paste in LyX mathed: the copied content is inserted. Fine. c) paste in a text editor: \int\text{\int} \ensuremath is not added -1 I get invalid LaTeX when copying from mathed to a LaTeX document in a text editor. Also, there is the problem of LyX file format specification. * in the beginning, this was easy: LyX uses LaTeX math syntax inside "Formula" insets. * currently, it would need to be LyX uses LaTeX math syntax inside "Formula" insets with the follwing additions: * Non-ASCII characters are allowed and converted during export according to their expansion in lib/unicodesymbols. * Recognized mathematical commands are also allowed in text-mode and wrapped in \ensuremath during export to latex. For a list of supported mathematical commands, use the source (lib/symbols). * with your patch, it would need to be LyX uses LaTeX math syntax inside "Formula" insets with the follwing additions: * Non-ASCII characters are allowed and converted during export according to their expansion in lib/unicodesymbols. * Recognized mathematical commands are also allowed in text-mode and wrapped in \ensuremath during export to LaTeX and when copying the complete formula inset. For a list of supported mathematical commands, use the source (lib/symbols). * A few recognized text-mode commands are also allowed in math-mode and wrapped in \text during export to LaTeX and when copying the complete formula inset. For a list of supported text-mode commands, use the source (lib/symbols). -1 external processing of LyX files is complicated because of these non-specified exceptions: -1 using a "latex-parser" for the mathematical content can lead to failure. -4 it is very hard to get a list of commands that get the exception as lib/symbols has a mixed ad-hoc syntax. Possible fixes ============== wrapping in the LyX source ************************** +1 copy-paste is consistent. +1 copy is always valid LaTeX. +1 the user gets feedback about valid LaTeX not only in the source pane but also in the status line (when entering the inset). -1 one more nested inset i.e. more cumbersome navigation and selecting. inserting a literal unicode char ******************************** +1 Handling is consistent with the current handling of literal non-ASCII characters +1 The file format specification becomes less complicated: LyX uses LaTeX math syntax inside "Formula" insets with the follwing addition: Non-ASCII characters are allowed and converted during export according to their expansion in lib/unicodesymbols. +1 A step towards consolidation of lib/symbols and lib/unicodesymbols removing code duplication +1 A step towards better Unicode use in LyX. Maybe we can get rid of the requirement for "exotic" fonts in mathed. -1 invalid latex-math code in the lyx source (but this is already possible, see the "current file specification" above). Examples/cases: * integral sign in a text-mode inset -0 the look in mathed is somewhat different +1 copy of the complete inset is fine: \text{\ensuremath{\int}} -0 The content of the LyX source and a copy from within mathed is the literal unicode char ∫ -1 invalid with 8-bit LaTeX +1 OK with Xe/LuaTeX and unicode-math * degree sign in math-mode +1 different expansions in text-mode and math-mode, \text{\textdegree} vs. {^\circ} allow adapt the look in the output. While this may be complicated and could change if we decide to remove the substitute math-command from lib/unicodesymbols, the important bonus is consistent handling of ° independent of input as literal character or via \textdegree. +1 copy of the complete inset is fine: {^\circ} -0 The content of the LyX source and a copy from within mathed is the literal unicode char ° -1 invalid in math-mode with 8-bit LaTeX +1 OK with Xe/LuaTeX and unicode-math * \lightning sign in math-mode +1 copy of the complete inset is fine: \lightning -0 The content of the LyX source and a copy from within mathed is the literal unicode char ↯ -1 invalid in math-mode with 8-bit LaTeX -1 also invalid with Xe/LuaTeX and unicode-math Implementation alternatives: a) Any macro in mathed is "relyxed" after completion: 1. replace with literal Unicode, if defined in lib/unicodesymbols 2. use visual representation from lib/symbols else. +1 works for all definitions in lib/unicodesymbols without code duplication -1 exceptions would need to be defined somewhere -1 replacing a macro with more than one character is impossible b) New keyword/syntax variant for lib/symbols that would insert a specified literal Unicode string into mathed. -1 lib/symbols code required for all supported commands +1 behaviour specified in the "mathed definition file" lib/symbols +1 replacing a macro with more than one character possible Günter
