simplify Unicode support by assuming that argv and output encodings are the same

[davidsarah]

When the changes to support Unicode on Windows (#1074 and #565) are applied, the argv and output encodings will always be the same as each other, on all platforms. Call that the "I/O encoding" and make any consequent simplifications.

[davidsarah]

I have a patch for this, but don't intend to apply it for 1.8.

[davidsarah]

encodingutil: argv and output encodings are always the same on all platforms. Lose the unnecessary generality of them being different. fixes #1120

[zooko]

I reviewed attachment:same-argv-and-output-encoding.darcs.patch​ and while doing so I recorded an equivalent patch using darcs replace. Using darcs replace instead of editing hunks can avoid unnecessary merge conflicts. I confirmed that my patch, attachment:same-argv-and-output-encoding-withdarcsreplace.darcs.patch​, has the same effect when applied to the current trunk.

So, I've reviewed this patch and give it +1. If someone wants to review my darcs replace variant of this patch, that would be cool, or if someone wants to just apply the original patch to trunk that would be cool too.

[davidsarah]

Maybe this is off-topic for this bug, but I'm really confused about the patches that darcs generates when darcs replace is used.

The effect of either patch set is basically to rename [get_]argv_encoding and [get_]output_encoding to [get_]io_encoding, and clean up any resulting duplicated imports and attributes. But in same-argv-and-output-encoding-withdarcsreplace.darcs.patch​, we also have explicit hunks that are either redundant with, or seem to conflict with the replace hunks.

For example, in test_cli.py we have hunks that explicitly change get_argv_encoding to get_output_encoding (not get_io_encoding), and then we also have replace hunks that change both get_argv_encoding and get_output_encoding to get_io_encoding. So why were the explicit hunks needed, and what is the implied ordering or priority when both explicit and replace hunks in a given patch affect the same lines?

There are some hunks that apparently go in the wrong direction, for instance changing get_io_encoding back to get_output_encoding in test_encodingutil.py. But there was no get_io_encoding in the original file, so how can those hunks be applied, even if they were correct? That is very puzzling.

Also, won't the explicit, non-replace hunks still cause conflicts if those lines or neighbouring lines are touched by a patch to be merged -- and if they do, doesn't this partly defeat the point of using darcs replace?

In conclusion, there's too much I don't understand about darcs replace, that makes me lack confidence in reviewing patches that use it. For patches that use only explicit hunks, I can often (not always) review them without actually applying them to see the effects; for replace patches that seems never to be the case :-(

[david-sarah@…]

In f9d218c6736cf389:

encodingutil: argv and output encodings are always the same on all platforms. Lose the unnecessary generality of them being different. fixes #1120

[davidsarah]

I committed the non-darcs replace version of the patch.

[zooko]

I went to report the problem with darcs replace on the darcs bug tracker, and saw that Zancas had ​previously reported the same issue.

[davidsarah]

​Heffalump wrote in #darcs:

darcs applies patches in the order listed.

a replace patch on its own does exactly what it says on the tin - it replaces token A with token B in the file listed

so if you have hunk patches then a replace patch, the hunk patches happen first then the replace

in your example I think force must have been used to do a couple of replace operations. I'm not entirely sure, but perhaps output -> argv was done first then argv -> io, or something like that.

with --force, if you are renaming A to B, then --force first inserts hunks that change any existing Bs to A, then a replace patch from A to B. That's to ensure that everything is invertible.

because darcs tries to squish together individual pieces of patches in a single named patch to avoid redundant operations, I can imagine replace --force twice generting something like you describe.