The list parser is complex and reusable without ui. Let's move it to
config.py.
This allows us to parse a list from a "pure" config object without going
through ui. Like, we can make "_trustusers" calculated from raw configs,
instead of making sure it's synchronized by calling "fixconfig"s.
man(1) behaves as poorly as Mercurial without this change. This cribs
from git's run-command[0], which has a list of characters that imply a
string that needs to be run using 'sh -c'. If none of those characters
are present in the command string, we can use shell=False mode on
subprocess and get significantly better error messages (see the test)
when the pager process is invalid. With a complicated pager command
(that contains one of the unsafe characters), we behave as we do today
(which is no worse than git manages.)
I briefly tried tapdancing in a thread to catch early pager exits, but
it's just too perilous: you get races between fd duping operations and
a bad pager exiting, and it's too hard to differentiate between a
slow-bad-pager result and a fast-human-quit-pager-early result.
I've observed some weird variation in exit code handling in the "bad
experience" case in test-pager.t: on my Mac hg predictably exits
nonzero, but on Linux hg always exits zero in that case. For now,
we'll work around it with || true. :(
0: cddbda4bc8/run-command.c (L201)
Our source loader was errantly turning this --debugger into a bytes,
which was then causing me to still get a pager when I was using the
debugger on py3. That made life hard.
This is a step towards fixing extension load warnings on Python
3. Note that I suspect there are still some bugs in this area and that
things like color won't work, but the code at least executes and
prints text to the console correctly now.
Since we're working on bytestrings, we have to use [offset:offset+1]
to get consistent behavior on Python 2 and 3. I've only tested the
_parse_plain closure, not the _parse_quote one, but I have no real
reason to expect the latter to be broken since the fixes were fairly
mechanical.
Default-push has been deprecated in favour of default:pushurl. But "hg clone" still
inserts this in every hgrc file it creates. This patch updates the message by replacing
default-push with default:pushurl and also makes the necessary changes to test files.
Until callsites are updated, this will have no effect. Once callsites
are updated, specifying experimental.editortmpinhg will create editor
temporary files in a subdirectory of .hg, which will make it easier
for tool integrations to determine what repository is in play when
they're asked to edit an hg-related file.
Care needs to be taken to prevent leaking potentially sensitive environment
variables through hgweb, if template support for environment variables is to be
introduced. There are a few ideas about the API for preventing accidental
leaking [1]. Option 3 seems best from the POV of not needing to configure
anything in the normal case. I couldn't figure out how to do that, so guard it
with an experimental option for now.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-January/092383.html
readline() returns '' only when EOF is encountered, in which case, Python's
getpass() raises EOFError. We should do the same to abort the session as
"response expected."
This bug was reported to
https://bitbucket.org/tortoisehg/thg/issues/4659/
This dictionnary is affected by the content of the config, so we should have
one for each ui config.
We rename the global dict to '_baseterminfoparams' to make the situation
clearer.
Since a33895509ccb changed the signature of ui.system(), chgui.system()
should have been updated. This patch factors out the util.system() call
so that chg can override how a shell command is executed.
Before this changeset, the value was carried by the class to work around
limitation of the extensions initialisation. Now that the initialisation is
cleanly handled in 'dispatch', we can drop this work around.
This is similar to what we needed for 'write', we move the logic from the
extension to the core class. Beside the dispatch to 'win32print', we just apply
label to the argument.
That subcall to 'self.write' is never doing actual write but only store things
in buffers. So we do not need to protect it for exception not to time its
execution.
This will make it easier to extract a '_write_err' function as we did for
'write'.
One more step, the support for writing color is not directly in core. No
behavior change for the default case ('_colormode' = None).
Here are the details of what we have to change to the core method:
* apply to 'self.label' to input in the buffered case
* dispatch to 'win32print' when applicable
* apply to 'self.label' to input when applicable
We are about to add some extra logic related to color. That logic will need to
access the low level layer of ui doing the actual write to a stream. (eg:
'win32print'). We extract this logic into a private method for this purpose.
This bring us closer to supporting color in core natively. Core already have a
'label' method that was a no-op. We update its to call the new 'colorlabel'
function. Behavior is unchanged when colormode = None.
Having all 'ui' objects aware of 'color' allows us to update the core code to
handle color. The mode will stay 'None' in the default case so that will not
introduce any changes.
This closes the last feature gap other than the attend list from the
extension. For now, I'm leaving the attend list in the extension,
because I'm unsure it has merit in a world where commands have been
updated to take advantage of the modern API.
I'm about to add direct paging support to some commands, and as a
result we need a way to communicate from the higher layers of dispatch
that paging is explicitly disabled.
No functionality change.
A previous version of this API had a category argument on
ui.pager(). As I migrated the commands in core, I couldn't come up
with good enough consistency in any categorization scheme so I just
scrapped the whole idea. It may be worth revisiting in the future.
We know that calls to ui.editor() always block on the user's configured editor.
Use a blocking tag that ensures that we don't see a huge variety of editor
options in our logging.
We use a wrapper around Mercurial at Facebook that logs key statistics (like
elpased time) to our standard performance tooling.
This is less useful than it could be, because we currently can't tell when a
command is slow because we need to fix Mercurial versus when a command is
slow because the user isn't interacting quickly.
Teach Mercurial to log the time it spends blocked, so that our tooling can
pick it up and submit it with the elapsed time - we can then do the math in
our tooling to see if Mercurial is slow, or if the user simply failed to
interact.
Combining this with the command duration log means that we can ensure that
we concentrate performance efforts on the things that bite Facebook users.
The perfwrite microbenchmark shifts from:
Linux:
! wall 3.213560 comb 0.410000 user 0.350000 sys 0.060000 (best of 4)
Mac:
! wall 0.342325 comb 0.180000 user 0.110000 sys 0.070000 (best of 20)
before this change to:
! wall 3.478070 comb 0.500000 user 0.420000 sys 0.080000 (best of 3)
Mac:
! wall 0.218112 comb 0.220000 user 0.150000 sys 0.070000 (best of 15)
showing a small hit in comb time, but firmly in the noise on wall time.
We want to log the time Mercurial spends trapped in things outside
programmatic control. Provide a mechanism to give us both command runtime
and as many different sources of blocking as we deem useful.
Before this change, urllib2 was brought in when constructing the ui object, and
that added ~5ms on my Linux workstation to the hg startup time for every
command, bringing the time for 'HGRCPATH=/dev/null hg root' from 46ms to 40ms.
Now, we construct a single proxy object per initial ui creation (so that if the
ui is copied they share the object), but defer the actual instantiation of it
and the import of urllib2 until it's needed.
# no-check-commit
4.2 cannot be expressed with IEEE floating point losslessly, and could
cause test failure on some platform:
File ".../mercurial/ui.py", line 414, in mercurial.ui.ui.configwith
Failed example:
u.configwith(float, s, 'float2')
Expected:
-4.2
Got:
-4.2000000000000002
This patch fixes that by changing the number to 4.25, which can be expressed
by the binary number 100.01.
