Idea | Track mode on a per-tab basis

[tmontes]

Picking up on an idea I shared in the context of #761 which I'm about to close, I wonder if Mu could "track/remember" its mode on a per-tab basis.

Possible usage:

• Open freshly configured Mu.
• Select PyGame Zero mode.
• Create and save your game: splatacat.py.
• Create a new tab / file / editor.
• Switch to Python mode.
• Create a turtle based drawing program: ninjaturtle.py.
• Activating the splatacat.py editor tab could automatically switch Mu to PyGame Zero mode.

This would make it easier for a beginner to quickly switch tabs and play around with recent projects.

Challenge:

• Could / should Mu remember the modes of "previously known files"?
• If we closed Mu and later reopened it, even with no files open at all, would it remember that splatacat.py is a PyGame Zero program and that ninjaturtle.py is a Python mode program?

Thoughts?

[ZanderBrown]

I've had this idea previously, may have even discussed it at Mu-moot, but I fear it adds too much complexity from both a code and UX perspective

Other thoughts:

• How would we know what tab is what mode? / How would mode be represented?
  • Icons on tabs?
• What mode would new tabs be?
• Why would you need different tabs to be different modes?
  • if your simply checking past code you don't need to be able to run it

[tmontes]

...sorry for the long-ish feedback delay (crazy work weeks as of late!): here are a few more ideas.

• How would we know what tab is what mode? / How would mode be represented?

  • Icons on tabs?

Switching tabs could update the "current mode indication" on the status bar.

• What mode would new tabs be?

Whichever current mode is active: if no tabs are open, the mode button would select the mode. Otherwise, a new tab would take the same mode as the current open tab.

• Why would you need different tabs to be different modes?

  • if your simply checking past code you don't need to be able to run it

I think the example I shared is reasonable: imagine a beginner's workshop where the first programs are Python mode, playing around with the turtle module. Later in the workshop beginners will learn about pgzero and create a few simple games with that.

It is not unreasonable for a beginner to have, say, two or three tabs with "different mode" programs... And while it is true that for "checking past code you don't need to be able to run it", the possibility of trying out a few changes and running it is valuable.

:-)

[ZanderBrown]

Switching tabs could update the "current mode indication" on the status bar.

Well that's a given but doesn't tell you what mode other tabs are

It is not unreasonable for a beginner to have, say, two or three tabs with "different mode" programs... And while it is true that for "checking past code you don't need to be able to run it", the possibility of trying out a few changes and running it is valuable.

Hmm, Still not convinced really

And that's a whole lotta extra state to track

I know @ntoll has said modes are based on vim's modes but I'm more of a nano person so not sure how that handles multiple tabs

[tmontes]

Switching tabs could update the "current mode indication" on the status bar.

Well that's a given but doesn't tell you what mode other tabs are

Oh, of course, I hadn't thought about that... I'm not sure that such indicators would be a fundamental feature, but I do understand your perspective.

Maybe the already visible "tab title / filename" is enough? The file/project name should be meaningful to the user, hopefully! :)

By comparison (and away from the Mu-world), I know that whenever I'm working on a given project I don't really think about its environment (and dependencies/virtual environment -- which could be thought of as the "Mu mode"): all that's on my mind is that I'm working on project A or B.

It is not unreasonable for a beginner to have, say, two or three tabs with "different mode" programs... And while it is true that for "checking past code you don't need to be able to run it", the possibility of trying out a few changes and running it is valuable.

Hmm, Still not convinced really

...and that is perfectly reasonable.

And that's a whole lotta extra state to track.

More state, yes. I'm not sure about the "whole lotta", but certainly more state. :)

A possible implementation could handle "per file/tab mode tracking" at load/save time:

• A save would save the edit buffer as it does today and also create a hash of its contents: such hash could be saved to a disk-based dict-like file mapping hashes to Mu modes.
• A load would load the file into a new edit buffer / tab, calculate the contents hash, lookup the mode in the disk-based map and, if present, set the tab mode to that.

Is that a "whole lotta" state? Well, maybe... The only challenge I foresee is a way of somehow pruning the disk-based map which could potentially grow indefinitely. But size-wise, I feel it would be a smallish thing when compared to, say, the logs that Mu produces. :)

I know @ntoll has said modes are based on vim's modes but I'm more of a nano person so not sure how that handles multiple tabs

I'm a vim user myself, but so old-school that whenever I need a new "vim tab", I spawn a new terminal/shell and vim instance, so I wouldn't know! :)

PARTING THOUGHT:

• I feel that this discussion, like others, is very interesting, regardless of the fact that it may or may not ever be implemented.
• Wondering if we could/should add a new "Ideas we have discussed in the past" section to the documentation, with links to GitHub issues: at least for those that we have discussed and decided not to implement. It could be valuable as a reference for people creating new issues with ideas for new capabilities and features, what do you say? :)

[dybber]

I think this is less about tabs, and more about projects. Like @ZanderBrown I think it will be too confusing for beginners to understand that the mode setting is not global. However, I can see the point that when a student loads a project, it might suggest "you're not in the right mode, do you want to change?"

I can't find the issue now, but I think it has also be suggested to have some kind of "project"-support in Mu, then it could be that when you load a project og swap between project it made such mode-change suggestions.

If we decide not to go for project-support, it could perhaps be implemented by looking through the import statements and suggest to change mode, if it looks incompatible with the current mode (import microbit in Python 3 mode)