[tahoe-lafs-trac-stream] [tahoe-lafs] #1120: simplify Unicode support by assuming that argv and output encodings are the same

[tahoe-lafs]

#1120: simplify Unicode support by assuming that argv and output encodings are the
same
----------------------------+--------------------------------------
     Reporter:  davidsarah  |      Owner:  zooko
         Type:  defect      |     Status:  new
     Priority:  minor       |  Milestone:  1.9.0
    Component:  code        |    Version:  1.7.0
   Resolution:              |   Keywords:  unicode cleanup reviewed
Launchpad Bug:              |
----------------------------+--------------------------------------

Comment (by 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 [attachment: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 :-(

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1120#comment:7>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage