<p dir="auto">Note that this is my understanding, please correct me if I'm wrong.</p>
<p dir="auto">Currently when conhost acts as bridge between kernel and terminal (is in vt mode), both conhost and terminal have a <code class="notranslate">TextBuffer</code>. If there is an API call from app, then conhost executes it as it used to in window mode, possibly altering buffer, but instead of displaying the changes in the window it sends them to terminal via text/vt sequence.</p>
<p dir="auto">While being niffty idea to reuse much code and clever use of polymorphism, I don't think it works so well:</p>
<ul dir="auto">
<li>It requires both buffers and other data to be kept in sync.</li>
<li>When one buffer changes, the other loses context of that change. E.g. when there is a resize (the issue I'm currently most concerned about.), the other buffer deletes its content and writes it anew, which prevents it from keeping track of the character position transitions. And this is very complicated and apparently error prone (<a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="459557345" data-permission-text="Title is private" data-url="https://github.com/microsoft/terminal/issues/1465" data-hovercard-type="issue" data-hovercard-url="/microsoft/terminal/issues/1465/hovercard" href="https://github.com/microsoft/terminal/issues/1465">#1465</a>).</li>
<li>If it's not slow, at least it seems to be. Don't show it to linux users.</li>
</ul>
<p dir="auto">So I suggest that conhost should translate API calls directly to text/vt. I also summize that this was the first obvious idea, but then something... something I'd like to know and potentially conquer.</p>
<p dir="auto">There are problematic API calls that don't have correspondig vt sequence. Like <code class="notranslate">ReadConsoleOutput</code> - it clearly has to access the buffer. So there should be another way of IPC between terminal and conhost, besides the two text/vt pipes. But it would need to be anyway and right now it even exists - signal pipe that currently only sends one type of message: resize event. For performace reasons conhost would probably still cache some data, but not entire text buffer.</p>
<p dir="auto">Maybe buffer could be in shared memory with access from both terminal and conhost?</p>
<p dir="auto">Let's discuss the issues which led us to current design and prevent from the one above. If it is still beneficial, at least leave some spec about this and someone from community 'd be likely to implemement it.</p>
<h1 dir="auto">Environment</h1>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="Windows build number: [Version 10.0.18362.239]
Windows Terminal version (if applicable):  0.3.2142.0"><pre lang="none" class="notranslate"><code class="notranslate">Windows build number: [Version 10.0.18362.239]
Windows Terminal version (if applicable):  0.3.2142.0
</code></pre></div>
<h1 dir="auto">Steps to reproduce</h1>

<p dir="auto">Pressing AltGR + 2/3/4/7/8/9/0/+ (number row) - and possibly other key combinations requiring AltGR does not seem to bite on the terminal. For instance, getting the "at" sign "@", we usually press AltGR+2 or CTRL+ALT+2 to write it, but terminal does not recognise both of these ways.</p>
<h1 dir="auto">Expected behavior</h1>
<p dir="auto">I was hoping to print out special letters very often needed in the terminal.</p>
<h1 dir="auto">Actual behavior</h1>
<p dir="auto">Nothing happens, nothing shows up, not even prints of weird character codes. Just no response.</p>