Dim or otherwise indicate "inactive" editor/terminal

[jasonhulbert]

One of the best features of VS Code is the built-in terminal. However, I often begin typing in the editor when in fact I think I'm in the terminal - and vice versa. To alleviate this issue, it would be helpful to visually indicate which portion of the IDE is "active" vs. "inactive". A subtle dimming effect might just do the trick.

[jasonhulbert]

Of course, this would be best suited as an option and, since it could be jarring to current users, not the default behavior.

Personally, I could also see this being useful in split-editor views as well.

[Tyriar]

Some things that could help you with this:

• "terminal.integrated.cursorBlinking": true, this is how I tell where the focus is. The terminal cursor is also hollow when it's not focused which helps.

• The high contrast theme adds a border around the terminal when it's focused:

  

  Probably not much of a workaround but worth mentioning 😉

@bpasero @isidorn @alexandrudima what are your thoughts on maybe having an option something like "workbench.focusBorder": "everywhere" which would draw the focus border around whatever is focused. Right not a border is not drawn when focusing the editor and panels. This could be useful to give an extra visual cue on which part of the workbench is focused. It would also be particularly nice when working with the workbench.action.navigate* commands.

We used to show the border around the explorer not that long ago which i actually liked. A border around the terminal and editor would be nice too.

Alternatively an option to dim the non-active view as proposed by the OP.

[jasonhulbert]

@Tyriar thanks for the response!

I do have blinking cursor set currently and when I'm on my macbook it's usually in a close enough proximity (visually) so that I see it but when I'm on my two large external displays at fullscreen it's easy to miss the blinking cursor if you're looking elsewhere and working quickly.

The high contrast mode makes my eyes bleed haha. None the less, that's great to point out here.

+1 on the focus border you have suggested.

Thanks again

[bpasero]

I do not like the border (in fact I even get annoyed by our blue focus ring so I disabled it via theme customization). I would prefer a solution that does not introduce ugly borders.

[jasonhulbert]

@bpasero What are you thoughts on the dimming effect? Possibly with an optional "amount"?

iTerm is an example of this:

[Tyriar]

I prefer borders personally 😛

[bpasero]

Yeah dimming might be better. We have this problem already today where when having multiple editors open side by side it is not clear which editor is active.

[GregBorrelly]

is anyone currently working on this request? I'm interested in implementing it.

[Tyriar]

@GregBorrelly I'm not sure there is clear way forward right now.

[rifelpet]

@Tyriar I experience a similar issue as well, specifically when switching between windows. I'll have my web browser "active" and then click on the terminal area of my VS Code window expecting the cursor to be in the terminal so I can start typing commands, however the cursor is unexpectedly placed in the editor. I have to click the terminal area a second time. It'd be great if clicking on the terminal area of an inactive VS Code window would make it active with the cursor in the terminal rather than the editor. Is that a reasonable fix? or should I open a separate issue for this suggestion

[safield]

+1 for dimming the inactive editor/terminal windows.

I always edit in split window mode, and I would really like the inactive windows to be dimmed.

I have been using this plugin for sublime text 3 for 3 years now, and it has convinced me that subtle, full pane dimming, is the most effective way to emphasise or de-emphasise an editor pane.

https://github.com/SublimeText/InactivePanes

[jcherven]

I also usually edit with a split editor and one or more split terminals, using homerow keybindings to navigate around them. While my color theme (spacemacs dark)'s dimmed tab colors, a hard-blinking block cursor, and the active line indicator does give me some indication of which split is active, I'm still often mistakenly typing into the wrong pane because these subtle cues take a lot of attention to notice.

I really like iTerm2's adjustable inactive pane dimming, it's implemented very well in my opinion. When I have some time I'd like to see if this effect can be hacked in the color theme. Anyone try this yet?

[kwonoj]

I was bugged by this too, while I wasn't able to make take care of terminal pane did a naive impl for text document at least: https://marketplace.visualstudio.com/itemdetails?itemName=ojkwon.vscode-activedocumentindicator until this feature lands in editor.

