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 :wink:

@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 :stuck_out_tongue:

[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 https://github.com/microsoft/vscode/issues/30522#issuecomment-314835872

[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]

Opps, more than one Jason 😅

@paladinu maybe, it could go either way. You could always vote on this though and it's only received 7 over the past 2.5 years. I just think it's not that popular of a request or it would have more.

[ruudhanegraaf]

I had the same issue as @jasonhulbert , and couldn't find an extension, so I cobbled something together myself. It relies on the Custom CSS and JS Loader extension (https://marketplace.visualstudio.com/items?itemName=be5invis.vscode-custom-css). It's a small script which will dim either the editor window(s) or the terminal, depending on which one has the focus. I hardly start typing in the wrong window anymore. :-) If anybody is interested, just let me know.

[marcelusaurelius]

I had the same issue as @jasonhulbert , and couldn't find an extension, so I cobbled something together myself. It relies on the Custom CSS and JS Loader extension (https://marketplace.visualstudio.com/items?itemName=be5invis.vscode-custom-css). It's a small script which will dim either the editor window(s) or the terminal, depending on which one has the focus. I hardly start typing in the wrong window anymore. :-) If anybody is interested, just let me know.

I am highly interested. @ruudhanegraaf

[ruudhanegraaf]

Hi @marxrecio.

It's not 100% perfect, but close to 90%. :-)

This is the trick:

• Download and install the Custom CSS and JS Loader extension.
• Create a file vscode-custom-css.js (or any name you'd like) in a folder on your system, with the following content:

` / var addon = "[inactive-window-dimmer]: "

// Add event listener to all existing elements var allElements = document.querySelectorAll("*") for (element of allElements) { element.addEventListener("focusin", doDimWindow) }

function doDimWindow() { // Primary elements var terminalElements = document.querySelectorAll('.terminal') // Terminal window var editorElements = document.querySelectorAll('.monaco-editor') // Editor window

// Get currently active element var currentElementName = document.activeElement.className

// Logging for debugging // console.info(addon + "Selected element: " + currentElementName)

// Don't do anything when elements like the menu bar or input fields are selected var regex = /actions-container|(action|menubar)-menu-|statusbar|monaco-list|input$/ if (regex.test(currentElementName) || !currentElementName) { return }

// Dim values (50%, 100%) var transparencyArray = [0.5, 1]

// Check if something other than the terminal was activated, and if so, flip the values: Editor will be dimmed, terminal will be undimmed if (currentElementName !== "xterm-helper-textarea") { transparencyArray.reverse() }

// Change opacity of the editor window for (element of editorElements) { element.style.opacity = transparencyArray[0] }

// Change opacity of the terminal window for (element of terminalElements) { element.style.opacity = transparencyArray[1] } } `

• Add the following to your settings.json, with the proper locations to the custom .js.

"vscode_custom_css.imports": [ "file:///D:/OneDrive/Visual%20Studio%20Code/vscode-custom-css.css", "file:///D:/OneDrive/Visual%20Studio%20Code/vscode-custom-css.js" ], "vscode_custom_css.policy": true, "vscode_custom_css.statusbar": false,

(The .css file is not used in this scenario.)

• Issue the F1 command 'Reload Custom CSS and JS' and you should be good to go. :-)

This reload needs to be done every time VSCode gets an update to a new version. You will also get a warning your VSCode installation is corrupted, which you can set to not display again. Both are behavior by design from the extension.

Overall, it works pretty well. If you use split editors or terminals, it will always (un)dim both panes, but I don't use splitting, so it's not a problem for me.

Let me know if you found it useful. :-)

(Something going wrong with the formatting of the code...)

[carldunham]

So where do we vote on this?

[mj-spencer]

So where do we vote on this?

