On Sat, Oct 03, 2009 at 11:56:50AM +0200, Jürgen Spitzmüller wrote: > Enrico Forestieri wrote: > > The method was once named textString() and was changed to tocString() > > at http://www.lyx.org/trac/changeset/27378 for (seemingly) unknown > > reasons (maybe due to a wrong comment in src/insets/Inset.h ?). > > I remember that Jean-Marc opted for the renaming. Could it be that we need to > split this method, if it's really used for pasting as well?
It is also used for pasting, so the renaming was inappropriate, apparently. Indeed, it can lead to pitfalls, as in your case. > > The correct patch is to allow for any character in > > InsetMathHull::plaintext. However, this is not the only bug in > > InsetMathHull::plaintext, as if you copy a math inset with an eqnarray and > > try to paste it, you only get the first cell content, and not the whole > > equation. > > > > The attached patch (for branch) fixes both bugs and, as a by-product, > > also bug #2342. > > Is it really correct to assume utf8 in plaintext (after all, other plaintext > methods use the runparams' encoding, so we would get a mish-mash of > encodings, > wouldn't we)? I agree that utf8 is te correct encoding for pasting and > probably also the TOC, but then, wouldn't we have to separate this tocString > method from plaintext? Yes, I really think that utf8 should be assumed for plaintext. We can't get a mish-mash of encodings for the simple reason that the encoding of an odocstream cannot be changed (only the encoding of a file stream can). We should simply rename tocString as textString, IMHO. The only doubt I have is about using either "wi << cell(0);" or "write(wi);". In the first case, eqnarray and similar are not correctly pasted to an external application (and math delimiters are left out). In the second case, this doesn't happen, but when the method is actually used for displaying a TOC element containing math in the GUI, it may be inappropriate showing the latex code. However, using complex math constructs in places that are to go in the TOC is inappropriate, in the first place. Then, there's another thing to take into account. If you select some text with embedded math and then paste it into mathed, using "wi << cell(0);" the math delimiters are left out and everything is treated as math. This can be misleading when you have an eqnarray, as you don't understand what is happening. On the other hand, using "write(wi);", you get the verbatim latex code, and it is clear what happened. But, if you don't have an eqnarray, it may be better to actually dropping the math delimiters... I cannot make my mind about this problem, so i propose to fix the bug about the encoding by using utf8 and to leave things as they are now as regards the eqnarray problem, for the moment. This means fixing #6250, accepting that eqnarrays cannot be pasted into external applications, and leaving unaltered the state of bug #2342. -- Enrico
