It is not very helpful to have 'Added tag %s for changeset %s' and
similar messages translated into different languages when people work
together using different locales.
We now use English strings without support for translations. If
needed, the user can still supply a custom string for most commands.
It is no longer necessary to wrap the docstrings at 70 characters in
the source -- with the reST parser, they are re-formatted to fit the
terminal when shown.
However, wrapping the docstrings at 78 characters makes life harder
for translators because it marks a lot of strings as fuzzy for no good
reason. When un-marking them, the translators would have to examine
each string again and determine if it is merely re-wrapped or if the
content was also changed.
The long lines also introduce very ugly linebreaks in the .po files if
they are processed using the standard Gettext tools without using
something like '--width 85' all the time.
We have always had a left margin of 4 characters -- probably just
because that's how docstrings for top-level functions turn out by
default, but it also looks nice in the built-in help.
The docstrings were wrapped at 70 characters, which is the default for
Emacs. However, this gives a right margin of 10 characters in a
standard 80 character terminal.
I've now wrapped the relevant docstrings at 78 characters, effectively
killing the right margin. The asymmetric margins looked a bit odd and
some of the text looked cramped with a right margin, so Dirkjan and I
felt that it was best to remove it entirely. The two character gap was
kept to have some space between the border of the terminal -- it will
also make diffs involving the docstrings fit in a 80 character line.
The code for wrapping a single line of text with a hanging indent was
duplicated in commands and help -- it's now moved to a new function
called wrap in util.
The function defaults to a line width is 78 chars, and this un-wraps
some command line flag descriptions, hence the test output changes.
I found that typical case is that grep target is added at (*) revision
in the tree shown below.
+--- 1(*) --- 3
0
+--- 2 ------ 4
Now, I expect 'hg grep --all' to show only rev:1 which is first
appearance of target line.
But 'hg grep --all' will tell:
target line dis-appeared at 3 => 4
target line appeared at 2 => 3
target line dis-appeared at 1 => 2
target line appeared at 0 => 1
because current 'hg grep' implementation compares not between target
revision and its parent, but between neighbor revisions in walkthrough
order.
I checked performance of this patch by "hg grep --follow --all
walkchangerevs" on whole Mercurial repo, and patched version could
complete as fast as un-patched one.
The intent is to fix many issues involving patching when win32ext is enabled.
With win32ext, the working directory and repository files EOLs are not the same
which means that patches made on a non-win32ext host do not apply cleanly
because of EOLs discrepancies. A theorically correct approach would be
transform either the patched file or the patch content with the
encoding/decoding filters used by win32ext. This solution is tricky to
implement and invasive, instead we prefer to address the win32ext case, by
offering a way to ignore input EOLs when patching and rewriting them when
saving the patched result.
