Allow more interactive apps (`man`, `less` etc.) to disable blocks and take over mouse input and scrolling

[mitranim]

Pre-submit Checks

• [x] I have searched Warp feature requests and there are no duplicates
• [x] I have searched Warp docs and my feature is not there

Describe the solution you'd like?

This is somewhere between a bug report and a feature request.

I'd like apps like man and less to take over the terminal, disabling blocks, similar to the behavior of vim.

Is your feature request related to a problem? Please describe.

Currently, some interactive apps (vim, yazi, btop) correctly take over the terminal, while some others (man, less, more) don't.

Comparing the app behaviors, this seems to be related to mouse input. The "correct" behavior of disabling blocks and taking over is exhibited by apps which support mouse input. The "incorrrect" behavior is exhibited by interactive apps which don't support mouse input. So I'm guessing this is the heuristic Warp uses.

There's probably another, more general heuristic Warp could use, to detect apps such as less which don't request mouse input.

See the attached video for an example. It shows me scrolling up and down. In the vim case, scrolling is limited to the actual CLI app, without spilling over to Warp's history and blocks. In the less case, scrolling "spills out" outside the app.

https://github.com/user-attachments/assets/2ca46959-a33f-4206-a60c-e67ea1b7cc9c

Additional context

Warp version: v0.2025.10.08.08.12.stable_03

Operating system (OS)

macOS

How important is this feature to you?

2

Warp Internal (ignore) - linear-label:39cc6478-1249-4ee7-950b-c428edfeecd1

None

[mitranim]

Turns out this was my fault. less in fact does support mouse input, and works correctly in Warp by default. But I had the following in my ~/.zprofile:

export LESS='-F -g -i -M -R -S -w -X -z-4 '

Turns out, -X disables mouse input in less, which in turn prevents Warp from recognizing less as a proper full-screen interactive app. Removing this flag fixes the problem.

-X was there for padding at the screen edges, but it also requires preexec() { clear } to minimize issues with scrolling, which is currently incompatible with Warp anyway (see #7664).

This means less and man should work properly out of the box for most users. Still, it would be nice if this tiny edge case could be fixed.

[mitranim]

Found a more legit example: gforth. Its REPL mode does not support / request mouse input, resulting in the same weirdness as recorded above. Unlike my less blunder, this isn't the result of turning off a feature; gforth is keyboard-only.

[mitranim]

Even more legit example: r2 (part of the radare2 reverse engineering and debugging toolkit). Steps to reproduce:

• Run r2 with any executable (such as r2 $(which r2)).
• Press the v button to enter "visual mode".
• Hover the disassembly panel on the left, and try scrolling.

In iTerm2, this scrolls the disassembly view, so clearly r2 is requesting and handling mouse input.

In Warp, this scrolls the terminal itself! So I'd say it's a legit bug or missing feature.

[acarl005]

Hi @mitranim thanks for reporting the issue. Glad you worked it out for less. I've tried r2 as you suggested and I agree there's something buggy here. I'll investigate.

"some interactive apps (vim, yazi, btop) correctly take over the terminal"

In case you were interested in the "standard" name for this mode, it's called the "Alternate Screen Buffer". https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-The-Alternate-Screen-Buffer

We like to call it the "alt screen" for short. Anyways back to this issue... r2 needs to be in alt screen mode and that's not happening in Warp. There are 2 possibilities that I suspect:

1. r2 believes that it's running inside a terminal which doesn't support alt screen, so it doesn't request it.
2. r2 is emitting an older escape code that Warp fails to recognize.

[acarl005]

Also r2 is super freaking cool thanks for making me aware.

[acarl005]

I have a fix I'm testing. I estimate it will be released Dec 11th

[acarl005]

Still on track to release this fix on Dec 11th

[acarl005]

This should be fixed on the latest version v0.2025.12.10.08.12.stable_03. Please let me know if it isn't fixed.