[PR #8689] Add support for Insert-Replace Mode (IRM) and SM/RM #27271

Open
opened 2026-01-31 09:20:58 +00:00 by claunia · 0 comments
Owner

Original Pull Request: https://github.com/microsoft/terminal/pull/8689

State: closed
Merged: No


This pull request adds support for IRM. I chose a brute-force strategy:
every time we insert text into a row, back up the characters and
attributes and stamp them down at the end of the inserted range.

Pros:

  • Easy
  • Fast implementation
  • Relies on preexisting DBCS lead/trail calculation and pre-formed
    CharRowCells

Cons:

  • Applies brute force
  • Expensive in terms of allocations, especially when inserting only a
    single character. Most output inserted is going to be on the order
    of single characters. 120 single characters, inserted one by one,
    with a memcpy() after each one.

I consider the cons to be acceptable enough for this scenario. It's rare,
and it seems like the most common use is in interactive shells where we
need to operate at "user speed". We can always optimize it later.

I chose to give SCREEN_INFORMATION knowledge of whether it was in
insert mode, rather than the text buffer, adapter or any other
component. When insert mode is on, the text buffer is instructed to
insert--a request it passes directly on to ROW. I've tried to keep
branch misprediction to a minimum (with some optimizer hints) and reduce
default-case allocations¹.

¹ by using unique_ptr<...> to store copied CharRow and ATTR_ROW,
s.t. there is no cost in the normal case except 2*sizeof(void*) bytes
on the stack in ROW::WriteCells

Closes #1947

Validation

  • Tests for IRM must be added
  • Tests for cool new ATTR_ROW stuff added, pass
**Original Pull Request:** https://github.com/microsoft/terminal/pull/8689 **State:** closed **Merged:** No --- This pull request adds support for IRM. I chose a brute-force strategy: every time we insert text into a row, back up the characters and attributes and stamp them down at the end of the inserted range. Pros: * Easy * Fast implementation * Relies on preexisting DBCS lead/trail calculation and pre-formed `CharRowCell`s Cons: * Applies brute force * Expensive in terms of allocations, especially when inserting only a single character. **Most** output inserted is going to be on the order of single characters. 120 single characters, inserted one by one, with a memcpy() after each one. I consider the cons to be acceptable enough for this scenario. It's rare, and it seems like the most common use is in interactive shells where we need to operate at "user speed". We can always optimize it later. I chose to give `SCREEN_INFORMATION` knowledge of whether it was in insert mode, rather than the text buffer, adapter or any other component. When insert mode is on, the text buffer is instructed to insert--a request it passes directly on to `ROW`. I've tried to keep branch misprediction to a minimum (with some optimizer hints) and reduce default-case allocations¹. ¹ by using `unique_ptr<...>` to store copied `CharRow` and `ATTR_ROW`, s.t. there is no cost in the normal case except `2*sizeof(void*)` bytes on the stack in `ROW::WriteCells` Closes #1947 ## Validation * [ ] Tests for IRM must be added * [x] Tests for cool new `ATTR_ROW` stuff added, pass
claunia added the pull-request label 2026-01-31 09:20:58 +00:00
Sign in to join this conversation.
No Label pull-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#27271