On Sat, Jan 30, 2010 at 3:08 AM, Ville M. Vainio <[email protected]> wrote: > On Sat, Jan 30, 2010 at 8:38 AM, HYRY <[email protected]> wrote: >> I found Leo-4.7 beta2 changed it's default Encoding setting. >> >> Here is the encoding message in log window: >> >> "default encoding cp936 from locale" > > This seems like a bug. We should never use anything apart from utf-8 > unless very explicitly requested by the user.
I think I agree. I have no clue about why there are locale-specific encodings and system default encodings. It would be easy to fix this bug, at least in a naive way. We simply have g.app.setEncoding always return 'utf-8'. And that is what I shall do. But looking at g.app.setEncoding has uncovered a larger issue. The answer to HYRY's question, "So, how can I set app.config.defaultEncoding to UTF8?" is, you can't (!!) Actually, the proper question relates to g.app.defaultEncoding: g.app.config.defaultEncoding isn't used at all except to init g.app.defaultEncoding, and g.app.config.defaultEncoding isn't even used then, because it is always None! The reason that g.app.defaultEncoding can't be set by a user option is "straightforward", though I have not realized until now ;-) Settings always apply to a commander, never (or almost never??) to global settings like g.app.config.defaultEncoding. Or so I say now: the init code in leoConfig.py is incredibly complex: that's what (usually) makes the user settings "just work" But I digress. The real issue is that g.app.config is, no matter how it is set, a wretched default for any purpose whatever. In particular, it is highly dubious for g.toUnicode. I suppose you could say that g.app.defaultEncoding pretends to be a user option, but it isn't. Another "naive" fix would be to replace g.app.defaultEncoding with 'utf-8' everywhere, or almost everywhere. I'm not going to do that (at least for now) because g.app.defaultEncoding serves as a marker for code that might have to change. Let's be clear about the big picture. When reading or writing files, the encoding passed to g.toUnicode (reading) or g.toEncodedString (writing) can depend on the file being read or written. There are several mechanisms in place for specifying per-file encodings. xml files can specify encoding directly. External files that Leo reads and writes can have @encoding directives that get put into the first line of the external files. Rst files can have @rst-option encoding=x options. Python files can start with encoding comment lines. There may be one or two other ways. In all these cases, it seems that 'utf-8' is a reasonable default, and perhaps it is the *only* reasonable default. In short, I consider this a serious bug. This is what I shall do: 1. g.app.setEncoding will always set g.app.defaultEncoding to 'utf-8'. I may leave the log message in for clarity during the transition. 2. I'll review all uses of g.app.defaultEncoding throughout Leo, including plugins, looking for places where using 'utf-8' might ignore per-file encodings that should have been considered, but haven't. Regardless of what happens, I think a b3 release is required asap. Unicode encoding issues are always major bugs. I'll play with this today, and release b3 tomorrow or Monday. That way rc1 would still be on track for Friday. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
