[win32] non-ascii/non-english file names: internal usage of file names

[Alexander Belchenko]

John Arbash Meinel пишет:
> As far as the "StringIO" can't decode into ASCII, that is something
> we've discussed.
> Basically, there are commands which "must be correct" and commands which
> "shouldn't fail". 'bzr commit' shouldn't fail because it can't display
> the log correctly (hence it should use encode(foo, 'replace')), other
> commands must not succeed with bogus output (possibly bzr diff, anything
> that is writing into a control file, etc.), and those should use the
> default encode(foo, 'error')). We just need to do more explicit encoding
> calls.

I don't understand your thought, sorry.

I'm talk about following code in commit when no message and no file is 
given and need to launch external editor for entering commit message:

         if message is None and not file:
             catcher = StringIO()
             show_status(tree.branch, specific_files=selected_list,
                         to_file=catcher)
             message = edit_commit_message(catcher.getvalue())


In this code show_status unable to print non-ascii filenames to 
file-like StringIO object due to limitation of StringIO.

Later this catched output used as string for passing as argument to 
edit_commit_message(). Probably here we could use real temporary file 
instead of file-like StringIO() to avoid encoding problems. But later in 
edit_commit_message() again created temporary file for editing commit 
message and to latter file will prints (again!) status output. I think 
there is some sort of overhead. Overhead not in execution time but in 
amount of executed actions with similar effect.

Furthermore, lately I send patch (#27) that fix some encodings issues in 
commit and log commands. And I give the example when system encoding and 
console encoding may vary on windows machine (due to backward 
compatibility of windows). That patch need to be taking into 
consideration when above code chunk will be refactored: show_status 
should be encoded by default with bzrlib.user_encoding not with 
sys.stdout.encoding, I guess.

Alexander