Markdown Notebook Panes #21012

New Issue

claunia · 2026-01-31T07:30:34Z

claunia commented

2026-01-31 07:30:34 +00:00

Originally created by @heartacker on GitHub (Dec 23, 2023).

Pre-requisite: #997

Spec in progress in https://github.com/microsoft/terminal/blob/dev/migrie/s/north-star/doc/specs/NorthStar/Markdown%20Notebooks.md

User Stories

A: The user can perform some commandline action (like wt open README.md), which opens a new pane in the Terminal, with the markdown file
rendered into that pane.

B: Markdown panes have buttons next to code blocks that allow the text of
that block to be sent directly to the adjacent terminal as input.

C: The user can press different buttons to run some subset of all the
commands in the file

C.1: Run all the commands in this file

C.2: Run all the commands from (the currently selected block) to the end
of the file

C.1: Run all the commands from (the currently selected block) to the
next header. (e.g., run all the commands in this section of the doc.)

D: The user can edit the contents of the markdown file directly in the
Terminal.

E: The Terminal could be configured to automatically open a markdown file
when cding to a directory

F: The command for opening a markdown file also supports opening files
from the web (e.g. directly from GitHub)

G: Code blocks in the markdown file are automatically assigned
autoincrementing IDs. The user can perform an action (via keybinding, command
palette, whatever) to execute a command block from the file, based on it's
assigned ID.

H: ...

maintainer notes: original OP below the break

Description of the new feature/enhancement

For many developers, especially embedded developers, they would pre-define many text commands and save them in a text file. If WT can split views and open and display text in one view, we can quickly send the text commands to the terminal. I can send lines, send selected blocks, or send the entire content of the file, and preset some shortcuts.

Proposed technical implementation details (optional)

Originally created by @heartacker on GitHub (Dec 23, 2023). Pre-requisite: #997 Spec in progress in https://github.com/microsoft/terminal/blob/dev/migrie/s/north-star/doc/specs/NorthStar/Markdown%20Notebooks.md > ### User Stories > > * **A**: The user can perform some commandline action (like `wt open > README.md`), which opens a new pane in the Terminal, with the markdown file > rendered into that pane. > * **B**: Markdown panes have buttons next to code blocks that allow the text of > that block to be sent directly to the adjacent terminal as input. > * **C**: The user can press different buttons to run some subset of all the > commands in the file > - **C.1**: Run all the commands in this file > - **C.2**: Run all the commands from (the currently selected block) to the end > of the file > - **C.1**: Run all the commands from (the currently selected block) to the > next header. (e.g., run all the commands in this section of the doc.) > * **D**: The user can edit the contents of the markdown file directly in the > Terminal. > * **E**: The Terminal could be configured to automatically open a markdown file > when `cd`ing to a directory > * **F**: The command for opening a markdown file also supports opening files > from the web (e.g. directly from GitHub) > * **G**: Code blocks in the markdown file are automatically assigned > autoincrementing IDs. The user can perform an action (via keybinding, command > palette, whatever) to execute a command block from the file, based on it's > assigned ID. > * **H**: ... _maintainer notes: original OP below the break_ ---- # Description of the new feature/enhancement  For many developers, especially embedded developers, they would pre-define many text commands and save them in a text file. If WT can split views and open and display text in one view, we can quickly send the text commands to the terminal. I can send lines, send selected blocks, or send the entire content of the file, and preset some shortcuts. # Proposed technical implementation details (optional)  ![image](https://github.com/microsoft/terminal/assets/1876302/2be7c2e4-7323-429c-b31b-58942120dec6)

claunia added the Needs-Tag-Fix Product-Terminal Issue-Scenario labels 2026-01-31 07:30:35 +00:00

claunia commented

2026-01-31 07:30:36 +00:00

@zadjii commented on GitHub (Dec 23, 2023):

Guys this is totally the notebooks thing I was talking about 😉

But also, there's probably some other useful things we're working on here for "Tasks" - basically, having a big long list of sendInput actions that you can quickly activate - either through the suggestions UI, or maybe even adding a "Tasks" pane.

