Add menu to change console environments

[isabela-pf]

To make it easier to switch what a new console defaults to and to change the environment for an existing console, we can add a menu from the lower status bar similar to the language server to its left.

Here is my proposal:

The default option will always be at the top, separated from the other options, and has the (Default) label. All other options should be listed below alphabetically with a check (Material Icons check) to the left of whichever option is being used by the currently selected console.

To change the default, hovering over that option opens the secondary menu. It follows the same pattern of alphabetic listing and check for currently selected default/

[juanis2112]

@CAM-Gerlach what do you think about this? We are going to continue this discussion further so let us know what are your ideas for this.

[CAM-Gerlach]

We are going to continue this discussion further so let us know what are your ideas for this.

I thought we were all going to have a meeting about this to discuss it?

Overall, the root of the confusion we're grappling with here is how to best present two distinct concepts: the environment of the currently selected console, and the environment that new consoles open in, which related to two different common user tasks: determining what environment their current console is using, and opening a new console in a specific environment. After considering several approaches, I think the best way to both make this difference clear while offering an efficient, discoverable and easy to use UX is to separate them in the UI, putting each in a place appropriate to the task users are trying to accomplish, which closely matches both @mrclary 's and my proposals on spyder-ide/spyder#12200 .

Breaking them down one by one:

Opening a new console in a specific environment

When (and only when) the user is opening a new console, they need to know what environment it will be opening in by default, and have a way to easily select a different one, as they may be opening several consoles in different environments or want to open one console in a specific environment, without changing the default.

Current proposals

Current UX:

• - New console env shown in statusbar where it isn't needed most of the time and may not be obvious when opening a new console
• - Lengthy, tedious process to open a new console in a different env: open Prefs (with a long lag), go to the right tab, select the interpreter, apply the changes, open the console, go back to Prefs, re-select the original env (or the next desired env), and apply the changes again
• - Non-discoverable

Initial spyder-ide/spyder#13950 proposal:

• + Much much faster switching: just select the env from the statusbar, open the console, and reselect the next env.
• + Env type, name and interpreter are shown, vs. just path as in preferences
• - Users still have to change it back
• - Still in a very different place than where users actually open new consoles
• - There's confusion over whether this changes the env of the current console or new consoles.

@isabela-pf proposal:

• + Offers a way to change both the current console env and the new console env
• +/- Same upsides and downsides as 13950 proposal for opening a new one.
• - Requires another layer of menus to set the new console env, further away from the actual New console command
• - It wasn't immediately clear to me what "default" did vs. selecting an env in the top-level menu (esp. since a "default" doesn't make sense when there's no way to override it)

Recommended approach

• Add a dropdown menu to the Console menu and Console pane options/context menu, allowing the user to easily open a console in a specific environment other than the default with one click, without having to change and revert it, in the same, easily discoverable UI location as opening a console in the default env (as suggested by both @mrclary and myself)

• Change the (default settings) parenthetical in the Create new console UI text to be the name of the current default env for new consoles, as this is the one place the user actually needs to know it

• As @mrclary suggested, we should add another dropdown option to the Python interpreter selection in preferences listing the autodetected environments in a more user friendly form, informative and easy to read form (as they were originally listed in the status bar menu) with types, names and interpreter versions (right now they are just listed as paths).

Checking the current environment

