Martin Vermeer wrote:
On Tue, 2006-01-31 at 09:09 +0100, Helge Hafting wrote:
Martin Vermeer wrote:
...
Martin> A more serious problem: we do not have an inherit_language. I
Martin> think we should. In LyX as it is in CVS, default_language
Martin> plays this role. With the proposed patch, the role is taken
Martin> over by the buffer language, which is better, but in a way
Martin> just as inappropriate. The roles of buffer language and
Martin> "no-defined-language flag" are mixed up.
Dekel Tsur has always fought against an inherit_language value, on the
ground that a text does have a language and is not supposed to inherit
anything when you do some cut-and-paste. I can see some value in the
argument, but it causes many problems.
Hmmm, if we accept this argument, we could argue that, contrary to font
attributes, inset text should _never_ inherit its language from the
surrounding inset. A _text_ has a language -- the language given to it
by its author -- but an _inset_ has not. But text inside an inset again
has a language -- the one the author chose.
Also my earlier argument that you want to be able to select a piece of
text, insets and all, and change its font attributes, may apply to
italic, bold, etc., *but not language*.
No no no. You're correct in that text has a language of its own, so
one inset pasted into another should *not* suddenly inherit a
different language.
But we definitely want to select an amount of text (possibly with
lots of structure and nested insets) and change the language on all of it.
Think of it. The author writes a document with chapters in
different languages. (Multi-lingual manual perhaps.) Then the
spellcheck fails, and the author realize he/she forgot to set correct
language in the last chapter. The logical solution then, is to select the
entire chapter and do a blanket change of language.
(Think of accidentally changing
Hebrew to French in a collapsed inset. Italicizing isn't remotely as
disastrous, having to do with appearance rather than identity.)
Accidents are what "undo" is for.
If you notice in time (inside a collapsed inset?)
Think of deliberately changing it
because it was written wrong initially. If there are some collapsed
footnotes
in the selection, then they are likely in the same language as the rest.
And when inserting a new inset in the middle of something, then
the new inset is likely in the same language as the surroundings.
So don't revert to document language all the time.
OK... can be done. But the price is, that lyx 1.3 documents will not
always be loaded and rendered faithfully.
If you have a 1.3 doc containing an inset at a location that has a
non-buffer language, containing text in which the language is reset to
the buffer language (which somehow is just possible in 1.3), then upon
loading, the latter font change will silently disappear. Saving makes
the loss permanent. This is due to the buffer language (without my
patch: the default language) doubling as "inherit_language". Under
current architecture, there is no solution to this. Admittedly a corner
case... I posit that we can live with this, provided we warn the users.
That is the bad news. The good news is that without my patch, lyx 1.4
will do even more crazy things with languages and fonts of a 1.3
document -- also without as much as a whimper ;-)
Attached a still slightly simplified patch. Two small things were
dropped which turned out to be unnecessary in further testing. And we
need applyOuterFont after all.
Helge, see if you can live with this one.
Not trying to be difficult, but unfortunately not.
Make a document, set a nondefault document language, type some text.
Insert a footnote, notice that it gets blue line, L-cursor, and the text
inside is in the default language instead of document language. And
it cannot be reset to document language either, although it _can_ be
set to any other language. Ouch!
The same applies to table cells. They are all in "default configured
language"
instead of "document language". Minipages work as they should though,
text inside is in the document language unless I change it.
This language error is only in Lyx' imagination though. Saving the file
shows no "\lang" in the places where the language is wrong.
Seems like the display drawing stuff sometimes consult the configured
language instead of the document language when no particular
language is specified.
So the file is correct, but the display is annoying.
Also, when changing language over a selection, the change is not
propagated into table cells or footnotes. This is an error,
perhaps unrelated.
An oddity:
* Write some text (in the document language), and insert a minipage
in the middle of it. write some text inside the minipage too.
* Mark one word inside the minipage, and change it to a second language.
This works, the word get underlined as expected.
* Mark everything (the whole document) and change to a third language.
Everything is now underlined as it should. But put the cursor in that
special word in the minipage, and see that it is still in the
"second" language.
Weird - because I tried to change everything.
* Select all again, and revert language. Everything goes back to document
language, except for that special word in the minipage. It remains
"second language", and can only be reset by making a selection
inside the minipage.
What exactly happens when I change language on a selection?
Do the minipage simply inherit language for content that
isn't explicitly nondefault? Incidentally, applying "bold"
works the same way: mark a word bold but not the rest.
Then, make a selection that spans the minipage and more.
Apply bold - everything is then bold. Revert bold, and everything
except the special word looses boldness.
My first reaction was surprise, but maybe this is intentional?
If a few scattered words are marked with a different language then
this is probably correct, and a wide-selection change shouldn't
reset them. But it is inconsistent, for scattered words that doesn't
happen to be inside some inset wholly contained in the selection
have no such protection.
This isn't much of a problem, but could be fixed by recursing
into insets when applying a font change.
Footnotes, floats, marginal notes, and tables in a document
with a nondefault language is broken though. Language in the
saved file is ok, but all on-screen indicators (blue line,
and the status bar) get it wrong.
Helge Hafting
