i18n: calculate terminal columns by width information of each characters neither number of 'bytes' in any encoding nor 'characters' is appropriate to calculate terminal columns for specified string. this patch modifies MBTextWrapper for: - overriding '_wrap_chunks()' to make it use not built-in 'len()' but 'encoding.colwidth()' for columns of string - fixing '_cutdown()' to make it use 'encoding.colwidth()' instead of local, similar but incorrect implementation this patch also modifies 'encoding.py': - dividing 'colwith()' into 2 pieces: one for calculation columns of specified UNICODE string, and another for rest part of original one. the former is used from MBTextWrapper in 'util.py'. - preventing 'colwidth()' from evaluating HGENCODINGAMBIGUOUS configuration per each invocation: 'unicodedata.east_asian_width' checking is kept intact for reducing startup cost.

util: wrap lines with multi-byte characters correctly (issue2943) This re-introduces the unicode conversion what was lost in d320e70442a5 5 years ago and had the comment: To avoid corrupting multi-byte characters in line, we must wrap a Unicode string instead of a bytestring.

encoding: use getattr isntead of hasattr

setdiscovery: fix hang when #heads>200 (issue2971) When setting up the next sample, we always add all of the heads, regardless of the desired max sample size. But if the number of heads exceeds this size, then we don't add any more nodes from the still undecided set. (This is debatable per se, and I'll investigate it, but it's how we designed it at the moment.) The bug was that we always added the overall heads, not the heads of the remaining undecided set. Thus, if #heads>200 (desired sample size), we did not make progress any longer.

ui: also swap sys.stdout with self.fout in _readline In 17ffb30d9174, _readline was changed to output a space using raw_input and this was done using sys.stdout directly, not self.fout. This change broke the command server for JavaHg since it (and other clients) would see a spurious ' ' on stdout and interpret this as an unknown channel.

merge with stable

Added signature for changeset d629f1e89021

Added tag 1.9.2 for changeset d629f1e89021

util: postpone and reorder parent calculation in makedirs

atomictempfile: make close() consistent with other file-like objects. The usual contract is that close() makes your writes permanent, so atomictempfile's use of close() to *discard* writes (and rename() to keep them) is rather unexpected. Thus, change it so close() makes things permanent and add a new discard() method to throw them away. discard() is only used internally, in __del__(), to ensure that writes are discarded when an atomictempfile object goes out of scope. I audited mercurial.*, hgext.*, and ~80 third-party extensions, and found no one using the existing semantics of close() to discard writes, so this should be safe.