[paladinu]

This frustrates me at least a few times a day. Dimming by a configurable amount seems like the clear winner. We should have this by now. Do we vote on it somewhere?

[ruudhanegraaf]

Throwing in my vote here...
+1

Mainly the terminal window. I can't count the times anymore I've mistakenly typed and overwritten stuff in the editor window, instead of the terminal window.

[jasonwilliams]

This frustrates me at least a few times a day. Dimming by a configurable amount seems like the clear winner. We should have this by now. Do we vote on it somewhere?

Someone needs to re-open this issue as a feature request so that it gets the whole voting thing.
or maybe one of the VSCode staff can update this issue.

@alexr00 ?

[Tyriar]

@jasonhulbert it's in the backlog and unlocked so it can be voted on just fine currently?

[jasonhulbert]

Sorry @Tyriar - not sure I understand the question.

If you're asking if my original comment is descriptive enough to be voted on then yes, I think it is accurate enough. I'd be happy to revise or provide more detail if needed.

[jasonhulbert]

Specifically, folks should take note of the first two comments in this issue and the image/example of iTerm2 shown here #30522 (comment)

[paladinu]

I think @Tyriar was acutally responding to @jasonwilliams not you @jasonhulbert . Are issues that have been around for a while less likely to be voted on?

[Tyriar]

Thanks for the discussion all, I tweaked the settings in #190751.

[lobsterkatie]

Yay! Thanks, @Tyriar, for taking our input!

[abhijit-chikane]

I just checked
The issue with this is If I enable this setting and If I do some changes in editor and click on other file from the explorer it just move the focus from the editor

I don't think we want this behaviour
I just care about the terminal and editor
If I jump in between those then only it should inactive the corrosponding part
but if it is going move the focus even if I click on the file explorer doesn't going to help much atleast for me
@Tyriar

[Tyriar]

@abhijit-chikane I think you're asking for us to track whether the terminal or editor was focused last which is more state than I'd prefer to track for this feature. I'll wait for more feedback on the topic to see the reception as is first.

[lobsterkatie]

The issue with this is If I enable this setting and If I do some changes in editor and click on other file from the explorer it just move the focus from the editor

Oh, damn, I hadn't even thought of this. Yeah, that's not exactly how I was picturing it, either. That said, @abhijit-chikane, I think it's worth turning it on and living with it for a few weeks. It may turn out to be intuitive, or it may not. And if it's not, we can always open another feature request! 😛

[Tyriar]

and click on other file from the explorer it just move the focus from the editor

Also a little tip, you can double click to select the file in the explorer and focus the editor

[Tyriar]

FYI I'm planning on moving this back to live under accessibility., see #191618 and some discussion about the feature in #191610

[Tyriar]

There's been a bunch of feedback from the team during the test round. I'll be announcing the feature in the release notes' experimental section and this is the plan for upcoming improvements #191775. Feedback is welcome of course!

[lobsterkatie]

There's been a bunch of feedback from the team during the test round.

I like your system of making an issue specifically for internal testing and then linked issues for feedback! I may suggest it to our product team. 🙂

[Tyriar]

@lobsterkatie this is our "endgame" week where the whole team turn into testers for a bit https://github.com/microsoft/vscode/wiki/Development-Process#end-game, it certainly works pretty well when building devtools 👍

[lobsterkatie]

Nice - I didn’t realize it was documented. Will definitely pass that along, thanks! And we do indeed make a devtool - you should check us out sometime!

[Tyriar]

@lobsterkatie ah I think I've heard ads for Sentry and been at the same conferences. I remember seeing https://blog.sentry.io/three-reasons-to-meat-us-at-github-universe/ 😉

[lobsterkatie]

Oh, how funny, and man, what a throwback! I remember the day our head of design was figuring out how to make the "Sentry" on that hot dog swag.

In any case, we have an electron SDK as well as freestanding browser and node SDKs (which, full disclosure, I helped maintain for a few years) should y'all ever be interested. 🙂