Sat, 27 May 2017 17:58:36 +0900 cat: use with statement to close output file
Yuya Nishihara <yuya@tcha.org> [Sat, 27 May 2017 17:58:36 +0900] rev 32583
cat: use with statement to close output file
Thu, 25 May 2017 21:43:09 +0900 cat: stop using makefileobj()
Yuya Nishihara <yuya@tcha.org> [Thu, 25 May 2017 21:43:09 +0900] rev 32582
cat: stop using makefileobj() Prepares for porting to the formatter API. We won't be able to utilize the abstraction provided by makefilename() because formatter must be instantiated per file.
Sat, 27 May 2017 17:44:26 +0900 formatter: add nullformatter
Yuya Nishihara <yuya@tcha.org> [Sat, 27 May 2017 17:44:26 +0900] rev 32581
formatter: add nullformatter This can be used as a placeholder variable.
Sat, 27 May 2017 17:40:18 +0900 formatter: add helper to create a formatter optionally backed by file
Yuya Nishihara <yuya@tcha.org> [Sat, 27 May 2017 17:40:18 +0900] rev 32580
formatter: add helper to create a formatter optionally backed by file To make things simple, openformatter() and maybereopen() have no support for a plain object API. Callers must use the "with" statement. Unlike cmdutil.makefileobj(), append mode ('ab') isn't supported by these functions. This is because JSON output can't be simply concatenated. Perhaps cmdutil.export() will have to build a {filename: [revs...]} map first and write revs per file.
Sun, 18 Jan 2015 18:04:44 +0900 formatter: add option to redirect output to file object
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Jan 2015 18:04:44 +0900] rev 32579
formatter: add option to redirect output to file object Commands like 'export' have --output=OUTFILESPEC option, so we need a way to write formatter output optionally to a file.
Thu, 01 Jun 2017 12:24:16 -0500 merge with i18n stable
Kevin Bullock <kbullock+mercurial@ringworld.org> [Thu, 01 Jun 2017 12:24:16 -0500] rev 32578
merge with i18n
Wed, 31 May 2017 20:42:58 -0300 i18n-pt_BR: synchronized with a0e46f6b248b stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Wed, 31 May 2017 20:42:58 -0300] rev 32577
i18n-pt_BR: synchronized with a0e46f6b248b
Fri, 26 May 2017 13:24:07 -0700 zsh_completion: install as _hg not hg stable
Kyle Lippincott <spectral@google.com> [Fri, 26 May 2017 13:24:07 -0700] rev 32576
zsh_completion: install as _hg not hg The contrib/zsh_completion file itself says to name it _hg. With a name like `hg`, if the user has a line like `autoload ${^fpath}/*(N-.:t)` in their zshrc, it will create a shell function named `hg` that will hide the actual hg command and make hg unusable. Separately from that though, the underscore prefix makes it actually work. The zsh man page states: The convention for autoloaded functions used in completion is that they start with an underscore This does not seem to just be a "convention", though. With the ill-advised line removed from my zshrc and the file named `/usr/local/share/zsh/site-functions/hg` (without the underscore), these completions did not seem to get loaded and the ones from the zsh installation were loaded instead. If I renamed them to be `/usr/local/share/zsh/site-functions/_hg`, however, they were loaded. I manually tested the above statement by starting a new zsh instance with the file in `/usr/local/share/zsh/site-functions` with the following names: - As `hg`, `which _hg_labels` did not show anything - As `_hg`, `which _hg_labels` showed the expected function.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip