manifest: use custom C implementation of lazymanifest This version is actually lazy, unlike the pure-python version. The latter could stand to be optimized if anyone actually wants to use it seriously. I put no work into it. Before any of my related changes on mozilla-central: perfmanifest tip ! wall 0.268805 comb 0.260000 user 0.260000 sys 0.000000 (best of 37) perftags ! result: 162 ! wall 0.007099 comb 0.000000 user 0.000000 sys 0.000000 (best of 401) perfstatus ! wall 0.415680 comb 0.420000 user 0.260000 sys 0.160000 (best of 24) hgperf export tip ! wall 0.142118 comb 0.140000 user 0.140000 sys 0.000000 (best of 67) after all of my changes on mozilla-central: ./hg: perfmanifest tip ! wall 0.232640 comb 0.230000 user 0.220000 sys 0.010000 (best of 43) perftags ! result: 162 ! wall 0.007057 comb 0.010000 user 0.000000 sys 0.010000 (best of 395) perfstatus ! wall 0.415503 comb 0.420000 user 0.280000 sys 0.140000 (best of 24) hgperf export tip ! wall 0.025096 comb 0.030000 user 0.030000 sys 0.000000 (best of 102) so it's no real change in performance on perf{manifest,tags,status}, but is a huge win on 'hgperf export tip'. There's a little performance work that could still be done here: fastdelta() could be done significantly more intelligently by using the internal state of the lazymanifest type in C, but that seems like good future work.

manifest: split manifestdict into high-level and low-level logic The low-level logic type (_lazymanifest) matches the behavior of the C implementation introduced in a5f1bccd. A future patch will use that when available.

manifest: do parsing inside manifestdict contstructor This shape to the code will make using a C implementation of the manifest storage easier.

manifest: move parsing functions up in file These functions are about to change signature and be hidden inside the manifestdict constructor. Doing the code motion now as an isolated change to make things easier to review.

dispatch: offer suggestions of similar-named commands When suggestions are available, we show those suggestions instead of showing some help output.

dispatch: offer near-edit-distance suggestions for {file,rev}set functions Before this patch, when I have a brain fart and type `hg log -r 'add(foo)'`, hg exits and just says add isn't a function, leading me to the help page for revset to figure out how to spell the function. With this patch, it suggests 'adds' as a function I might have meant.

test-revset: add tests for missing function output An upcoming change will slightly alter behavior here. Adding the test now so the output change stands out in the later changeset.

revset: use UnknownIdentifier where appropriate

fileset: use UnknownIdentifier where appropriate

error: add a new UnknownIdentifier error type This will be used by the revset and fileset code to communicate more specific errors to higher levels so that we might be able to offer suggestions about what function might have been similar.

log: display closing-branch nodes as "_" (BC) In plain `hg log` there is no indication that a commit closes a branch. You can use hg log --debug, but this is too verbose. A simple idea copied from thg and other graphical viewers is to display the node for a closing-branch commit as a horizontal line. I think this technically is a BC if we consider the graphlog to be part of the stdout API, but I really can't imagine who the hell is parsing the graphlog to determine information about commits.

manifest: move pure parsing code out of pure This lets us transition more smoothly.