@carldunham My understanding is that you thumbsup the first post in this github thread (jasonhulbert's original post), or, more generally, the thread for the feature you're voting for (I'm not part of the VSCode team, but info found here https://github.com/microsoft/vscode/issues/90091)

[ddnomad]

This would be such a nice feature to have. It is somewhat hard to determine what "pane" is currently active when cursor is set to underline, even if it is blinking. I do prefer this style of the cursor but not having any instant understanding of where I am after doing one of the navigate* shortcuts is kind of confusing.

[samwho]

If you're trying to use @ruudhanegraaf's custom JS above and finding it doesn't quite work exactly right with terminals being allowed in editor groups now, here's a modified version I came up with that seems to work:

for (element of document.querySelectorAll("*")) {
  element.addEventListener("focusin", doDimWindow);
}

function doDimWindow() {
  for (element of document.querySelectorAll(".monaco-editor,.terminal")) {
    if (
      element === document.activeElement ||
      element.contains(document.activeElement)
    ) {
      element.style.opacity = 1.0;
      continue;
    }
    element.style.opacity = 0.5;
  }
}

[tobobo]

I added an additional slight modification to @samwho's code so that all editors and terminals in a window dim if a window loses focus (so I can tell which window has focus if I have multiple windows open.

for (element of document.querySelectorAll("*")) {
  element.addEventListener("focusin", doDimWindow);
}

window.addEventListener("blur", doDimWindow);

function doDimWindow() {
  for (element of document.querySelectorAll(".monaco-editor,.terminal")) {
    if (
      (element === document.activeElement ||
      element.contains(document.activeElement)) &&
      document.hasFocus()
    ) {
      element.style.opacity = 1.0;
      continue;
    }
    element.style.opacity = 0.5;
  }
}

[distek]

I modified the modification of the modified code to instead show a border around the editor, panel, and sidebar views:

let div = document.createElement("div");
div.id = "focus-border";
div.style.position = "absolute";
div.style.left = 0;
div.style.top = 0;
div.style.width = "100%";
div.style.height = "100%";
div.style.zIndex = 100;
div.style.border = "solid 2px #7f7f7f";
div.style.pointerEvents = "none";
div.style.userSelect = "none";

document.getElementsByTagName("body")[0].appendChild(div);

window.addEventListener("blur", moveFocusBorder);
document.addEventListener("focusin", moveFocusBorder); // I think this is what you meant

function moveFocusBorder() {
  for (element of document.querySelectorAll(
    ".panel,.sidebar,.editor-group-container"
  )) {
    if (
      (element === document.activeElement ||
        element.contains(document.activeElement)) &&
      document.hasFocus()
    ) {
      let rect = element.getBoundingClientRect();

      document.getElementById("focus-border").style.left = rect.left + "px";
      document.getElementById("focus-border").style.top = rect.top + "px";
      document.getElementById("focus-border").style.width =
        rect.right - rect.left - 5 + "px";
      document.getElementById("focus-border").style.height =
        rect.bottom - rect.top + "px";

      document.getElementById("focus-border").style.display = "block";
      return;
    }
  }
    // hide the div if we're not in a tracked element
  document.getElementById("focus-border").style.display = "none";
}

New to JS so if anyone can improve the efficiency of this, please do.

[Tyriar]

We're moving back to a rectangle outline for the unfocused terminal, so that it's possible to differentiate regardless of cursor style. https://github.com/xtermjs/xterm.js/pull/4443

It's best if we can avoid adding yet another setting and I think this solves the issue for the most part.

[paladinu]

I don't think that issue is really solved at all in this case is it? It has just been decided not to address it?

[Tyriar]

@paladinu yes sorry, commented in the wrong tab 🤦

[paladinu]

No worries, I was just surprised! :)

[boettges]

If someone is still looking for a simple way to dim the unfocused Terminal using Custom CSS and JS, this got the job done for me:

/* Dim Unfocused Terminal */
div.terminal.xterm:not(.focus) {
    filter: opacity(0.7);
}

/* Hide Cursor of Unfocused Terminal */
div.terminal.xterm:not(.focus) > div.xterm-screen > canvas.xterm-cursor-layer {
    opacity: 0;
}

[abhijit-chikane]

This is closed but i dont see this happening in latest insider Is there any configuration for this?

[Tyriar]

@abhijit-chikane the current setting is "accessibility.unfocusedViewOpacity`. To improve discoverability, did you look for a setting and if so where did you search and what words did you use?

[lobsterkatie]

I looked under "inactive," "pane," "panel," and "dim." (I assumed it was going to be a boolean rather than a number.) Would never have occurred to me to look under "accessibility," as this seems not like an accommodation for someone who needs it but rather a display preference for everyone.

[Tyriar]

@lobsterkatie thanks, I'll tweak the description to include more keywords. I put it under accessibility as it makes it much clearer what element is focused, similar to the high contrast focus border in HC themes.

[abhijit-chikane]

@abhijit-chikane the current setting is "accessibility.unfocusedViewOpacity`. To improve discoverability, did you look for a setting and if so where did you search and what words did you use?

Sorry, I thought its a toggle dim/inactive unfocused terminal something like this

I think instead of putting it under accessibility it should be a generic setting and shouldn't it be a default behaviour with just toggle with preset opacity and have optional property to set the opacity?

Anyways thanks Appreciate your work!

[Tyriar]

think instead of putting it under accessibility it should be a generic setting

cc @aeschli about the setting name accessibility.unfocusedViewOpacity if you have opinions. Note that it's workbench-level, not editor.

shouldn't it be a default behaviour with just toggle with preset opacity and have optional property to set the opacity?

Thanks for the feedback. The rationale there is that 1 setting is simpler than 2, we typically combine settings where they can be naturally like this.

[aeschli]

Name is ok, but users will expect that all views and editors will support this, Is that on the radar? To turn the feature on of, a Boolean would be more intuitive. The opacity as such can be a secondary setting. I personally would try to come up with a good default and only add a setting if multiple users ask for it.

[Tyriar]

but users will expect that all views and editors will support this

Not so sure about this. The ask is mainly to make clear whether a terminal or editor has focus, dimming the explorer also for example would make the experience worse imo

Reopening to tweak the setting

[lobsterkatie]

As someone who's wanted this feature for a long time, I agree that the problem this is solving is really restricted to the editor and the terminal (i.e., the places where you're normally typing stuff), to prevent typing in the wrong spot.

