On Fri, Sep 09, 2016 at 07:05:52AM +0000, Guenter Milde wrote: > > 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.
These are opinions. Mine is different. > >> * 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, http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg149849.html > I would appreciate if you could fix it. > See http://www.lyx.org/trac/ticket/9616 This is your hitch. I am not motivated in scratching it. > >> 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 ;-) As everyone else, me thinks. The point is how much important are those use cases? > >> > 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: Sorry, it works for me. Check what is wrong on your part. > 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 TL;DR All I can say is: show your patch implementing your proposals, otherwise stop hindering development, please. Tell me how much time you think it will take you. One month? Two months? Three months? I'll wait for that time. -- Enrico
