Clicking on terminal windows in same tab shouldn't move blocks up and down, it moves things around too much

[ilyaGurevich]

Describe the solution you'd like?

Don't move blocks around, just highlight the terminal you're working in like iterm2 to show you're working in it

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

No response

Additional context

No response

[elviskahoro]

We're gonna close this for now. The blocks move because the input editor was collapsed but opens when the new pane takes the focus. ATM it's a design decision. CCing @zachlloyd

[rswerve]

Glad to see this reopened. Layout shifting is a UI anti-pattern, and as @ilyaGurevich notes, iTerm's use of background color to show focus is better because it reduces layout shifting and makes it easier to see at a glance which tab is in focus.

[ugrupp]

I'm also using panes a lot, and both the layout shift and the hidden prompt are a little irritating. Especially when the prompt already has some content, that definitely shouldn't be hidden when switching the pane.

Perhaps make it configurable to hide the prompt?

(So far, it's literally the only thing that bugs me, everything else about Warp is fantastic!)

[rswerve]

(So far, it's literally the only thing that bugs me, everything else about Warp is fantastic!)

Agreed. I'm trying very hard to make Warp my daily driver, but the movement and the ever-so-slight difficulty of seeing which pane is active are challenges.

[rswerve]

I see that half of this was done, with the release of the dimmed inactive tabs. 🎉 Hoping that the shifting is up next, since that seems to be a consistent annoyance for folks. 🙌

[kg-currenxie]

Same here. Would be great having the option to enable/disable this behavior in settings. Can't imagine a lot of effort? :) if (settings.collapseWhenBlurred) { collapse() } 😂

[simonst]

+1 for this, the only downside of warp as of right now - it does really distract when switching between split panes. Any chance to make this configurable?

[samv]

Yeah, I've been finding this behavior really irritating, and was looking for a config option but to no avail. The current behavior I think is kind of broken. Making an input box change size, with non–local effects on the whole window because it is not focused is not how user interfaces work. The one I'm typing in for instance, the Github Issues box. If I press tab, a blue border around the text box moves to another location. If I move to a user input with a flyout, that flyout flies over the existing display, but it doesn't cause the whole window to move around.

The current behavior means that if you switch to a tab, run a command to look something up or get a result, and then switch back. The information you got from the other tab moves right as you were looking at it. It's jarring.

[warpdotdev-devx[bot]]

We're tracking this issue over at #303 and would appreciate it if you could 👍 and comment there if you're also experiencing the same. This helps us gauge the impact of the issue. Also, we recently released Synced Inputs which may allow us to implement a feature to help alleviate the issue.

We'll be closing this as a duplicate.

[dannyneira]

Thanks for your patience folks! As requested, in Warp version v0.2023.09.19.08.04.stable_00 and above, the input editor remains visible in inactive panes when using split panes.

Closing as completed, but please let us know if any issues.