##// END OF EJS Templates
dispatch: force \n for newlines on sys.std* streams (BC)...
dispatch: force \n for newlines on sys.std* streams (BC) The sys.std* streams behave differently on Python 3. On Python 3, these streams are an io.TextIOWrapper that wraps a binary buffer stored on a .buffer attribute. These TextIOWrapper instances normalize \n to os.linesep by default. On Windows, this means that \n is normalized to \r\n. So functions like print() which have an implicit end='\n' will actually emit \r\n for line endings. While most parts of Mercurial go through the ui.write() layer to print output, some code - notably in extensions and hooks - can use print(). If this code was using print() or otherwise writing to sys.std* on Windows, Mercurial would emit \r\n. In reality, pretty much everything on Windows reacts to \n just fine. Mercurial itself doesn't emit \r\n when going through the ui layer. Changing the sys.std* streams to not normalize line endings sounds like a scary change. But I think it is safe. It also makes Mercurial on Python 3 behave similarly to Python 2, which did not perform \r\n normalization in print() by default. .. bc:: sys.{stdout, stderr, stdin} now use \n line endings on Python 3 Differential Revision: https://phab.mercurial-scm.org/D8339

File last commit:

r30765:eb7de21b default
r45141:02fa5392 default
Show More
footer.tmpl
11 lines | 227 B | application/x-cheetah | CheetahLexer
<div class="page_footer">
<div class="page_footer_text">{repo|escape}</div>
<div class="rss_logo">
<a href="{url|urlescape}rss-log">RSS</a>
<a href="{url|urlescape}atom-log">Atom</a>
</div>
<br />
{motd}
</div>
</body>
</html>