When the user is working in a given console, they may want to check the current environment they are using. I'm not sure how necessary offering a menu to change it is, since as it would have to kill the current kernel and launch a new one, losing all of the user's variables and packages (unless we automatically save and restore the user's session), it has essentially the same effect (and the same number of clicks) as opening a new a new console in that env and closing the old one, but it could be a little more intuitive for users.

Current proposals

Current UX:

• - Doesn't offer this at all; new console env is shown in statusbar instead of current env, which is confusing

Initial spyder-ide/spyder#13950 proposal:

• - Same as current UX, except potentially even more potential for confusion with the popup menu

@isabela-pf proposal:

• + Displays current console env and allows selection of it
• - "Default" menu is potentially confusing and does not allow selection of the default interpreter for the current console

Recommended approach

Use the above proposal, just without the Default menu (which is handled separately, per the above), and with the env type, name and interpreter version shown for each env, as in spyder-ide/spyder#13950 and as @mrclary and others have proposed.

@mrclary , thoughts?

[mrclary]

@CAM-Gerlach, If I follow everything correctly, then I think I agree with your assessment. I believe this would be the summary of your proposal.

Checking the current environment

• The current environment should be displayed in the status bar (not the default new environment).
• I would also recommend moving away from status bar menus and have the status bar only display the environment of the current console. This would eliminate the need for an additional menu layer and stay consistent with the purpose of a "status" bar.

Opening a new console in a specific environment

• New environments can be opened (in a new tab) using the console menu or context menu, changing the existing menu item "New console (default settings)" to "New console"-> list of environments with "default" indicated.
• Keyboard shortcut opens console in designated default environment.

Run configuration per file

We have not discussed what to do about per-file run configurations, but currently we can set this to "Execute in current console", "Execute in dedicated console", or "Execute in an external system terminal". Under the existing and proposed paradigms, files executed in dedicated consoles can only use the designated default environment. I think we should consider updating this setting to include a selected environment to be used. I also think we should consider adding a setting at the project level, i.e. opening/switching projects opens consoles in the chosen environment. The environment would be set, in decreasing order of precedence, file -> project -> Spyder preferences.

Regarding the path display of environments in Preferences, I think that @steff456 is currently revising that to be more readable (i.e. type, name, version).

[CAM-Gerlach]

Yep, thanks @mrclary . That pretty much sums it up, with a few small notes (below).

I would also recommend moving away from status bar menus and have the status bar only display the environment of the current console. This would eliminate the need for an additional menu layer and stay consistent with the purpose of a "status" bar.

Yeah, I don't really see the need for per-console environment switching in the status bar; the utility is pretty marginal, potentially confusing and it doesn't feel intuitive to have commands in the status bar affect a specific console (especially a destructive action like this). I mainly included it because it was in your original proposal, so I figured you had a use case in mind.

New environments can be opened (in a new tab) using the console menu or context menu, changing the existing menu item "New console (default settings)" to "New console"-> list of environments with "default" indicated.

Keyboard shortcut opens console in designated default environment.

Unfortunately, many users are unaware of keyboard shortcuts or even don't like to use them at all, especially newer users likely to be potentially confused or intimidated by a list of environments to choose from. Therefore, I suggest retaining the existing separate top-level menu item to open a console in the default environment, to make it easier and more obvious to access, which is reflected in my mockup screenshot above. Also, how would you suggest clearly indicating the default environment in the list?

Run configuration per file

I definitely agree, we need to add that at some point, and as mentioned default environment is an ideal example for a project-level setting—I'm just not sure of the implementation status of the project improvements necessary for that, which you probably are more so than me.

Regarding the path display of environments in Preferences, I think that @steff456 is currently revising that to be more readable (i.e. type, name, version).

I see; this might already be in work, but especially if we make this change, we should revise the UI text in the preferences to eliminate the "default" wording for the build-in environment and just call it "same as Spyder", to avoid confusion with the default interpreter for new consoles (which this option is selecting) as well as the system, Anaconda, etc. default Python environment.

[mrclary]

@CAM-Gerlach

I mainly included it because it was in your original proposal, so I figured you had a use case in mind.

Sometimes I spitball ideas...doesn't mean they are good ;-)

I suggest retaining the existing separate top-level menu item to open a console in the default environment, to make it easier and more obvious to access, which is reflected in my mockup screenshot above.

I think this is just fine.

Also, how would you suggest clearly indicating the default environment in the list?

Usually, defaults are indicated with an asterisk * or (default) text and kept at the top of the list. However, given your suggestion, there would be no need for that.

[isabela-pf]

Replying to the meeting we had a few weeks ago, I generally agree with this, but I think there is some more work to be done around how information is communicated to the user.

Recommended approach

• Add a dropdown menu to the Console menu and Console pane options/context menu, allowing the user to easily open a console in a specific environment other than the default with one click, without having to change and revert it, in the same, easily discoverable UI location as opening a console in the default env (as suggested by both @mrclary and myself)
• Change the (default settings) parenthetical in the Create new console UI text to be the name of the current default env for new consoles, as this is the one place the user actually needs to know it
• As @mrclary suggested, we should add another dropdown option to the Python interpreter selection in preferences listing the autodetected environments in a more user friendly form, informative and easy to read form (as they were originally listed in the status bar menu) with types, names and interpreter versions (right now they are just listed as paths).

Below are some very rough ideas on what could be useful to add.

If we are going to have a potential split on how environments are applied, it would make sense to specify the different ways it influences the interface. I think this could be as simple as adding a syntax highlighting label to the status bar to show which environment the editor is currently relying on.

This could also be communicated through some kind of icon in the console tab. Something like this could make it easy to skim and quickly find which editor and environment are linked.

I also agree with the idea that changing the default environment should take more intention and happen in Preferences, though I don't know if it belongs in an existing section or if there should be a new section to accommodate this.

[mrclary]

If we are going to have a potential split on how environments are applied, it would make sense to specify the different ways it influences the interface. I think this could be as simple as adding a syntax highlighting label to the status bar to show which environment the editor is currently relying on.

Since this is handled by the LSP server, would it make sense to just append the LSP status with the environment used for completions/syntax? E.g. "LSP \<language>: \<env>" -> "LSP Python: conda: base (Python 3.7.6)"; it also seems redundant to have "ready" indicated since if LSP is not ready, then it either has a spinning wheel or indicates error.

[CAM-Gerlach]

Sorry I wasn't able to make the meting this morning; morning storms from the ongoing severe wx outbreak in MS and AL knocked out power and internet shortly beforehand. EDIT: Also, realized I never actually submitted this before I headed out on a research deployment.

I think this could be as simple as adding a syntax highlighting label to the status bar to show which environment the editor is currently relying on.

Overall, that seems like a fair solution, with some refinements.

Actually, its not syntax highlighting that uses this, but LSP services, most notably code completion, so we'd want to change the UI text accordingly (maybe "Code completion:"? But I'm not sure users would understand what it entails, though a tooltip, e.g. "Python environment used for providing code completions", might help).

Also, the status bar in the mockup is getting quite long and complex. However, assuming we go with your excellent idea to simply label each console tab with its environment rather than change the status bar indication to show the console env (which I think we all agree on, makes more sense conceptually, is clearer for users and is simpler to implement), the environment already shown in the status bar is the Editor completion/etc lookup environment (in the current working proposal you reference above, the default env for new consoles, which may or may not be the same depending on what we decide, is already shown the one place it matters, when creating a new console in the default env), so we could either:

• Simply pre-pend the extra UI text to the existing statusbar item; or
• [EDIT: As @mrclary suggests] Combine the LSP Python and Completion env entries in one item

I initially considered the latter due to being even shorter, but I'd lean toward the former, for the reasons discussed below

Since this is handled by the LSP server, would it make sense to just append the LSP status with the environment used for completions/syntax? E.g. "LSP : " -> "LSP Python: conda: base (Python 3.7.6)"

The main issue I see with this with this is it makes the status bar indication rather long and syntactically complex, i.e. LSP Python environment: conda - base (Python 3.7.6) [restarting], comprising two related but distinct status items and limits our flexibility if we do want to add a menu to select the environment at some point, add additional LSP options or adjust the UI text to be more specific to one or the other. So, I'd suggest just eliminating the entirely redundant environment listing, and just adding descriptive UI text to the existing one, which is also a much simpler change to implement and less of a break from the current UI, unless there are compelling reasons to do something else.

it also seems redundant to have "ready" indicated since if LSP is not ready, then it either has a spinning wheel or indicates error.

Yeah, but it provides a positive indication that LSP should be functional, as is done in the statusbars of other applications, at least on Windows (users may not just assume this if nothing is shown), and something would still be shown if it is restarting or here is an error, taking up as much if not more space. So not sure its worth it.

I also agree with the idea that changing the default environment should take more intention and happen in Preferences, though I don't know if it belongs in an existing section or if there should be a new section to accommodate this.

This is actually how it always has been, though a number of improvements have been made in recent versions; see Preferences > Python interpreter for how it looks currently. Or are you suggesting making the default LSP/completion environment and default Console environment entirely different settings (assuming we keep the former static, rather than dynamically following the active console)? I'm not sure its worth the considerable added complexity relative to the likely small number of users that would have a compelling reason to set them differently.

[mrclary]

I agree with @CAM-Gerlach regarding the general principle of consolidating the statusbar items, where possilbe. I think we both agree that the LSP server status is the right place to put the completion environment details.

However, I think that there needs to be clear communication about the console environment; a simple icon in the console tab will not be sufficient. Even if it clearly communicates that it is the "default" environment, I won't remember what that environment was, especially when working with multiple environments.

If we agree that a document should be linked to an environment, should we consider segregating the status bar into editor an console sections? Or should the Editor and Console widgets have their own statusbars, apart from the application statusbar?

[CAM-Gerlach]