(we'll probably have more to say after the holidays)

@zadjii commented on GitHub (Dec 23, 2023): Guys this is **totally** the notebooks thing I was talking about 😉 But also, there's probably some other useful things we're working on here for "Tasks" - basically, having a big long list of `sendInput` actions that you can quickly activate - either through the suggestions UI, or maybe even adding a "Tasks" pane. (we'll probably have more to say after the holidays)

claunia commented

2026-01-31 07:30:36 +00:00

@zadjii-msft commented on GitHub (Jan 4, 2024):

Okay so, you may be interested in the Suggestions UI and Tasks, which are new in 1.19: Using SendInput Actions in the Suggestions UI

I have Big Plans for these in upcoming releases - some of which is tracked in #13445 (though I think a better thread is floating around here somewhere)

Main workflow: User clicks "Run" on a textblock with a command.

We want to send that to the connection.

buttonPressedHandler(auto&&,auto&&)
{
    Notebook.SendInput(block.Text());
}

notebook sends that to the ControlCore? Active TermControl? Let's start there, by sending it to the active TermControl

Control does it's thing. Eventually the command ends, and the control raises a NewPrompt

On the `NewPrompt`:

Notebook needs to cork the connection
Remove the connection from the TermControl.
- Including removing old event handlers
~~Tell the TermControl to stop rendering there.~~
- ~~TermControl doesn't actually own the renderer, the ControlCore does. So plumb it.~~
- ~~Tell the Terminal~~
- The TermControl can totally just keep rendering. That's fine.
Create a new TermControl,
- Start by instantiating a new ExistingControlData
  - Create a new BlockRenderData. This renderdata starts at the current,new mark, and doesn't have a bottom set
  - the existing root Terminal
  - the existing connection
- Pass that to a new ControlInteractivity/ControlCore
  - Who grabs the RenderData out of that existing control data and uses it to create a new Renderer
- Add that content (ControlInteractivity) to a new TermControl
- attach the connection to it
- mark the new control as the active one.

On a `CommandStarted`:

This is when the control actually needs to be rendered. Raise some event that notebook can bubble to mark it as Visible

Some interfaces

class Notebook {
    Notebook(ITerminalConnection connection, Settings...);
}

class Notebook
{
    TermControl[] controls;
    TermControl active;
    ITerminalConnection connection;
    shared_ptr<Terminal> terminal;
    Notebook(ITerminalConnection connection, Settings...); // Initialize the terminal, the NotebookRenderData, and the first TermControl
    void NewPromptHandler()
}
class NotebookRenderData : IRenderData
{
}
interface IControlData
{
    IRenderData* renderData;
    Terminal* terminal;
    ITerminalConnection connection;
}
struct Control.ExistingControlData : IControlData
{
    IRenderData* renderData;
    Terminal* terminal;
    ITerminalConnection connection;
}

The IRenderData for a control is just the Terminal itself.
TextBuffer is created with a reference to a Renderer. Yike.
In the ControlCore ctor is where we construct the Renderer and pass in the Terminal as the IRenderData

Terminal already knows how to be a IRenderData so we can just modify it's implementation to also work in block mode. NO NO NO there's only one Terminal. It needs to implement a second IBlockRenderData interface, and have the control nah fuck

ControlCore::ControlCore(ExistingControlData dataFromNotebook, Settings...)
{
    _terminal = dataFromNotebook.terminal;
    _renderer = make_unique<Renderer>(renderSettings,
                                      dataFromNotebook.renderData, // IRenderData
                                      nullptr, // pEngine
                                      0,  // cEngines
                                      std::move(renderThread));

}

The notebook holds the Terminal. It holds a bunch of controls&cores. So there's one Renderer for each control. Each renderer is given a NotebookRenderData that the Notebook owns and instantiates for each control.

At creation

We instantiate a new Notebook, with the given connection and settings.

It's going to create a Terminal,
- Passing in to that Terminal, it'll pass it's own renderdata?

Terminal already implements IRenderData. And on Terminal::Create(), Terminal recieves a Renderer&. That's annoying. We

And eventually, a first TermControl.

Todo list

Convert the Renderer& in TextBuffer and AdaptDispatch (et. al) to be a Renderer*, since references can't be reassigned.
Terminal needs a ChangeRenderer method that takes a Renderer* and updates the buffer et al.
Create a BlockRenderData class, (In TerminalCore project, why not)
- implements IRenderData,
- Takes a Terminal* as a param
- Originally, just implement as a passthrough on all the TerminalRenderData methods
Change ControlCore to have a public non-projected ctor which takes a IControlData and settings, and initialize the _terminal from that if given.
Create a Notebook class in Terminal.Control.
- Just stick a pair of TermControls into the notebook.

At this point, I was able to stick the pair of TermControls from the notebook into the MyPage of the scratch project.

De-dupe the input.
- I think there's two OUTPUT handlers registered somewhere.
Update all bocks when relevant
Start making more blocks for each command

2024-march-14 lunch screenshot:

All blocks share one Terminal, but have different RenderData.
Every time we get a FTCS A, we make a new block.
- We do this behind the scenes
Each block's renderdata only renders that specific mark.
Each block's renderdata independently tracks the viewport, so that they can be scrolled independently
Each block has a play button
Blocks are generated from markdown.
Markdown files can be loaded from a given file path.

Updates archive

2024-march-13 lunch screenshot:

2024-march-12 EoD screenshot:

2024-march-11 EoD screenshot:

2024-march-11 lunch screenshot:

2024-march-08 screenshot:

These two blocks both share a single Connection and Terminal. They have separate ControlCore & ControlInteractivity & TermControl's. Only the last one actually gets updates to its viewport, we should fix that.

Conclusions

Overall, project was a huge success. Clearly, it's possible to have Terminal notebooks that have a single hidden connection & terminal core, and then have a markdown frontend for that notebook, with each block of output rendered separately.

However, at this point, one should probably ask: why the heck isn't this just .ipynb's? Especially with the existence of:

Couldn't the Terminal just be a kernel for that? There's not really a reason why not, right? And if we want to do that, then we really don't need... any... of what was written here. I should have probably done more research first.

There's probably also still value in the side-by-side UX. Probably.

@zadjii-msft commented on GitHub (Mar 7, 2024): _reserving for notes for hackathon_ 9da196da7da7e342698a354a322cfc0265cc9d04: `dev/migrie/fhl/notebook-proto-000` was the eldest attempt here, circa March 2023. Notably predates tab tear out. Actual relevant diff was: https://github.com/microsoft/terminal/compare/a04a51bbe4270d65a5a58652772b00fb719261ac...dev/migrie/fhl/notebook-proto-000 2024 spring hack is branched off `dev/migrie/fhl/2024-spring-merge-base`, https://github.com/microsoft/terminal/compare/dev/migrie/fhl/2024-spring-merge-base...dev/migrie/fhl/2024-inline-notebook * `dev/migrie/f/sui-panes` * + til events ==> `dev/migrie/fhl/2024-spring-merge-base` * Inline notebooks: https://github.com/microsoft/terminal/compare/dev/migrie/fhl/2024-spring-merge-base...dev/migrie/fhl/2024-inline-notebook * Tasks pane: https://github.com/microsoft/terminal/compare/dev/migrie/f/sui-panes...dev/migrie/fhl/tasks-pane * Markdown pane: https://github.com/microsoft/terminal/compare/dev/migrie/f/tasks-pane...dev/migrie/fhl/md-pane <details> <summary>Notes that I have saved locally, but should be persisted elsewhere just in case</summary> Notes as I try to make this work There's a lot of in-flight changes to the Terminal, so I'm gonna start off of `sui-panes` + `dev/migrie/til-events-for-all` ## Main workflow: User clicks "Run" on a textblock with a command. We want to send that to the connection. ```c++ buttonPressedHandler(auto&&,auto&&) { Notebook.SendInput(block.Text()); } ``` notebook sends that to the `ControlCore`? Active `TermControl`? Let's start there, by sending it to the active `TermControl` Control does it's thing. Eventually the command ends, and the control raises a `NewPrompt` ### On the `NewPrompt`: * Notebook needs to cork the connection * Remove the connection from the `TermControl`. - Including removing old event handlers * ~~Tell the `TermControl` to stop rendering there.~~ - ~~`TermControl` doesn't actually own the renderer, the `ControlCore` does. So plumb it.~~ - ~~Tell the `Terminal`~~ - The TermControl can totally just keep rendering. That's fine. * Create a new `TermControl`, - Start by instantiating a new `ExistingControlData` - Create a new `BlockRenderData`. This renderdata starts at the current,new mark, and doesn't have a bottom set - the existing root `Terminal` - the existing connection - Pass that to a new ControlInteractivity/ControlCore - Who grabs the `RenderData` out of that existing control data and uses it to create a new `Renderer` - Add that content (ControlInteractivity) to a new TermControl - attach the connection to it - mark the new control as the active one. ### On a `CommandStarted`: This is when the control actually needs to be rendered. Raise some event that notebook can bubble to mark it as `Visible` ### Some interfaces ```csharp class Notebook { Notebook(ITerminalConnection connection, Settings...); } ``` ```c++ class Notebook { TermControl[] controls; TermControl active; ITerminalConnection connection; shared_ptr<Terminal> terminal; Notebook(ITerminalConnection connection, Settings...); // Initialize the terminal, the NotebookRenderData, and the first TermControl void NewPromptHandler() } class NotebookRenderData : IRenderData { } interface IControlData { IRenderData* renderData; Terminal* terminal; ITerminalConnection connection; } struct Control.ExistingControlData : IControlData { IRenderData* renderData; Terminal* terminal; ITerminalConnection connection; } ``` The `IRenderData` for a control is just the `Terminal` itself. `TextBuffer` is created with a reference to a `Renderer`. Yike. In the `ControlCore` ctor is where we construct the `Renderer` and pass in the `Terminal` as the `IRenderData` ~~`Terminal` already knows how to be a `IRenderData` so we can just modify it's implementation to also work in block mode. NO NO NO there's only one Terminal. It needs to implement a second IBlockRenderData interface, and have the control nah fuck~~ ```c++ ControlCore::ControlCore(ExistingControlData dataFromNotebook, Settings...) { _terminal = dataFromNotebook.terminal; _renderer = make_unique<Renderer>(renderSettings, dataFromNotebook.renderData, // IRenderData nullptr, // pEngine 0, // cEngines std::move(renderThread)); } ``` The notebook holds the `Terminal`. It holds a bunch of controls&cores. So there's one Renderer for each control. Each renderer is given a NotebookRenderData that the Notebook owns and instantiates for each control. ## At creation We instantiate a new `Notebook`, with the given connection and settings. - It's going to create a `Terminal`, - Passing in to that Terminal, it'll pass it's own renderdata? Terminal already implements IRenderData. And on `Terminal::Create()`, Terminal recieves a `Renderer&`. That's annoying. We - And eventually, a first `TermControl`. ## Todo list * [x] Convert the `Renderer&` in `TextBuffer` and `AdaptDispatch` (et. al) to be a `Renderer*`, since references can't be reassigned. * [x] `Terminal` needs a ChangeRenderer method that takes a `Renderer*` and updates the buffer et al. * [x] Create a `BlockRenderData` class, (In `TerminalCore` project, why not) * [x] implements `IRenderData`, * [x] Takes a `Terminal*` as a param * [x] Originally, just implement as a passthrough on all the TerminalRenderData methods * [x] Change ControlCore to have a public non-projected ctor which takes a `IControlData` and settings, and initialize the `_terminal` from that if given. * [x] Create a `Notebook` class in `Terminal.Control`. * [x] Just stick a pair of TermControls into the notebook. At this point, I was able to stick the pair of TermControls from the notebook into the `MyPage` of the scratch project. * [x] De-dupe the input. - I think there's two OUTPUT handlers registered somewhere. * [ ] Update all bocks when relevant * [ ] Start making more blocks for each command </details> _2024-march-14 lunch screenshot_: ![image](https://github.com/microsoft/terminal/assets/18356694/68444a10-ff01-45d0-8360-e78063c05246) * All blocks share one Terminal, but have different RenderData. * Every time we get a `FTCS A`, we make a new block. * We do this behind the scenes * Each block's renderdata only renders that specific mark. * Each block's renderdata independently tracks the viewport, so that they can be scrolled independently * Each block has a play button * Blocks are generated from markdown. * Markdown files can be loaded from a given file path. <details> <summary>Updates archive</summary> _2024-march-13 lunch screenshot_: ![fhl-notebooks-with-progress](https://github.com/microsoft/terminal/assets/18356694/3bd160f1-4c46-4706-a5ad-a27f201a82bc) _2024-march-12 EoD screenshot_: ![image](https://github.com/microsoft/terminal/assets/18356694/9fa11089-7f4f-4983-b211-ac4bf195b40a) _2024-march-11 EoD screenshot_: ![image](https://github.com/microsoft/terminal/assets/18356694/0c1071c1-499d-4dd9-a30a-bced9f163c24) _2024-march-11 lunch screenshot_: ![image](https://github.com/microsoft/terminal/assets/18356694/a5ffd870-2385-4d5a-a722-6d92a8fbcc95) _2024-march-08 screenshot_: ![image](https://github.com/microsoft/terminal/assets/18356694/8ad7fd1a-3bab-418e-bb73-33f8b4351b67) These two blocks both share a single `Connection` and `Terminal`. They have separate `ControlCore` & `ControlInteractivity` & `TermControl`'s. Only the last one actually gets updates to its viewport, we should fix that. </details> ## Conclusions Overall, project was a huge success. Clearly, it's possible to have Terminal notebooks that have a single hidden connection & terminal core, and then have a markdown frontend for that notebook, with each block of output rendered separately. However, at this point, one should probably ask: why the heck isn't this just `.ipynb`'s? Especially with the existence of: * https://github.com/dotnet/interactive and * [Polyglot Notebooks](https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.dotnet-interactive-vscode) Couldn't the Terminal just be a kernel for that? There's not really a reason why not, right? And if we want to do that, then we really don't need... any... of what was written here. I should have probably done more research first. ------------ There's probably also still value in the side-by-side UX. Probably.

claunia commented

2026-01-31 07:30:38 +00:00

@zadjii-msft commented on GitHub (Mar 14, 2024):

I'm gonna leave the above comment for the "inline notebooks" investigation that eventually petered out, and use this one for side-by-side markdown in the Terminal

Branch map:

dev/migrie/f/sui-panes
- - til events ==> dev/migrie/fhl/2024-spring-merge-base
  - Inline notebooks: https://github.com/microsoft/terminal/compare/dev/migrie/fhl/2024-spring-merge-base...dev/migrie/fhl/2024-inline-notebook
- Tasks pane: https://github.com/microsoft/terminal/compare/dev/migrie/f/sui-panes...dev/migrie/fhl/tasks-pane
  - Markdown pane: https://github.com/microsoft/terminal/compare/dev/migrie/f/tasks-pane...dev/migrie/fhl/md-pane

2024-march-15 end of hackathon:

Updates archive

2024-march-14 EoD screenshot:

@zadjii-msft commented on GitHub (Mar 14, 2024): I'm gonna leave the above comment for the "inline notebooks" investigation that eventually petered out, and use this one for side-by-side markdown in the Terminal Branch map: * `dev/migrie/f/sui-panes` * + til events ==> `dev/migrie/fhl/2024-spring-merge-base` * **Inline notebooks**: https://github.com/microsoft/terminal/compare/dev/migrie/fhl/2024-spring-merge-base...dev/migrie/fhl/2024-inline-notebook * Tasks pane: https://github.com/microsoft/terminal/compare/dev/migrie/f/sui-panes...dev/migrie/fhl/tasks-pane * **Markdown pane**: https://github.com/microsoft/terminal/compare/dev/migrie/f/tasks-pane...dev/migrie/fhl/md-pane _2024-march-15 end of hackathon_: ![fhl-markdown-open-demo](https://github.com/microsoft/terminal/assets/18356694/3fe10b55-8d07-4183-8555-2e2538716d4a) <details> <summary>Updates archive</summary> _2024-march-14 EoD screenshot_: ![image](https://github.com/microsoft/terminal/assets/18356694/204f83af-5ea1-45ba-8b70-0e5939eb1ecb) </details>

claunia commented

2026-01-31 07:30:38 +00:00

@heartacker commented on GitHub (Mar 15, 2024):

Could you please provide a another text base panel， not only markdown panel?

@heartacker commented on GitHub (Mar 15, 2024): Could you please provide a another text base panel， not only markdown panel?

claunia commented

2026-01-31 07:30:38 +00:00

@zadjii-msft commented on GitHub (Mar 15, 2024):

Sure, why not. Rendering plaintext is easy comparatively to rendering markdown in WinUI 😜

@zadjii-msft commented on GitHub (Mar 15, 2024): Sure, why not. Rendering plaintext is _easy_ comparatively to rendering markdown in WinUI 😜 ![fhl-markdown-open-text-file](https://github.com/microsoft/terminal/assets/18356694/b8ca820b-a768-438d-8174-c58a49be0af5)

claunia commented

2026-01-31 07:30:39 +00:00

@heartacker commented on GitHub (Mar 15, 2024):

Sure, why not. Rendering plaintext is easy comparatively to rendering markdown in WinUI 😜

thank ，now i just need a short cut to send the line command without text_selected ，or selected_text command ,

after that ，we don't need copy->paste->commit line

@heartacker commented on GitHub (Mar 15, 2024): > Sure, why not. Rendering plaintext is _easy_ comparatively to rendering markdown in WinUI 😜 > > ![fhl-markdown-open-text-file](https://github.com/microsoft/terminal/assets/18356694/b8ca820b-a768-438d-8174-c58a49be0af5) > thank ，now i just need a short cut to send the line command without text_selected ，or selected_text command , after that ，we don't need copy->paste->commit line

Sign in to join this conversation.

Branches Tags

main

automated/loc-update

feature/llm

dev/cazamor/sui/search

dev/pabhoj/actions_editor_search

dev/lhecker/11509-kitty-keyboard-protocol

dev/lhecker/11509-kitty-keyboard-protocol-wip

dev/pabhoj/actions_editor_visual

dev/cazamor/selfhost/2026-01-29

dev/duhowett/no-blank-issues-you-lost-privileges-for-that-fam

dev/lhecker/benchcat-fix

dev/lhecker/dcs-perf

dev/duhowett/eoy-25/allow-set-foreground

release-1.24

release-1.23

dev/cazamor/bot/deprecate-area-atlasengine

dev/pabhoj/actions_editor_followups

dev/cazamor/selfhost/2026-01-20

dev/cazamor/selfhost/2026-01-12

dev/cazamor/spec/auto-save

dev/duhowett/eoy-25/underline-colors-in-atlas-bug-redux

dev/duhowett/fhl-2024/asciicast-recorder

dev/duhowett/eoy-25/underline-colors-in-atlas-bug

dev/duhowett/hax/serial-port-support

dev/duhowett/connection-utf8

dev/lhecker/fused-event

dev/lhecker/18928-wip

dev/duhowett/fhl-2024/clang

dev/cazamor/uia-leak

dev/duhowett/win7-wpf-termcontrol-squash

release-1.22

dev/cazamor/selfhost/11-18-v3

dev/cazamor/selfhost/11-18

dev/duhowett/fhl-2025/bitmap-fonts

dev/duhowett/server-2025-vms

dev/duhowett/cant-believe-gotta-do-this-shit

dev/lhecker/1410-large-scrollback

dev/lhecker/dark-mode

dev/cazamor/sui/invert-cursor-color

dev/duhowett/fhl-2025/wt-command-palette-cmdpal-integration

dev/duhowett/fhl-2025/wt-json-relative-icons

dev/lhecker/fucking-service-locator

dev/duhowett/unicode-17

dev/duhowett/multi-blern

dev/lhecker/wellp2-alt

dev/duhowett/wellp2

dev/lhecker/1860-horizontal-scrollbar

dev/lhecker/fix-window-count

dev/cazamor/sui/tab-color-old

dev/duhowett/hax/conhost-icon

dev/duhowett/hax/sui-color-chip-border

dev/duhowett/hax/terminalsettings-as-a-lib-/with-types-merged-into-tsm

dev/pabhoj/page_control_input_cleanup

dev/duhowett/padding-in-atlas-rebase-20250729

dev/lhecker/attach-thread-input

dev/duhowett/portable-shader-members

msbuildcache-reenable

dev/cazamor/selfhost/1.24-2025-06-10

dev/cazamor/upgrade-settings-containers

dev/cazamor/sui/ext-page/powershell-stub

dev/cazamor/selfhost/1.24-2025-05-15

dev/pabhoj/sui_action_overhaul

dev/cazamor/selfhost/1.24-2025-05-06

dev/cazamor/selfhost/1.24-2025-04-29

dev/cazamor/sui/ext-page/lazy-load-objects

dev/cazamor/sui/ext-page/badge

dev/cazamor/selfhost/1.24

dev/lhecker/sdk-26100

dev/duhowett/testing

dev/jadelaga/VS-Pty.Net-1.22

dev/duhowett/fhl-2025/what-if-no-content-ids

dev/cazamor/a11y/vt-seq-prototype

dev/lhecker/18584-part2

dev/lhecker/get-lang-id

dev/duhowett/hax/clogs

release-1.21

dev/pabhoj/featurellm_fix_paste

dev/lhecker/grapheme-backup

dev/jadelaga/VS-Pty.netFixes

dev/lhecker/atlas-engine-compute-shader

dev/migrie/s/ai-providers

dev/lhecker/animated-cursor-wip

dev/pabhoj/featurellm_timeout

dev/lhecker/dark-mode-alt

dev/duhowett/osc-strided-table

dev/lhecker/bugbash

dev/pabhoj/featurellm_improve_parsing

dev/duhowett/coast-to-coast

dev/lhecker/curly-improvements

dev/duhowett/net8

dev/duhowett/onebranch-custom-pool

dev/lhecker/renderer-overhaul-2nd-attempt

dev/lhecker/cleanup

dev/cazamor/sui/confirmation-announcements

dev/lhecker/theme-quality

dev/duhowett/hax/cmake

dev/lhecker/winconpty-cleanup

dev/duhowett/learn/rewrite-highlights

dev/migrie/b/no-nesting-when-searching

release-1.20

dev/lhecker/14165-conhost-font-size

dev/duhowett/sel-2-spans

dev/lhecker/7118-cursor-color

dev/lhecker/remove-glyph-width

dev/lhecker/igfw-scroll-region

dev/lhecker/17656-win32im-double-encoding

dev/duhowett/fhl-2024/merge-idls

dev/duhowett/feed-forward-variables

dev/lhecker/remove-chrome-math

dev/duhowett/copylink

dev/duhowett/applicableactions

gh-readonly-queue/main/pr-17566-de50310295b7d92ed3d51f07974a2a945776bf9d

dev/lhecker/atlas-engine-stride-copy

dev/migrie/b/bump-nuget-in-c

dev/migrie/f/992-redux-redux

dev/migrie/f/filter-weight-input-too

dev/migrie/f/disable-nesting

dev/migrie/f/local-snippets-cleaner

dev/migrie/s/1553-mouse-bindings

selfhost-1.22-bugbash-2024-06-04

selfhost/1.22-bugbash-2024-06-04

dev/lhecker/15689-tab-drag-crash-fix

dev/migrie/f/sxnui-font-size-change

dev/migrie/f/local-snippets-on-action-refactor

dev/migrie/f/just-local-snippets

dev/migrie/save-input-patches

dev/migrie/f/md-pane-official

dev/migrie/base-pane

dev/migrie/fhl/tasks-pane

release-1.19

dev/migrie/b/17130-clear-marks-2

dev/migrie/b/17075-its-me-the-killer

dev/duhowett/i-figured-out-why-sometimes-the-publish-build-failed

dev/duhowett/nuget-publication-with-aad-app-id

selfhost-1.20

dev/duhowett/graph

dev/migrie/b/15803-activate-dont-copypasta

dev/duhowett/is-pgo-broken-because-of-sui-being-slower

dev/migrie/b/remove-terminaltab

dev/migrie/fhl/md-pane

dev/migrie/fhl/local-tasks-2024

dev/migrie/fhl/2024-inline-notebook

dev/duhowett/interface-projects

dev/duhowett/dead-loc

release-1.18

dev/migrie/fhl/2024-spring-merge-base

dev/duhowett/hax/l9

inbox

dev/migrie/14073-on-main

dev/duhowett/hax/conhost_dump_replay

user/lhecker/atlas-engine-srgb

dev/migrie/fhl/sxnui-tooltips-3

dev/migrie/7718-notifications-experiments

dev/migrie/fhl/7718-notifications

dev/migrie/fhl/7718-notifications-reboot

dev/lhecker/remove-gsl

dev/lhecker/16575-TerminateProcess

dev/lhecker/window-thread-climate-control

dev/lhecker/client-context-input-output-mode

dev/lhecker/ring-buffer-input-buffer

release-1.17

dev/lhecker/propsheet-fontdlg-refactor

dev/lhecker/renderer-overhaul

dev/pabhoj/test

dev/duhowett/chop

dev/lhecker/til-ulong-cleanup

dev/lhecker/til-env-cleanup

dev/migrie/f/16005-a11y-pane

dev/cazamor/a11y/fastpass

dev/migrie/b/15487-push-cwd

dev/migrie/b/15536-or-15219-idk

dev/duhowett/move-timers-down-into-core-interactivity-etc

dev/migrie/b/15812-broadcast-paste-two

dev/migrie/fhl-fall-2023/11162-quake-III-arena

dev/migrie/fhl-fall-2023/1620-automatic-tab-progress

dev/migrie/fhl-fall-2023/9992-quake-II

dev/migrie/fhl-fall-2023/9992-default-quake-settings

dev/migrie/fhl-fall-2023/9992-window-name-settings

dev/migrie/fhl-fall-2023/oceans

dev/lhecker/ColorScheme-improvements

dev/migrie/search-v2-v3

dev/migrie/pr-15717/its-dangerous-to-go-alone

dev/migrie/f/4768-taskbar-icons

dev/duhowett/padding-in-atlas

dev/migrie/f/3121-tooltips

dev/duhowett/sticky-control

dev/duhowett/fix-tracing-2

dev/migrie/b/add-support-for-vsc-marks

dev/migrie/f/1860-this-is-literally-what-less-is-for

dev/migrie/s/5916-draft

dev/lhecker/tracy

dev/migrie/s/north-star

dev/cazamor/tag-youre-it

dev/migrie/f/12336-let-it-mellow

dev/migrie/f/now-with-more-compat-settings

dev/migrie/f/compatibility-sui

dev/duhowett/hax/wpf-atlas

dev/duhowett/fgb

dev/migrie/b/15487-relative-paths-are-hard

dev/lhecker/colrv1

loc-update

dev/migrie/fhl/dyndep-csharp

dev/migrie/fhl/dyndep

dev/migrie/fhl-clickable-send-input

dev/migrie/f/cwd-hijinks-5506-15173

dev/lhecker/openconsole-async-start

1.17

dev/migrie/bump-scratch

dev/migrie/f/3726-restartConnection

dev/migrie/b/cxn-restarting-attempt-1-backport

dev/migrie/b/9053-part-3-the-actual-doing-of-the-thing

dev/migrie/b/13388-focus-logger

dev/migrie/b/9053-part-4-i-guess-defterm

dev/migrie/oop/3/of-the-silmarils

of-the-darkening-of-valinor

dev/migrie/fhl/notebook-proto-000

dev/migrie/f/narrator-buddy

dev/migrie/mux-2.8.2-march-2023

dev/migrie/f/roast-mutton

dev/migrie/f/12861-preview-input

dev/lhecker/clang-tidy

dev/migrie/f/3121-wE-dOnT-hAvE-dEv-DaYs

dev/duhowett/compiler-compliance

dev/duhowett/i-have-a-burning-hatred-for-ntstatus-of-later-so-why-not-fix-it

dev/duhowett/shorthand-namespaces

dev/duhowett/rename-all-dlls

dev/duhowett/errordialog

dev/lhecker/gsl-narrow

dev/migrie/b/11522-dumb-idea

release-1.16

dev/miniksa/env

dev/duhowett/hax/embed-everything

dev/migrie/b/13388-attempt-003

dev/migrie/b/14512-test-research

dev/migrie/b/13388-attempt-002

dev/migrie/b/14464-copyOnSelect-moving-text

dev/migrie/s/thema-schema-for-1.16

dev/migrie/s/theme-pair-schema

dev/migrie/b/13388-experiments-1

dev/cazamor/spec/a11y-vt-seq

dev/migrie/b/14557-empty-folder-dropdown

dev/cazamor/spec/a11y-vt-seq-v2

release-1.15

dev/migrie/f/process-model-v3-test-0

dev/lhecker/vsconfig

dev/migrie/s/5000-presentation

dev/lhecker/5907-startup-perf

dev/lhecker/winrt-file-api-benchmark

dev/duhowett/128-bit-compiler

dev/duhowett/hax/arm64-native-build

dev/migrie/fhl/more-shell-integration

dev/migrie/b/13388-experiments-0

dev/lhecker/til-to-ulong-improvements

dev/migrie/s/markdown-notebooks

dev/cazamor/a11y/nav-by-page

dev/cazamor/a11y/system-menu-support

dev/duhowett/no-private-registry-keys

dev/cazamor/wpf/uia-expose-enable-events

dev/cazamor/wpf/uia-events

extendAISpec

dev/migrie/fhl/clickSendInput

dev/migrie/fhl/save-command

dev/migrie/b/theme.profile

dev/migrie/b/13943-a-test-for-this

dev/migrie/oop/2/endgame

dev/duhowett/hax/merge_idl

dev/migrie/oop/2/infinity-war

dev/migrie/spellbot-cve

dev/cazamor/a11y-sev3/new-profile-announcement

dev/migrie/fhl/upside-down-mode

release-1.14

dev/migrie/f/9458-startupInfoToTerminal

dev/migrie/fhl/5916-triggers

dev/migrie/b/13523-context-menu

dev/migrie/b/6523-endpaint-outside-lock

dev/migrie/b/12413-OnUnhandledException

dev/lhecker/render-snapshot

dev/cazamor/1.15/scroll-to-point

dev/migrie/mux-2.8-aug-2022

dev/lhecker/lock-console-guard

dev/migrie/f/1504-final

dev/pabhoj/sui_follow_ups

dev/migrie/f/til-winrt.h

dev/cazamor/color-picker-redesign

dev/migrie/fhl/vscode-autocomplete-prototype

dev/migrie/f/1504-prototype

dev/migrie/oop/2/loki

dev/migrie/oop/2/wandavision

dev/migrie/b/8698-YOURE-OUT-OF-ORDER

fabricbot-configuration-migration

dev/migrie/b/12788-did-it-work

dev/migrie/b/localtests-ci-2022

dev/cazamor/1.14/replace-compareInBounds

dev/pabhoj/preview_string

dev/cazamor/ks/switchSelectionEndpoint

dev/migrie/oop/2/COM-ISwapChainProvider-attempt-1

dev/migrie/b/dxd-marker

release-1.13

dev/migrie/b/13066-for-defterm

dev/cazamor/revert-dwm

dev/migrie/b/13066-sw_flash_repeatedly

dev/migrie/b/no-cloaky-cloak

dev/migrie/f/apples-to-oranges

dev/migrie/f/no-custom-caption-btns

dev/migrie/f/10509-mica-and-transparent-titlebars

dev/migrie/b/12911-wpf-focus-fg

dev/migrie/titebar-colors

dev/lhecker/4015-cursor

dev/migrie/fhl/rgb-rainbow-window-frame

dev/migrie/fhl/scroll-marks-prototype

release-1.12

dev/miniksa/compliance

dev/migrie/f/default-icons

dev/migrie/fhl/10175-web-search-for-text

dev/migrie/fhl/menu-complete-prototype

dev/migrie/b/2988-merged-prototypes

dev/migrie/b/2988-niksa-msgs-prototype

dev/migrie/fhl/9583-colorSelection

dev/migrie/b/10609-sui-leak

dev/migrie/b/32-attempt-3

dev/migrie/release-1.12-rejuv-attempt-2

dev/migrie/demo-for-presentation

dev/migrie/b/32-but-im-here-for-12567

dev/duhowett/conpty_first_frame_blug

dev/migrie/b/11092-unfocused-acrylic-settings

dev/migrie/localtests-in-ci

dev/migrie/b/12356-attempt-2

dev/migrie/b/12353-with-null

dev/migrie/b/12387-trim-spaces

dev/migrie/b/5033-bad-start

dev/lhecker/12351-broken-locales

dev/migrie/b/8663-input-to-oem-crash

dev/migrie/b/11743-win10-opacity-is-hard

dev/migrie/f/ctrl-click-elevate

dev/migrie/b/12196-shim-localization

dev/lhecker/issue-4015-til-rect

dev/cazamor/eim/mvvm

dev/migrie/f/--elevate

dev/migrie/b/11668-i-think

dev/migrie/b/11994-wsl-mangline

dev/migrie/eim/3475-action-xmacros

dev/migrie/eim/incremental-build-000

dev/cazamor/a11y/fake-uia-data

dev/migrie/f/non-terminal-content-elevation-warning

dev/migrie/f/632-on-warning-dialog

dev/lhecker/rgba

dev/migrie/b/8480-keybindings-in-tabs

release-1.11

dev/migrie/b/11561-dead-ends

dev/migrie/oct-21-roadmap-update

dev/migrie/fhl/adaptive-card-extension

dev/cazamor/test/11440

dev/migrie/f/warning-dlg-automation

dev/migrie/b/1.12-crash-on-exit

dev/migrie/b/11146-next-tab-in-cmdpal

release-1.10

dev/migrie/5ff9a24-and-75e2b5f

dev/duhowtt/hax/cpal-jumplist-async

dev/lelian/actionid/1

dev/migrie/f/just-elevated-state

dev/lhecker/terminal-settings-cleanup

dev/migrie/gh-10824

dev/pabhoj/cursor_light

dev/migrie/oop/wandavision

dev/migrie/oop/endgame

dev/migrie/oop/infinity-war

dev/lhecker/app-state-actually-hidden

dev/migrie/b/6160-dynamic-default-warning

dev/mgirie/b/more-nchhittest-ideas

dev/migrie/b/9320-interfacial-separation

cinnamon/fhl/find-contextmenu

dev/lhecker/wsl-distro-generator-cleanup

dev/migrie/b/10875-but-more-clever

dev/migrie/b/broken-globalsummon-overloading

dev/duhowett/hax/rle-row

dev/migrie/fhl-2021/cmdpal-select-list

dev/migrie/fhl-2021/differential-pixel-shading

dev/duhowett/hax/no-writable-glyphat

dev/migrie/fhl-2021/more-shader-variables

dev/migrie/titlebar-shenannigans

dev/miniksa/win10_font_matching

dev/lhecker/conhost-oom

dev/migrie/b/10332-less-snappy-scrolling

dev/migrie/b/7422-1px-top-border

release-1.9

dev/cazamor/move-scratch

release-1.8

dev/miniksa/manifest_2

release-1.6

release-1.7

dev/migrie/oop/the-whole-thing

dev/migrie/oop/connection-factory

dev/migrie/f/quake-dropdown-2

dev/miniksa/rle2

dev/migrie/f/quake-toCurrent-experiments-2

dev/migrie/f/quake-toCurrent-experiments

dev/migrie/f/quake-dropdown

dev/cazamor/actions-page/template

dev/duhowett/hax/cursor_stamp_foreground_background

dev/migrie/f/1860-hey-might-was-well-hack-during-a-hackathon

dev/migrie/oop-terminal.control-split-control

dev/duhowett/hax/build-with-wholearchive

dev/cazamor/spec/tsm-actions-temp

dev/migrie/oop-tear-apart-control

dev/migrie/oop-scratch-3

dev/cazamor/sui/bugfix-reload-crash

dev/migrie/f/xmacro

dev/cazamor/sui/proto/profile-nav-view

dev/migrie/f/name-windows

dev/migrie/dol/messing-with-shaders-take-1

release-1.5

dev/cazamor/sui/inheritance-hyperlinks-test

dev/migrie/r/commandline-lib-002

dev/migrie/f/com.fabrikam.toaster

dev/cazamor/adaptive-cards-prototype

dev/migrie/f/commandline-lib

dev/miniksa/zipzoom2

dev/migrie/f/remote-commandlines

dev/migrie/f/632-elevated-profiles

dev/migrie/oop-broker-000

dev/migrie/fix-pr-7015

dev/duhowett/clang

dev/miniksa/input_tests_2

dev/miniksa/input2

dev/migrie/oop-rpc-000

release-1.4

dev/migrie/oop-mixed-elevation-1

dev/migrie/oop-window-content-1

cinnamon/open-json

dev/miniksa/input_tests

dev/duhowett/hax/tsm-graphviz

dev/miniksa/input

dev/duhowett/hax/caption_buttons

release-1.3

dev/cazamor/a11y/expand-line-under-viewport

dev/cazamor/acc/ch/word-nav-perf

dev/cazamor/spec/settings-ui-architecture-draft

dev/duhowett/hax/tap_upgrade

dev/migrie/f/pane-exit-animation

release-1.2

dev/migrie/move-lib-up-and-dll-down

release-1.1

dev/migrie/f/branch-2-backup

dev/migrie/f/settings-getters-only

dev/duhowett/hax/command_palette_search

dev/migrie/f/6856-let-terminalpage-expandcommands

dev/migrie/f/theming-2020

dev/migrie/oop-scratch-4

dev/duhowett/hax/punchout

dev/migrie/s/action-ids

dev/migrie/f/lets-just-generate-these

dev/migrie/oop-scratch-2

dev/miniksa/dcomp

dev/miniksa/gotta_go_fast_spsc

dev/miniksa/gotta_go_fast

dev/miniksa/perf_skip_checks

dev/miniksa/perf_buffer_dig

dev/migrie/s/1203-cursorTextColor

dev/migrie/f/fix-intellisense-i-guess-backup

release-1.0

dev/migrie/f/execute-commandlines

dev/migrie/f/2046-Command-Palette-v2

dev/migrie/b/6421-passthrough-alt

dev/migrie/b/moving-focus-is-hard

dev/miniksa/set

dev/migrie/f/1203-phase-1

dev/migrie/f/get-localtests-in-ci

dev/cazamor/drag-panes

dev/cazamor/tile-background

release-0.11

dev/duhowett/dev/duhowett/hax/appstate_remember

dev/duhowett/load_condrv

dev/duhowett/hax/wpf_win_8_hax

dev/migrie/b/3088-weird-exact-wrap-resize

release-0.10

dev/migrie/b/4591-custom-scaling-bug

dev/duhowett/hax/attr_smuggling

dev/migrie/b/5161-mingw-vim-fix

dev/miniksa/dx_bitmap

dev/migrie/b/1503-try-messing-with-cooked-read

dev/duhowett/eyebeam

dev/migrie/b/5113-experiments

dev/duhowett/hax-selection-exclusive

dev/migrie/f/more-vt-renderer-tracing

dev/miniksa/bitmap

dev/duhowett/wprp

dev/miniksa/bitmap-mad-with-power

dev/migrie/f/resize-quirk

dev/migrie/f/reflow-buffer-on-resize-002

wpf-renderer-revert

dev/miniksa/draw

release-0.9

dev/miniksa/tabs-color-fix

dev/miniksa/4309

dev/migrie/f/just-wrapping

dev/migrie/b/3490-try-another-resize-algo

release-0.8

dev/migrie/b/3490-a-simpler-resize

dev/migrie/b/3490-resize-down

dev/miniksa/4254

dev/migrie/f/conpty-wrapped-lines-2

dev/migrie/b/be-better-at-hiding

dev/migrie/f/3327-xaml-theming-proto

dev/miniksa/gardening2

release-0.7

dev/duhowett/conpty-flags

dev/migrie/f/603-vintage-opacity

dev/migrie/PR#3181-comments

dev/duhowett/font-64

release-0.5

dev/migrie/b/663-paste-lf-always

dev/migrie/b/2011-reordered-fallthrough-strings

dev/migrie/b/411-init-tab-stops

dev/migrie/b/json-patching-is-hard

dev/migrie/b/2455-try-getting-tests-working

dev/migrie/b/1223-change-256-table

dev/migrie/f/2171-openterm.cmd

dev/migrie/f/drag-panes

dev/migrie/f/2046-command-palette

release-0.3

dev/miniksa/manager

dev/migrie/f/non-terminal-panes

dev/migrie/f/passthrough-2019

dev/miniksa/shared_pch

dev/migrie/f/1897-less-duplicated-work

release-0.2

dev/cazamor/mcs/viewport-selection

dev/duhowett/version_hack

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/terminal#21012

Markdown Notebook Panes #21012

User Stories

Description of the new feature/enhancement

Proposed technical implementation details (optional)

Main workflow: User clicks "Run" on a textblock with a command.

On the NewPrompt:

On a CommandStarted:

Some interfaces

At creation

Todo list

Conclusions

On the `NewPrompt`:

On a `CommandStarted`: