Am Freitag, den 19.07.2019, 17:01 +0200 schrieb Jean-Marc Lasgouttes: > > I would really have LyX respecting my defaults.lyx settings. If > > defaults.lyx does not exist, the GUI language (or keyboard > > language, if > > we can make it work under Linux) can be used as a fallback rather > > than > > English. > > Exactly my thoughts.
Good. > Another thing: currently I use Buffer::getLanguage so that, if one > writes a document partly in British English, having a en_US keyboard > would not be an issue, since the language will change to en_GB if > there > is no en_US in the document. Is it a good idea, or is it > over-engineering in your eyes? I am not sure I can follow, but it would not be good if it would not be aware of language varieties. This is probably a general problem with the approach: if I have selected to write a document in Austrian German (de_AT), I would not want LyX to force German German (de_DE) on me, even if my keyboard would be setup as de_DE. This is why I think it should take the context language/variety of the cursor, as it used to be. I would even say that, rather than the keyboard language setting the document language, the document (context) language should (re)set the keyboard, unless explicitly switched. > If I keep that, I may have to rewrite getLanguage which causes > performance issues in my testing. It should be integrated into > updateBuffer anyway (and toc backend should too, bu this is a > different > story). I see. Wouldn't it be easier then, for now, to get the (explicit) keyboard switching working and do not let the cursor try to be smart? Jürgen
signature.asc
Description: This is a digitally signed message part
