On Mon, 2006-01-30 at 15:44 +0100, Jean-Marc Lasgouttes wrote:
> >>>>> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> >> swedish if the inset is one with noFontChange() == true, else
> >> norwegian. At least I think that it works like that.
>
> Martin> Yes, that's how I think it *ought* to work. What else is
> Martin> noFontChange for.
>
> If I may object, noFontChange has not be designed for that at all :)
> Originally, it was just supposed to tell that you could not put the
> inset latex code into a \textbf{}, for example (imagine a figure float
> with a paragraph break in there). It was just supposed to describe
> LaTeX output peculiarities. Now it has grown into something else, but
> I am not sure what.
>
> 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*. (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.)
There is a logic and consistency to this viewpoint. If we accept it, we
have to completely leave out the stanza
if (font.language() == bufferFont().language())
font.setLanguage(font_.language());
from applyOuterFont. Then the answer to the above question will be
"always Swedish."
Hmmm... I kind of take a liking to that viewpoint.
- Martin
PS. Are we going to do anything with this for 1.4.0?
signature.asc
Description: This is a digitally signed message part
