<p dir="auto">I propose to add a new action with a shortcut: <code class="notranslate">Open New Window</code>, which will open a new WT window (a new WT process essentially).</p>
<p dir="auto">I use this often as it is a standard feature of almost all other terminals in other OSes and DEs that I used. I often need to open a new terminal side-by-side with other open terminal windows, in order to view them in parallel (monitor logs with tail -f, work and orchestrate concurrently multiple machines and how they communicate together etc. and I'm sure that are countless other reasons for needing this).</p>
<p dir="auto">Now, the way to open a new window in WT is either to raise my hand from the keyboard to grab (OMG, I know it's not important but I hate doing this) the mouse and hunt-and-peck the terminal icon in the taskbar to middle click it, or open the windows start menu and navigate through a charade of submenus in order to do it.</p>
<p dir="auto">This is frustrating for me, wastes my time and makes me feel that "my hands are tight" while using WT, compared to any other terminal in any other OS that I use which is just a shortcut away taking a only the time of a blink of an eye.</p>
<p dir="auto">Therefore I propose to implement this action and assign a shortcut to it (preferably <code class="notranslate">Ctrl+Shift+n</code>).</p>
<p dir="auto">This bug-tracker is monitored by Windows Console development team and other technical types.  <strong>We like detail!</strong></p>
<p dir="auto">If you have a feature request, please post to <a href="https://wpdev.uservoice.com/forums/266908" rel="nofollow">the UserVoice</a>.</p>
<blockquote>
<p dir="auto"><strong>Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues</strong>. Instead, send dumps/traces to <a href="mailto:secure@microsoft.com">secure@microsoft.com</a>, referencing this GitHub issue.</p>
</blockquote>
<p dir="auto">Please use this form and describe your issue, concisely but precisely, with as much detail as possible</p>
<ul dir="auto">
<li>
<p dir="auto">Your Windows build number:  (Type <code class="notranslate">ver</code> at a Windows Command Prompt)<br>
10.0.17704.1000 (Insider Preview Fast ring)</p>
</li>
<li>
<p dir="auto">What you're doing and what's happening: (Copy &amp; paste specific commands and their output, or include screen shots)<br>
Generally I use WSL and conhost a lot to interface with my Linux servers.. and its experience has become more and more delighting over time, which I really appreciate. One particular issue in the rendering however is that even though I have installed a Powerline patched font that supports all the extra required glyphs, characters like exit status (<g-emoji class="g-emoji" alias="heavy_check_mark" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/2714.png">✔</g-emoji>) or box drawing characters (╭╰) do not display correctly, instead they're just these boxes denoting unrecognized characters in the console. In Chrome Canary on the Windows system itself, they're displayed just fine. An arrow key, and some rounded rectangular-shaped glyphs for drawing. Perfect! So it seems like the fonts are installed and are able to render these characters, but the conhost seems to only rely on its primary font. I don't think that these characters are in Monofur for Powerline directly.<br>
The characters to denote git directory (like  which for some reason in Chrome renders as an up arrow.. strange) do render correctly though, and the proper Powerline fonts have been installed (which makes this related to fonts such as in <a href="https://github.com/Microsoft/WSL/issues/881" data-hovercard-type="issue" data-hovercard-url="/microsoft/WSL/issues/881/hovercard">this issue</a>, but - hopefully - not user error (? Not sure if WSL was able to render Powerline at the time.. probably not but the font used is unclear) as has happened there). Anyway, I really hope that this isn't a duplicate of some issue that I haven't been able to check though.<br>
From tests in PowerShell (where the default Consolas was still set) I was able to confirm that this font supports the aforementioned glyphs but not the Powerline ones. This should support the "conhost doesn't look in other fonts, even though the glyphs are present there" issue.</p>
</li>
<li>
<p dir="auto">What's wrong / what should be happening instead:<br>
As a workaround I <em>could</em> fork and edit this Monofur font to include the glyphs that I need, but that'd be a royal pain in the ass and I really don't want to do it. The only real universal and long-term solution would be for conhost to look for presence of glyphs in other fonts whenever it isn't found in the primary font.</p>
</li>
</ul>
<p dir="auto"><a target="_blank" rel="noopener noreferrer nofollow" href="https://user-images.githubusercontent.com/19938179/42485212-fd0a1c5e-83f6-11e8-8100-88b70909000e.png"><img src="https://user-images.githubusercontent.com/19938179/42485212-fd0a1c5e-83f6-11e8-8100-88b70909000e.png" alt="wsl" style="max-width: 100%;"></a><br>
<a target="_blank" rel="noopener noreferrer nofollow" href="https://user-images.githubusercontent.com/19938179/42485473-07645fe2-83f8-11e8-8ca2-c0317908ebf3.png"><img src="https://user-images.githubusercontent.com/19938179/42485473-07645fe2-83f8-11e8-8ca2-c0317908ebf3.png" alt="powershell" style="max-width: 100%;"></a></p>