Helge Hafting wrote: > I have no idea of compatibility problems. My problem has always been > bugs with multilingual files, such as: > > * Set the document language to something else than the default language > configured in lyx. Notice that some insets either have, or seem to > have, the lyx default language instead of the document language. > Before the patch, this happened only occationally, as 1.4cvs contain > a "imperfect" fix. The cause I believe is that the "lyx default > language" > is consulted in cases where it shouldn't. It should only ever be used > as a default for the document language when creating a new document. > It is apparently used erroneously in some other cases as well. > The patch fixes this, and I hope at least the part that do this goes in.
I agree. > * Selecting lots of text (that includes insets) and changing the language > on the selection has problems. Often, insets is not updated with the > language change, so one have to open each of them and apply the > language change. This is very irritating routine work - iterating > over all > those insets is exactly the sort of thing a computer should be good at. > Feel free to argue over implementation details, but I hope the end > result is that 1.4.0 _will_ change the language of everything inside a > selection. > The patch as-is do that, and it is nice. I have a hard time This is http://bugzilla.lyx.org/show_bug.cgi?id=1973 (it is the same for language, emphasize and any other font attribute). Jean-Marc and Lars decided that this won't be fixed for 1.4.0. Again my opinion: If bug 1973 gets fixed, it should get fixed for all font attributes and language at the same time, not only one or the other. Martins patch fixes this bug for the language case by redefining the semantics of font language in insets (correct me if I understood something wrong). This is the wrong way IMHO, see the patch in bugzilla if you want to know how I think it should be fixed. >>Your fix to not draw the line for insets can probably be very iritating >>for inlined insets (such as specialchar, but I did not try). >>We could use a huge switch (ugly) or yet another virtual inset method, I >>don't know. >> >> > This case was improvement. Sure it can be delayed, but why. Because it has drawbacks, see below. > There is no need for underlining the baseline of a table, for the > table itself is only lines. It has no language, just as a "hfill" have > no language. Table cell contents may have language changes, > and with the patch, they are underlined as they should. So no > need for a table underline, and no need for underlining any > no-text inset. I also think that something should be done here, but if you read Martins latest post then you'll see that the current patch makes things better for tables etc, and worse for quotes and other special characters that are implemented as an inset. Georg