P.S. While I'm here, I'll just make one more plea for this not being buried in accessibility settings. I'm guessing I'm not the only person who zips right by those (both in the settings json and in release notes), assuming they don't apply to me. I understand your reasoning that this might help someone with visual challenges, but then again, so might font size, and that's not an accessibility setting. I just think moving it into regular settings makes it a lot more discoverable.

In any case, thanks again for implementing this - looking forward to it being released! 🙂

[Tyriar]

@lobsterkatie do you have example(s) on what you would expect the setting to be called?

[lobsterkatie]

Hmmm... I want to say workbench.autoDimUnfocusedViews or workbench.view.autoDimUnfocusedViews, but I recognize that that's not 100% accurate, given that neither sidebar is affected (and those both count as views, correct?).

Maybe one option would be to use that and have the options be true, false (default), or {editor: <bool>, panel: <bool> } (with an explanation similar to that in workbench.panel.defaultLocation that the panel is where the terminal, etc live). That way, if you ever do decide to extend this to other views, they can just be added to the object option rather than having to spawn another option name. (There's precedent for settings being either a boolean or an object in task.problemMatchers.neverPrompt, for example.)

Thanks for considering this!

[ruudhanegraaf]

As someone who's wanted this feature for a long time, I agree that the problem this is solving is really restricted to the editor and the terminal (i.e., the places where you're normally typing stuff), to prevent typing in the wrong spot.

Completely agree. :-)

Concerning the name, maybe something like workbench.dimInactiveWorkArea? Since both the editor and the terninal are the areas you do your real work in? Though it's not a term many people will search for. But I think most people would search for 'dim'. I don't think many people would search for 'opacity'. Using 'Inactive' instead of 'Unfocused' would be more in line with other settings I think (like tab.inactiveBackground or window.inactiveBorder and all the other color/border settings).

[lobsterkatie]

Using 'Inactive' instead of 'Unfocused' would be more in line with other settings I think (like tab.inactiveBackground or window.inactiveBorder and all the other color/border settings).

Yes, I actually like inactive better also, as I agree it's significantly more intuitive - was just trying to match the current name of accessibility.unfocusedViewOpacity. But given that there's precedent for inactive, I'd vote for that over unfocused.

[Tyriar]

I considered inactive but problem with it is that technically there is an active terminal when the editor is focused and vice versa. This is just a technical thing, but regardless mixing these terms could be confusing:

https://github.com/microsoft/vscode/blob/85de2f21c63608e8bbc5c2347fe927b00c8300bf/src/vscode-dts/vscode.d.ts#L9668-L9673

https://github.com/microsoft/vscode/blob/85de2f21c63608e8bbc5c2347fe927b00c8300bf/src/vscode-dts/vscode.d.ts#L9755-L9759

[Tyriar]

Thanks for the discussion all, I tweaked the settings in https://github.com/microsoft/vscode/pull/190751.