@mrclary Sorry if I wasn't clear. What I was proposing was:

• Avoid overcomplicating the LSP status listing with the completion environment details for the reasons mentioned above; instead, simply add a descriptive UI text prefix to the existing default completion environment (what is already shown in the current statusbar)
• Don't add another lengthy and potentially confusing (as you say @mrclary ) statusbar item to track the current console env; instead, simply add the env name to each console tab (with a tooltip with full env details) as suggested by @isabela-pf elsewhere, where it is more clearly connected to what it describes, allows viewing the envs of all open consoles at a glance, and is simpler to implement.
• Show the default env for new consoles (which in practice would be the same as the editor's completion env, at least as implemented now) the one place it matters, in the "New console in default env (ENV-NAME)" menu listing, as in my original proposal

We do need to decide whether the Editor's completion env should follow the active console, or always default to the current default env set it preferences (which in the future will be configurable per-project). The former matches how the Editor runs files; they are sent to the active console, so we might already expect the user to have selected an appropriate console with the packages present to run their code, and is arguably the best heuristic we have to choose the most likely desired environment to get completions in, rather than whatever is the default selected in preferences, for users working in multiple at once. However, there were concerns related to latency switching between them, explaining this to users and matching user expectation, and its also more complex/more of change to implement. Regardless, the approach suggested above works for whatever we decide on that.

However, I think that there needs to be clear communication about the console environment; a simple icon in the console tab will not be sufficient.

I neglected to directly respond to it above, but I definitely agree the icon in the console tab is confusing—in fact, I'm not really sure what it is even intended to mean at all. If its the default env for new consoles, or the Editor's default completion env (presuming we keep the latter fixed in preferences, all) some or none of the currently open consoles could have this env, so users cannot rely on it being present nor indicate anything meaningful. Meanwhile, if it is supposed to indicate the completion env and we have that follow the active console, it is redundant with the already prominent indication of the active console tab. Either way, unlike UI text in the statusbar, I'm not sure it provides any additional value in actually telling the user what it means, and may in fact mislead more savvy users (those likely to get anything out of it) into thinking Editor completions are looked up dynamically in the indicated console instead of statically in whatever environment that console happens to correspond to (although I have heard plans to eventually do the latter).

[mrclary]

Don't add another lengthy and potentially confusing (as you say @mrclary ) statusbar item to track the current console env; instead, simply add the env name to each console tab (with a tooltip with full env details) as suggested by @isabela-pf elsewhere, where it is more clearly connected to what it describes, allows viewing the envs of all open consoles at a glance, and is simpler to implement.

My only concern here is cluttering the console tab, particularly for "Execute in dedicated console" where the document name is listed in the console tab.

We do need to decide whether the Editor's completion env should follow the active console, or always default to the current default env set it preferences (which in the future will be configurable per-project). The former matches how the Editor runs files; they are sent to the active console, so we might already expect the user to have selected an appropriate console with the packages present to run their code, and is arguably the best heuristic we have to choose the most likely desired environment to get completions in, rather than whatever is the default selected in preferences, for users working in multiple at once. However, there were concerns related to latency switching between them, explaining this to users and matching user expectation, and its also more complex/more of change to implement. Regardless, the approach suggested above works for whatever we decide on that.

I'm not sure what your intended meaning for "active" is. I don't think the Editor should necessarily follow the active (tab focused) console. I frequently use "Execute in dedicated console", so it always executes in it's own (possibly already open) console, regardless of which console tab has focus. For me, this links the document to an environment, albeit indirectly. It would be much better to link the document to an environment explicitly, whether directly configured, like the per file run configuration, or via project configuration, as we have discussed. The only issue then is how to handle the situation where the document env doesn't match the console env when one "Executes in current console":

• just use the (tab focused) console env anyway
• warn the user about the discrepancy
• open a new console
• or some combination of the above

[CAM-Gerlach]

My only concern here is cluttering the console tab, particularly for "Execute in dedicated console" where the document name is listed in the console tab.

Yeah; just displaying the env name and included the type, path, etc. in a tooltip this would help, or perhaps not show it for dedicated consoles if we have another mechanism for users explicitly setting this. That raises another question—we didn't consider the case of running files in dedicated consoles; therefore, we should presumably have a way to set the env to run in per-file, otherwise users have to constantly switch their default env to run different files (these suggested changes don't make things worse in that regard, but don't really address that case). However, this could solve two problems at once, this selected environment would both explicitly set the environment to run in (if "Run file in dedicated console/external system terminal" is used), and could also be used to retrieve completions for that file (if the overhead of switching envs in LSP is not so great, IIRC @ccordoba12 said he would look into that).

I'm not sure what your intended meaning for "active" is.

Currently selected tab; I didn't really consider the other two run config options, sorry.

It would be much better to link the document to an environment explicitly, whether directly configured, like the per file run configuration, or via project configuration, as we have discussed.

Coupled with the above approach (which it seems you're thinking of already), I agree this seems the most straightforward and workable solution, and more clearly and explicitly addresses the case of needing different envs for different source files as opposed to the originally proposed approximate heuristic of the currently selected console tab, and without increasing user confusion. The only potential issue is the latency of switching PyLS between envs (or the overhead of running a PyLS per env), but that is the case with any approach that doesn't use a fixed per-project completion env.

The only issue then is how to handle the situation where the document env doesn't match the console env when one "Executes in current console"

I guess this depends on whether you're referring to the dynamic case (running the code from a file) or the static case (providing static completions for it). Assuming we adopt the behavior you mention (do the lookup in the specified environment for the file if explicitly set, otherwise fall back to the default project env) then the currently active console (and thus the setting) doesn't matter, since the operation does not depend on the active console.

For the former, if no environment is explicitly set, and only the project-default env differs from that of the currently selected console, then naturally the status quo approach (just run it in the current console anyway) makes the most sense. For cases where an env was explicitly specified for a file, we could automatically switch to and run the code in the last active console with a matching env, which would handle a lot of cases but be far from perfect (what if the user wants to temporarily run the code in a different env? what if no console of that env is open? What if multiple are, and the desired console isn't the last-selected one? etc), so I'd think it would be simplest and least confusing to just follow the current behavior, though perhaps we could add the option for a warning under the "Current console" setting? (Warn if file's selected environment doesn't match). We'd have to think more carefully about this...

[mrclary]

The only issue then is how to handle the situation where the document env doesn't match the console env when one "Executes in current console"

I guess this depends on whether you're referring to the dynamic case (running the code from a file) or the static case (providing static completions for it). Assuming we adopt the behavior you mention (do the lookup in the specified environment for the file if explicitly set, otherwise fall back to the default project env) then the currently active console (and thus the setting) doesn't matter, since the operation does not depend on the active console.

I mean that the document env will always be used for completions (and the currently active console doesn't matter) but also be used for execution, in conjunction with the execution configuration (dedicated, external, active).

For the former, if no environment is explicitly set, and only the project-default env differs from that of the currently selected console, then naturally the status quo approach (just run it in the current console anyway) makes the most sense.

exactly

For cases where an env was explicitly specified for a file, we could automatically switch to and run the code in the last active console with a matching env,

I don't think this is good because both the env and the namespace are important. I think for dedicated consoles and external consoles, this is a non-issue. The conflict should only arise when executing in active console.

what if the user wants to temporarily run the code in a different env?

If they have the document env set and executing in dedicated/external console, they would have to temporarily relax/change one of these settings; there is no way around it. If the document env is set and executing in active console, then they could just run in the active console (with whatever env they setup there).

what if no console of that env is open?

If dedicated/external console is set, then this is a non issue. Otherwise, just run in active console.

What if multiple are, and the desired console isn't the last-selected one?

If dedicated/external console is set, then this is a non issue. Otherwise, just run in active console.

We can replace "document env" with "effective document env" in all of the above.

Summary

• If "Execute in dedicated console", behavior is the same as now, except the console will use the configured environment hierarchically: document->project->preferences default.
• If "Execute in external console", behavior is the same as now, except the console will use the configured environment hierarchically document->project->preferences default.
• If "Execute in active console", behavior is the same as now (environment configuration ignored).
• Completions always use configured environment hierarchically: document->project->preferences default.

Importantly, the above does not really change Spyder's existing behavior, we're simply checking for other environments in front of the default environment in preferences. If the document and project environments are not configured, then the behavior is exactly Spyder's current behavior. So maybe no warnings are required; everything seems pretty logical and what most users would intuitively expect...

[mrclary]

But perhaps we're diverting off topic. The issue at hand is how to communicate to the user the completion environment and the console environment...

Summary

• I think the console tab is fine for displaying console environment name with increment, e.g. "spy-dev 1" for environment "spy-dev". This is what Spyder currently does, except it uses the useless "Console" name :-). By the way, what is "/A" suppose to indicate? For dedicated consoles, currently the document name is used; this should remain since the environment would be implied by the file (with statusbar indication). Detailed information can be shown in the context menu (as suggested earlier) and in the tab browser.

• The existing statusbar environment really only indicates the completion environment (and default environment) since it does not change with active console. So this could be co-opted by the completion environment, and for good measure, consolidated in some way with the LSP status, since that is what the LSP service is providing. LSP/completions status will always follow the active document (which won't be dynamic until document/project env configurations are implemented)

[CAM-Gerlach]

I mean that the document env will always be used for completions (and the currently active console doesn't matter) but also be used for execution, in conjunction with the execution configuration (dedicated, external, active).

Right, I just wanted to make sure we were talking about the same basic thing

I don't think this is good because both the env and the namespace are important.

Yeah, as mentioned, neither do I. The questions I posed following it were intended to point out the shortcomings and complexities introduced in what at first seemed to me to be a reasonable heuristic, in support of the following conclusion that retaining the status quo behavior in this case as well (with potential future consideration for a warning or other options to handle it) was likely the best approach. That was what I meant by "so I'd think it would be simplest and least confusing to just follow the current behavior"; sorry for any confusion there.

I think for dedicated consoles and external consoles, this is a non-issue. The conflict should only arise when executing in active console.

Right; to be clear, the statements responding to your question related only to the "Current console" case, since that was the case posed.

Otherwise, just run in active console.

Exactly.

Summary

Agree with all, that was my understanding as well.

So maybe no warnings are required; everything seems pretty logical and what most users would intuitively expect...

Yeah, we can talk with our UX people and less-experienced users to make sure it wouldn't be confusing that they can select an environment but the code is still run in the current console i.e. its just used for static completion. I'd also think it might be useful to have some sort of optional warning or other behavior for cases where the user don't want their code to run in the wrong console, but this use case is probably pretty narrow.

We're planning to have a Zoom meeting to discuss this further and would really appreciate having you there for your great input, since you've been the biggest single contributor to making this change happen and provided incredibly valuable feedback, insight and analysis (we meant to invite you to the first one, but there was a mixup on my part); we'll reach out to you shortly with more details on that.

[CAM-Gerlach]

I think the console tab is fine for displaying console environment name with increment, e.g. "spy-dev 1" for environment "spy-dev".

Yeah, the 1 part would be the equivalent of the current stock name (Console 1), which would be editable, while the environment name would not be (like the current A). To make the separation clearer, we could do something like 1 (env-name), though if we do that, it would make sense for the number to increment with each console created, rather than each console created in that environment.

By the way, what is "/A" suppose to indicate?

I honestly have no idea; its not part of the user-editable name and is set separately. Looking at the code, it looks like it might be some sort of "client ID", but its not clear what it signifies, and I've never seen it anything different then A, even when connecting to a local or remote external console. Possibly its obsolete, or part of something that was never implemented. @ccordoba12 any help here?

For dedicated consoles, currently the document name is used; this should remain since the environment would be implied by the file (with statusbar indication).

Yeah, I think this is the simplest approach without inflating the tab name.

Detailed information can be shown in the context menu (as suggested earlier) and in the tab browser.

I actually suggested a tooltip, but the tab menu would be a great place too as you demonstrate

The existing statusbar environment really only indicates the completion environment (and default environment) since it does not change with active console. So this could be co-opted by the completion environment,

Right, that's what I'm proposing as well, so we just need to add some UI text (Completion env:, etc. which we can discuss and bikeshed over at the meeting); @isabela-pf 's input would be particularly helpful here

consolidated in some way with the LSP status, since that is what the LSP service is providing.

At first I favored this, but IMO I think its simpler to keep them as they are for now, as described previously:

The main issue I see with this with this is it makes the status bar indication rather long and syntactically complex, i.e. LSP Python environment: conda - base (Python 3.7.6) [restarting], comprising two related but distinct status items and limits our flexibility if we do want to add a menu to select the environment at some point, add additional LSP options or adjust the UI text to be more specific to one or the other. So, I'd suggest just eliminating the entirely redundant environment listing, and just adding descriptive UI text to the existing one, which is also a much simpler change to implement and less of a break from the current UI, unless there are compelling reasons to do something else.

But we can definitely see what the others think.

[juanis2112]

Thanks for your feedback @mrclary. We will have a meeting in two weeks to discuss this with @isabela-pf, @CAM-Gerlach and @ccordoba12. We will like you to join us since we think your input is very valuable! I sent the invite to your email, I hope you can join us.

[isabela-pf]

I second Juanita and want to say a big thanks for all your feedback! Here's my quick thoughts on what I'm seeing above.

Status bar

Console env in the status bar makes sense, but I do think it is describing something users might not know the consequence of. Is it common knowledge that the console environment determines code completion? If so, then I don't think this is a problem. I also don't think it looks too much shorter in terms of characters in my (very quick) mockup.

Console tabs

I think changing the naming convention is a great idea @mrclary! Admittedly, I also don't know what the /A is for 🙃. Based on your idea, it sounds like the behavior would be:

• If it is a console dedicated to a document, keep the document name (and number opened for that) as the console name like document name (#)
• If it is any other console, name it by the environment name like env name (#)

Does that sound correct? I think there is still a question here. If users can rename the consoles (as I think they currently can), where would they get the information if they overwrite the environment name?

[mrclary]

Per our conversation today, I should create a new issue for the following:

• Combine LSP and completion environment status bar widgets with syntax changes
• Create completion environment preference heirarchy: document->project->default

Is that correct?

[CAM-Gerlach]

Sounds good to me, @mrclary . Thanks again for all your great input! And I believe @isabela-pf mentioned she would summarize our discussion today, once she gets the time.

[isabela-pf]

Here I am! Based on our meeting, this is what I think we’ve agreed upon. I’ve broken it up by UI region to make it easier to track.

Status Bar

Add a new item to the status bar to clarify how code completion fits in with the environment changes. This looks almost the same as my previous mockup, but uses the text Completion to cut out a few more characters. I also am using the Material icon code-parentheses-box.

Console tabs

Change the way consoles are automatically named so that it includes relevant information.

• Most consoles will be console number (environment name) such as 1 (Python 3.7.6) The console number is an editable area that users can rename, and the environment name cannot be changed.
• Consoles tied to a document keep the document name (environment name) pattern like untitled.py (Python 3.7.6).

We want to truncate long console names with ellipses in the middle, but since I wasn’t sure whether this was just for the editable part of the console name or included the environment name too I have not provided an example.

Preferences

Add a message to the default environment switcher to tell users that it also determines code completion. For easy copy and pasting, I wrote Select the Python interpreter used for default Spyder consoles and code completion. That looks like this:

Context menu

Add a New console in environment option in the console menu. This was the portion agreed on above, but for the sake of collecting it all in one place I’ll quote @CAM-Gerlach’s image once again.

Let me know if I've missed anything and if you have any questions!

[mrclary]

@isabela-pf, I thought we decided to just update the LSP server status widget and get rid of the others. Pattern might be something like "Completion \<status icon> (\<language>): \<env type> \<env name> (\<py version>)".

I also think that the console tabs might be better to show the environment name than the Python version (if both is too long), e.g. "(conda base)" instead of "(Python 3.7.6)".

Otherwise I think they all look great! Thanks for all your hard work.

[CAM-Gerlach]

Thanks for the detailed summary @isabela-pf ! A few issues do remain, however:

This looks almost the same as my previous mockup

As discussed in the meeting and @mrclary mentions, the Completion env: UI text just needs to be appended to the existing environment name widget; there is no need for a new widget that displays identical information. We might also consider swapping the current icon for the new one you propose, if that would be clearer.

but uses the text Completion to cut out a few more characters.

I personally find "Completion env" to be a necessary clarification, as many users may not automatically know the name listed after represents and environment, and eliminating the redundant item (and potentially combining the LSP and completion env ones) will save far more space than the 4 characters this does. But we can discuss it next meeting if needed.

Consoles tied to a document

Your textual description is correct, but the number shown in the mockup is redundant and potentially confusing, as only one console can be tied to a given source file at a time.

Most consoles will be console number (environment name) such as 1 (Python 3.7.6)

As discussed at the meeting and previously on this issue, and as @mrclary also mentions, we all agreed the name shown should be the environment name (not the Python version, env type, path, etc). The Python version is typically quite unhelpful at identifying an environment, as it is less descriptive, is not unique (many environments may share the same runtime) and is already displayed at console startup. The Python version, env type, and maybe even full path can be displayed in a tooltip shown hovering over the console tab.

We want to truncate long console names with ellipses in the middle, but since I wasn’t sure whether this was just for the editable part of the console name or included the environment name too I have not provided an example.

Actually, it is neither; it is for the environment name only. The user can set the console name however long or short they want, and Spyder will respect that; as it is only used for allowing users to quickly tell their consoles apart at a glance, any additional characters not displayed serve no practical purpose. However, the environment name may be arbitrarily long and cannot be easily changed, but typically only a subset of its characters are needed to uniquely identify it, typically those on the ends. Therefore, the current proposal for truncation, for a console named My Console and and environment my-very-long-environment-name-3, would be something like My Console (my-very-l...name-3).

For easy copy and pasting, I wrote Select the Python interpreter used for default Spyder consoles and code completion

It should read and code completion in the Editor, as this is only used in the latter, not the Console. Otherwise, looks good to me.

I thought we decided to just update the LSP server status widget and get rid of the others.

@mrclary I thought we tentatively agreed on that but decided to split that out to a separate issue in this repo that you offered to open with the latest version of the current proposal, since the implementation is potentially rather complicated due to how the plugins are structured and essentially orthogonal to the other changes here? Thanks again for your awesome feedback at the meeting!

[mrclary]

@mrclary I thought we tentatively agreed on that but decided to split that out to a separate issue in this repo that you offered to open with the latest version of the current proposal, since the implementation is potentially rather complicated due to how the plugins are structured and essentially orthogonal to the other changes here? Thanks again for your awesome feedback at the meeting!

Perhaps I'm confused, then. I thought we decided on the following:

1. This issue (#10) covers the environment menu and Console tabs, and we are all in good agreement.
2. This issue spawned related, but separate, implications for the status bar. Currently we have two status bar items: a) LSP server language and status; b) interpreter environment type, name, and Python version. The latter is problematic since it is not necessarily related to any existing console (this info is covered by #10), and really reflects the completion environment and new console environment. Since the LSP server handles completions anyway, the latter status bar widget should be removed and the "completions" environment listed in the LSP server status bar widget, with the "LSP" text replaced with "Completion", or some variant syntax. This is what the new issue is supposed to cover. There is some uncertainty whether this can be easily accomplished in the near term for Spyder 5 or whether this won't play nice with the current plugin structure and will have to wait until Spyder 6. I think it should be okay, since it won't be changing any of the underlying code behavior, but we were going to submit the PR and let Carlos decide.
3. The other spawned issue was regarding hierarchy of completion environments: document->project->default. This was the other issue that I'm to create. This has less to do with the user interface and more to do with underlying preferences and code behavior, so maybe this gets created in the spyder repo. This will most certainly be looked at later for Spyder 6.

[CAM-Gerlach]

Perhaps I'm confused, then. I thought we decided on the following:

Yup, that was my precise understanding as well. The part I'm confused on from your previous message is

just update the LSP server status widget and get rid of the others

which, based on your mockup, is what I understood to be item 2 from the above (i.e. the separate issue), as opposed to something covered by this issue (just a simple UI text tweak of the existing item, with no other status bar changes, to more clearly indicate it is the completion env). Could you help me understand your intent here? Thanks!

[mrclary]

Perhaps I'm confused, then. I thought we decided on the following:

Yup, that was my precise understanding as well. The part I'm confused on from your previous message is

just update the LSP server status widget and get rid of the others

which, based on your mockup, is what I understood to be item 2 from the above (i.e. the separate issue), as opposed to something covered by this issue (just a simple UI text tweak of the existing item, with no other status bar changes, to more clearly indicate it is the completion env). Could you help me understand your intent here? Thanks!

Okay, I thought #10 did not include any changes to the status bar, just the menu and tabs for the console. Isabela's mockup showed an additional status bar widget, instead of a reduction; although this should be in a new issue, I just wanted to clarify what I thought was an error.

I suspect that my item 2 amounts to just a text tweak for the LSP status bar widget and removing the console environment status bar widget, which is why I don't think we'll have to wait for Spyder 6. But just to keep things clean, I recommend leaving the status bar alone for #10 and then refresh our status bar discussion in the new issue.

[isabela-pf]

@isabela-pf, I thought we decided to just update the LSP server status widget and get rid of the others. Pattern might be something like "Completion (): ()".

I am personally fine with that, I thought there was some technical reason blocking this at the time, so I'll double check.

I also think that the console tabs might be better to show the environment name than the Python version (if both is too long), e.g. "(conda base)" instead of "(Python 3.7.6)".

I agree; that's my mistake!

I personally find "Completion env" to be a necessary clarification, as many users may not automatically know the name listed after represents and environment,

That sounds fair to me. I can put the env back in.

as only one console can be tied to a given source file at a time.

I didn't know that. Thanks for the clarification. I'll remove the number then!

Therefore, the current proposal for truncation, for a console named My Console and and environment my-very-long-environment-name-3, would be something like My Console (my-very-l...name-3).

Makes sense to me.

It should read and code completion in the Editor, as this is only used in the latter, not the Console. Otherwise, looks good to me.

Thanks again for the clarification! Noted.

[CAM-Gerlach]

I am personally fine with that, I thought there was some technical reason blocking this at the time, so I'll double check.

Yeah, that's per @ccordoba12 , we would have to investigate that further. so my understanding is that we're just going to simply add the Completion env: UI text to the existing environment status bar item (since its trivial to implement) and split further work on this (i.e. @mrclary 's proposal) out to another issue, where we can refine the UI/UX and determine what needs to be done to implement it.

Otherwise, I'm :+1: on everything. Thanks!

[CAM-Gerlach]

@mrclary Sorry, thought I sent this yesterday night.

Gotcha; my understanding was that we would do the UI text tweak since its so trivial to do (so long as we agree on what the text should read), and to match the similar change in preferences. This would avoid any added confusion as to what the statusbar indicates, given environment names will also be shown in the console tabs and the console menu, if and until the status bar PR gets merged.

Isabela's mockup showed an additional status bar widget

Yeah, I mentioned that as well; I believe that may have been an accidental holdover from previous mockups before we decided to put the current console envs in their respective tabs.

I suspect that my item 2 amounts to just a text tweak for the LSP status bar widget and removing the console environment status bar widget, which is why I don't think we'll have to wait for Spyder 6.

I believe the potential difficulty here that Carlos is citing may be due to the API is overhauled in Spyder 6, with various widgets split out to individual plugins with minimal interdependencies. That said, unless it would require significant re-archetecting, it wouldn't necessarily push implementation to Spyder 6, but it does make sense to do it in a separate PR since the two features are essentially independent implementation-wise and gives us more flexibility.

[mrclary]

It seems to me that the text "Console X/A" in the console tab does not provide any useful information. Since we are implementing the <type>: <env name> in the console tab (#20421), I think "Console X/A" should be removed.

[dalthviz]

So checking the way the console naming is currently working there are some currently managed cases:

• Dedicated console: For example __ini__.py/A
• Special console: For example Pylab 2/A
• Different client same kernel: For example Console 3/A and Console 3/B

Regarding the different client same kernel possibility, I think the logic uses the letter to distinguish since the tab name is kept so if the initial client connected is Console X when connecting to the same kernel from a different console client you get a Console X/B tab name, so a new client gets the C and as full tab name Console 3/C:

With the addition of the new info about the environment this could end up being something like:

• For dedicated console: __ini__.py (env_name)/A
• For special consoles: Pylab 2 (env_name)/A
• Different client same kernel: Console 3 (env_name)/A and Console 3 (env_name)/B

Following the idea of @mrclary of removing the Console text then instead this could end up being:

• For dedicated console: __ini__.py (env_name)/A
• For special consoles: Pylab 2 (env_name)/A
• Different client same kernel: 3 (env_name)/A and 3 (env_name)/B

From the usage of A, B C, etc letters seems like @mrclary also thinks that this identification could be removed so the console client tab name could end up being:

• For dedicated console: __ini__.py (env_name)
• For special consoles: Pylab 2 (env_name)
• Different client same kernel: Console 3 (env_name) and Console 3 (env_name)

[CAM-Gerlach]

• For dedicated console: __ini__.py (env_name)

• For special consoles: Pylab 2 (env_name)

• Different client same kernel: Console 3 (env_name) and Console 3 (env_name)

I definitely prefer this; I find the A/B/C confusing and noisy and never actually knew what it meant despite using many consoles, and "Console" is redundant since its in the IPython console pane and clearly a console. Otherwise, it would be even longer and more confusing with this new addition.

[mrclary]

• For dedicated console: __ini__.py (env_name)
• For special consoles: Pylab 2 (env_name)
• Different client same kernel: Console 3 (env_name) and Console 3 (env_name)

I definitely prefer this; I find the A/B/C confusing and noisy and never actually knew what it meant despite using many consoles, and "Console" is redundant since its in the IPython console pane and clearly a console. Otherwise, it would be even longer and more confusing with this new addition.

Perhaps

• For dedicated console: __ini__.py (env_name)
• For special consoles: Pylab (env_name)
• Different client same kernel: (env_name) and (env_name)

[dalthviz]

Perhaps

* For dedicated console: `__ini__.py (env_name)`

* For special consoles: `Pylab (env_name)`

* Different client same kernel: `(env_name)` and `(env_name)`

Or removing Console and kernel client id (A, B, etc) but keeping the number?:

• For dedicated console: __ini__.py (env_name)
• For special consoles: Pylab 1 (env_name)
• Different client same kernel: 1 (env_name) and 1 (env_name)

[mrclary]

Perhaps

* For dedicated console: `__ini__.py (env_name)`

* For special consoles: `Pylab (env_name)`

* Different client same kernel: `(env_name)` and `(env_name)`

Or removing Console and kernel client id (A, B, etc) but keeping the number?:

• For dedicated console: __ini__.py (env_name)
• For special consoles: Pylab 1 (env_name)
• Different client same kernel: 1 (env_name) and 1 (env_name)

What is the 1 supposed to communicate?

[dalthviz]

What is the 1 supposed to communicate?

It would work as the default way to differentiate consoles using the same env, so you can have

1 (env_name) 2 (env_name) 3 (env_name)

Instead of:

(env_name) (env_name) (env_name)

[CAM-Gerlach]

One issue though is that the numbers are counted sequentially for all consoles, but the position of the number after the "Pylab", etc., implies they are counted separately for each type of console. It also could potentially cause a little confusion as to whether the number implies something about Pylab, Sympy, etc. specifically, Removing the number side-steps the issue, but it could be avoided while keeping the number (which takes up little space and can certainly be useful) by changing it to

• Regular consoles: 1 (<env name>)
• Dedicated console: __ini__.py (<env_name>)
• Special consoles: 1 - Pylab (<env_name>)
• Different client same kernel: 1 (<env_name>) and 1 (<env_name>)

[mrclary]

Can we number the consoles only for duplicate console tab text, similar to what most file explorers do when creating new files or folders?

• For dedicated console: __ini__.py (env_name)
• For special consoles: Pylab (env_name), 1 Pylab (env_name)
• Different client same kernel: (env_name), 1 (env_name), and 2 (env_name)

[CAM-Gerlach]

In that case, if we change the numbering scheme to enumerate duplicates rather than being sequential (which would IMO be a good idea, and would further improve the tab titles), I would suggest some changes:

• The number needs to go after the unique part of the name since it serves as the least significant bit rather than the most significant bit, and is also naturally the convention used by file managers
• The putting it in parenthesis would follow the conventions of file managers to indicate a successive same-named file:
• The number should start at 2, to avoid ambiguity and confusion
• Fix the numbers for the different client/same kernel case
• Ensure the other usages (parenthesis, etc) are consistent between name types

Thus:

• Regular consoles (different kernels): <env_name>, <env_name> (2), <env_name> (3)
• Dedicated console: <env_name> (__ini__.py)
• Special consoles: <env_name> - Pylab, <env_name> - Pylab (2)
• Different client same kernel: <env_name> and <env_name>; <env_name> (2) and <env_name> (2)

The "different client same kernel" case isn't quite as intuitively clear as before, but given that is rarely used and mostly for advanced users, that's less of a concern than not compromising clarity and conciseness for the other cases (which changing it would require).

[mrclary]

• Regular consoles (different kernels): <env_name>, <env_name> (2), <env_name> (3)
• Dedicated console: <env_name> (__ini__.py)
• Special consoles: <env_name> - Pylab, <env_name> - Pylab (2)
• Different client same kernel: <env_name> and <env_name>; <env_name> (2) and <env_name> (2)

I like this, except possibly - for the special consoles. Nevertheless, I agree that the console number is the least significant bit and any tab with the same tab text is using the same kernel; if the tab text is different, then different kernels. Thus the enumeration distinguishes between consoles of the same type but using different kernels.

The "different client same kernel" case isn't quite as intuitively clear as before, but given that is rarely used and mostly for advanced users, that's less of a concern than not compromising clarity and conciseness for the other cases (which changing it would require).

Indeed, I don't see any use case for multiple Spyder consoles connecting to the same kernel. Two consoles connected to the same kernel in Spyder will have exactly the same namespace, etc. What purpose does this serve? It's just a duplicate console 🤷🏼 . Connecting to the same kernel has advantages for different applications, for example if I want to connect a Spyder console and a Jupyter notebook to the same kernel, then both applications have access to the same namespace across applications.

[ccordoba12]

I agree with most of @CAM-Gerlach's last suggestion. The only thing that it's not clear to me is the Different client same kernel convention. What if preserver the A/B/C tags we already have? I mean, we could got with something like:

• Different client same kernel: <env_name>, <env_name> (A), <env_name> (B)

It's not super intuitive, but it follows the same convention of Regular consoles (different kernels), which perhaps could make users better understand what's going on there.

What do you think?

[ccordoba12]

Other things to consider are that haven't been discussed before:

• Should we preserve the current naming convention for consoles that are not associated to envs (minus A/B/C)? I mean, how should we name consoles attached to /usr/bin/python or Spyder's default env?
• How are we going to present the Special consoles menu now? Perhaps three entries per env (Pylab, Sympy, Cython), then a separator, then three other entries for the next env, etc?

[CAM-Gerlach]

What if preserver the A/B/C tags we already have?

I guess we could have it be as you suggest, e.g. <env_name>, <env_name (2), <env_name (2A), etc., so long as the "same kernel" letter isn't shown on the first console (which I believe your suggestion indeed omits). I suppose it doesn't do much harm if few people use that feature anyway, so long as it isn't shown when it isn't being used.

Should we preserve the current naming convention for consoles that are not associated to envs (minus A/B/C)? I mean, how should we name consoles attached to /usr/bin/python or Spyder's default env?

Hmm, good point. IMO, in most of those cases we still have some kinda name/identifier for the environment we can use, e.g. base for Anaconda base, , default or spyder_default Spyder's runtime env/default working env, or system for the user's system Python on macOS or Linux. For any others, we could use Python X.Y.Z (i.e. the version) as the name, which would presumably be very helpful since typically users with multiple base Python installs do so because they each have different Python versions. So there's no need to fall back to the old, potentially confusing different scheme.

How are we going to present the Special consoles menu now? Perhaps three entries per env (Pylab, Sympy, Cython), then a separator, then three other entries for the next env, etc?

Instead of doing all that which would be long and hard to read, I would just make Pylab, Sympy and Cython sub-menus of their own with a list of environments under that, with the first one being the default.

[mrclary]

• Different client same kernel: <env_name>, <env_name> (A), <env_name> (B)

I still don't know of any compelling reason to identify kernels. Every console has its own kernel. The only way to have two separate clients with the same kernel is to explicitly connect to an external kernel again. Why would anyone have two consoles (in Spyder) using the same kernel? Just to take up more tab space? Am I missing something here? I think we'd be better off just alerting the user that they already have a client connected to that kernel, rather than duplicating consoles.

Hmm, good point. IMO, in most of those cases we still have some kinda name/identifier for the environment we can use, e.g. base for Anaconda base, , default or spyder_default Spyder's runtime env/default working env, or system for the user's system Python on macOS or Linux. For any others, we could use Python X.Y.Z

Agreed.

How are we going to present the Special consoles menu now? Perhaps three entries per env (Pylab, Sympy, Cython), then a separator, then three other entries for the next env, etc?

I think that would be good. As far as the console tab goes, how about a small icon in the tab that indicates IPython, Pylab, Sympy, or Cython? We just need 4 different icons. Can the tab have hover text? If so, the hover text could show all information: console type, environment type (conda), environment name and/or path (conda, venv, system, etc.), Python version, kernel identifier, ...

[CAM-Gerlach]

I think that would be good. As far as the console tab goes, how about a small icon in the tab that indicates IPython, Pylab, Sympy, or Cython? We just need 4 different icons.

As mentioned in my previous reply, this would mean the submenu is four times as long (which could increase to an unbounded length depending on the number of user environments), and also make the text horizontally longer and more repetitive. If having the special consoles as submenus in a submenu is too many layers of nesting (not an unreasonable position), IMO it would be better overall to just put the submenu for each console type directly in the top-level Consoles menu/context menu; it's only three more lines total.

[ccordoba12]

Hmm, good point. IMO, in most of those cases we still have some kinda name/identifier for the environment we can use, e.g. base for Anaconda base

What if users don't venture into using envs and just use the base env for all their computations? In that case, consoles would be named base, base (1), etc, which I think it'd be really confusing for newbies. They could ask: why consoles are not named Console 1, Console 2, etc (as before) and instead they have this weird base name?

default or spyder_default Spyder's runtime env/default working env

This is kind of the same scenario as the above one, but for our installers, i.e. consoles would be named default, default (2), etc, which I also find confusing for newbies and people not familiar with envs.

For any others, we could use Python X.Y.Z (i.e. the version) as the name, which would presumably be very helpful since typically users with multiple base Python installs do so because they each have different Python versions.

And what if two non-env installations have the same Python version? For instance, two Homebrew and MacPorts Pythons? In that case the Python version is not enough, unless we have Python X.Y.Z (2), Python X.Y.Z (3), etc, to be consistent.

What I'd like to highlight with my previous comments is that you (i.e. both @CAM-Gerlach and @mrclary) seem to be optimizing the naming convention for envs. And I think using envs is still an advanced feature that perhaps not many people rely on. So, I propose that we keep using Console X when the default interpreter is selected in Preferences. In that way, consoles attached to envs would be treated as our other special consoles (Pylab, Sympy, dedicated, etc) by having a different name. And I guess users should have no problem to get familiar with them due to that.

Instead of doing all that which would be long and hard to read, I would just make Pylab, Sympy and Cython sub-menus of their own with a list of environments under that, with the first one being the default.

That's a very good idea. I agree with it.

[ccordoba12]

I still don't know of any compelling reason to identify kernels. Every console has its own kernel. The only way to have two separate clients with the same kernel is to explicitly connect to an external kernel again. Why would anyone have two consoles (in Spyder) using the same kernel? Just to take up more tab space? Am I missing something here? I think we'd be better off just alerting the user that they already have a client connected to that kernel, rather than duplicating consoles.

I disagree. First, because it'd be a regression in functionality that is quite simple for us to support. And second, because you can have a console filled with results that you don't want to clear, but you could need to run another computation in the same kernel that can have lots of output. In that case, the most natural thing is to connect another client to the same kernel.

[ccordoba12]

IMO it would be better overall to just put the submenu for each console type directly in the top-level Consoles menu/context menu; it's only three more lines total.

I think having three additional submenus for Pylab, Sympy and Cython inside the Special consoles submenu is fine.

[mrclary]

a console filled with results that you don't want to clear, but you could need to run another computation in the same kernel that can have lots of output.

Thanks @ccordoba12, I had not thought of that.

[mrclary]

This may help clarify my thoughts and perhaps be useful to others as well. So take it for what it is worth.

Goals:

1. We want to provide as much information as possible about the console
2. We want to do so as efficiently as possible, reducing clutter and confusion

Information that should be communicated:

1. Console type: IPython, Pylab, SymPy, Cython
2. Console environment
   • Name: environment name, "System", or "Spyder"
   • Type: conda, pyenv, venv
   • Environment filepath
   • Python version
3. Dedicated console: file name
4. Kernel

Questions:

1. Are there other means to communicate these in addition to tab text? For example, icons, colors, font weight, or whatever.
2. Is hover-text possible with the console tab? This may provide a convenient place to list all the information verbosely while keeping the UI clean.
3. Do we need to distinguish between consoles with identical identifiers? The set of information above will distinguish between consoles if any of the identifiers differ. But what if they are all the same: same console type, exactly the same environment, connected to the same kernel. Do we need to distinguish consoles under this circumstance?
4. Which information is most important, which should be tab text, which should be an icon, which should be displayed elsewhere?

Comments:

1. It seems to me that the console type is a prime candidate to be displayed as an icon in the console tab: there are only four possibilities and all are known.
2. If hover-text is possible, then verbose information displayed there may relieve some of the need to communicate more in the tab text.
3. We've discussed elsewhere removing the console status widget, but maybe that should instead be updated to display something regarding the focused console rather than the default console. Maybe the console type icon could go here instead of in the console tab. Maybe the environment type could go here as well, instead of the console tab.
4. Let's not forget that the user can edit the console name to be whatever he wants, so the burden of distinguishing consoles under every circumstance may not have to be our responsibility.
5. Perhaps the environment name is not the most important information. In my own use, I usually use dedicated consoles for files and all using the same environment. I switch environments from time-to-time, but that is related to changing projects. If (when) we implement project specific consoles, or having multiple projects open simultaneously, then the relevant identifier for me will be the project, not necessarily any environment information.