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?)
The question here is, what is "normal use"? Do people normally write
text in one language with lots if little insets in different languages?
If so, protecting those insets makes life easier for them.
But my experience is that language doesn't follow inset boundaries that
well.
So changing language in the text first and then having to alter each
inset as
well seems strange and a lot of work. Work that the computer can do
easy enough
with a loop, if we let it. Which is why I protested. I didn't know that
this could affect the loading of old documents, or put limitations on
what kind
of language changes it is possible to do.
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.
Well, I don't see the connection - other than that this is what can be
done with a reasonably small patch. No matter how 1.4 works internally,
an 1.3 document can always be "fixed" by the converter so each and every
word show up in the same language as it did in 1.3. Unless 1.4 actually
loose ability for some language constellations. Of course, this may
mean extra work on the converter for which there isn't time right now.
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.
I believe what I asked for (or hoped for) was ability to select a range
containing all sorts of stuff and change the language of the lot.
Do that imply that we can't reset part of a foreign-language inset
to document language at all? (I guess one can work around this by
setting the language explicit to whatever the doc language is,
instead of using "revert"?) To me, setting the language through editing
is completely orthogonal to loading an old document.
Seems that this isn't so then, without needing "too much work".
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 ;-)
Substituting a small wrong for a big one is a win :-) It'd be worse
if we broke something error-free.
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.
I'll try to look at it later today.
Helge Hafting
