Performance benchmarks:

I would love to hear your thoughts on this, @quaquel.

I think this is really nice.

Unfortunately, I don't have time to play around with it at the moment. However, I know you have been testing this extensively. I'll try to review soon, but I have various other obligations at the moment.

Started playing with it. I think it's great. Below is a WIP list of things I run into. Not all of this needs to be addressed in this PR.

1. Is it possible to "inherit" all imports from app.py? That is, populate the namespace of the console based on what is defined in the file from which the solara front end is started.
2. Great to have model readily available. This makes dynamically exploring the model easy.
3. It would make sense if the view jumps to the bottom after each command. Currently, I have to scroll down every time.
4. Is it possible to "force" and update of the display without calling model.step()? For example, If I update the wealth of an agent in the boltzmann wealth model, it would be nice if I see the color of an agent changing.
5. Currently, there are two windows: the console history and the line where you type new commands. Most consoles in IDE's integrate this into a single window where the last line is just where you type commands. Is something like this possible with this code base as well at some point in the future?
6. Discussion point: where to put the console? Currently, it is on the left-hand side, but this is getting quite crowded. I like the convention in most IDE's to have a console at the bottom right. How difficult would it be to do this at some point?
7. ...

1. Is it possible to "inherit" all imports from app.py? That is, populate the namespace of the console based on what is defined in the file from which the solara front end is started.

Don't know yet, it doesn't seem very plausible because those are the imports we can't see. Will try to find a way.

2. Great to have model readily available. This makes dynamically exploring the model easy.

Glad to know.

3. It would make sense if the view jumps to the bottom after each command. Currently, I have to scroll down every time.

This feature makes sense, I will try to incorporate it.

4. Is it possible to "force" and update of the display without calling model.step()? For example, If I update the wealth of an agent in the boltzmann wealth model, it would be nice if I see the color of an agent changing.

I think I've added that already in the recent commits, I also realized that was very annoying, that's why I added force_update() after every execution. Can you please check if that line is there in your code?

5. Currently, there are two windows: the console history and the line where you type new commands. Most consoles in IDE's integrate this into a single window where the last line is just where you type commands. Is something like this possible with this code base as well at some point in the future?

Most likely possible, but I will have to go through the solara documentation thoroughly for that (because just adding the enter took long enough).

6. Discussion point: where to put the console? Currently, it is on the left-hand side, but this is getting quite crowded. I like the convention in most IDE's to have a console at the bottom right. How difficult would it be to do this at some point?

same as the answer in the 5th. Plus I would love to get this PR merged and look back at the code when implementing the variable explorer, because that will also take up some space.

Thanks for the responses. None of these comments are blocking approval. They are merely a wishlist from my side.

1. Is what can be seen based on where you create the console?
2. Ok.
3. This would be the main thing to add if it is easy before merging
4. It is working, I just missed it. I do notice for boltzman that gini is not updated. I understand why given how all this is implemented, but for a future extension this would be nice to have (probably requires using some of the experimental signal stuff)
5. Ok
6. Ok
7. New wish: in most consoles, arrow key up gives you the last command. Is something like this available in code so that we can add support for the history of commands in the future?

1. The model instance that is to be used is passed onto the SolaraViz, that can be directly used in the console environment but that is not the case with other imports in the app.py. There may be some kind of way there, if I search hard enough I may find it, but not soon.
2. .
3. I am working on it now. Just found a source after searching a bit. Will see if be able to do it in the next 2 hours, otherwise it will be postponed until tomorrow.
4. Ok
5. .
6. .
7. I also want that, but its not easy to make custom key handlers that's the main reason it is postponed until now. Will try to ask some friends that are more knowledgeable in the javascript web development field. That may act as reference. (but also for me its a must have). About the implementation I think just extracting the last command in the current buffer will work, so code module won't be needed.

Auto-scrolling is implemented, simple fix I found was to use ChatBox from solara.lab which already contains this functionality.

Thank you very much @quaquel for starting the review. I, too, wanted to try it out before reviewing this PR. But I still haven't found the time to dedust my local mesa workspace.

Thanks for the responses. None of these comments are blocking approval. They are merely a wishlist from my side.

This should be quite important. I think it would be good to take those (very good) ideas to a follow-up PR and try to merge this soonish. Its an awesome PR, I can already tell without doing a proper review right now.

One request: can you add the console stuff to /docs/apis/visualization.md? I am wondering if some of the docstrings will render correctly.

I don't know how the doc stuff works, should I add this?

\## Command Console

\```{eval-rst}
\.. automodule:: mesa.visualization.command_console
   :members:
   :undoc-members:
   :show-inheritance:
\```

ignore the '\'

yes that should probably work

I will inform once I get the docs right, they seem a little off.

Yeah docs look good now, its good to go!

It would be good to open an overview issue with a wishlist of possible extensions based on the ideas discussed here.

Congratulations on getting this PR merged! Awesome feature already and really excited in what it can involve into!