On Wed, Feb 01, 2006 at 07:21:03PM +0200, Martin Vermeer wrote: >> > 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. > > If only it were so simple... you don't want to know what really goes > on... nothing like recursion, rather a bitstring operation between inside > and outside fonts. And the language attribute being handled separately, > wrong or not at all.
Ok, lets leave that part for a later version. > > > 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 > > Try the above, works for me. Or wait for a *really* carefully produced > patch Real Soon Now. Think I have to wait for that patch, for this didn't change anything at all. footnotes, margin notes and table cells still believe they are in "lyx default language" with blue line, L-cursor and language indication on the status line. But of course they are not - there are no language changes in the .lyx file. So a correct file is produced, but the display is all wrong. Do you have diskspace enough for two source trees? I have found that doing so helps in testing patches, especially in cases where the "work" tree is full of unrelated stuff. Just check out cvs in the "test" tree, apply a single patch and do a quick test of the basics. I'll keep testing these patches of course. But the "wrong" patches delays the process a lot - not that they cause much extra work, but we don't always work at same time so each mistake means another day. Looking forward to that carefully made patch. :-) Helge Hafting
