Please enable a 'vi' editing mode for the mongo shell.

• Similar to vi mode in bash
• Similar to https://www.npmjs.com/package/mongovi

A first cut of key bindings would be:

Basic command mode/editing mode toggling:
i Insert before cursor
Esc Toggle to command mode

Cursor motion keys:
h Move left
j Move down
k Move up
l Move right

w Move to next word
b Move to the beginning of the word

0 Move to the beginning of the line
$ Move to the end of the line

And delete/change:
x delete next character to the right
d

{motion} delete amount specified by {motion}
c

{motion} delete amount specified by {motion}
and also put you in insert mode

There is an initiative in the tech community to replace non-inclusive terms with more inclusive ones and I'd like to get the community's take on it. I think the biggest offenders are terminology referring to "slaves" and "masters", but I'm sure there are others that might fall into that category. Although I'm sure nobody meant any harm by using these terms, I think we can and should do better.

I'm currently working my way through the m103 replication course and I see in replication configuring there's a term "slaveDelay". Also a "rs.isMaster()" method. I'm suggesting replacing "slave" with "worker" and "master" with "main". I know these changes have a gigantic impact logistically speaking, but I think it's time to prioritize the human impact.

An initiative like this ties into a larger movement across the tech industry to create a better, more professional workplace for everyone. See this article for a similar initiative taken on by GitHub: https://www.zdnet.com/article/github-to-replace-master-with-main-starting-next-month/#:~:text=By%20default%2C%20GitHub%20uses%20the,of%20a%20source%20code%20repository.&text=1%2C%202020%2C%20any%20new%20repositories,will%20be%20left%20as%20is.

This is a papercut in the legacy shell which would make the modern shell even more usable by comparison...

Currently, both the new and legacy shell have an issue with the way they store a multiline command (eg. when defining an aggregation pipeline) as a single line in its history.

Often (especially for aggregation pipelines) inputted commands will contain // comments. For example, see the code snippet 'var pipeline = [...];' here: https://www.practical-mongodb-aggregations.com/examples/simple-examples/group-and-total.html

The reason why this shell behaviour is problematic is discussed in the Practical MongoDB Aggregations book chapter at https://www.practical-mongodb-aggregations.com/guides/composibility.html
(scroll 2/3 down that page and read the 'punchout' text shown)

In short, if the command contains '//' comments it breaks when re-run from the history (even if the history command is not edited by the user). Need a way to allow the command to still be re-executed from history without failing (whether edited inline or left as-is, before re-running).

I don't have one single way to recommend about how this should be implemented, but some options (each with likely relative pros/cons) are:

1. When saving a multi-line command, in the shell's history, replace // comments with /.../ commands (but would have to be careful if some of the text already containing /.../ comments).

2. Store the version of the command retaining multi-line characters but then only show it in the history as a single line (this would be fine for just pressing Up followed by Execute, but might be problematic when editing the command between Up and Execute).

Also, ideally, when using an inline text editor, the inline text editor would show the history command with its multi-lines retained.

currently, when creating a role, we need to list one collection per db for custom role

db.getSisterDB('admin').createRole({role : 'readWriteCollectionXY',
privileges : [ {resource : {db : "databaseA", collection : "***"}, actions : ["find", "insert", "update"]},
{resource : {db : "databaseA", collection : "yyy"}, actions : ["find", "insert", "update"]} ],
roles : []
})

having an option to list all the collections in one db with the same permission would be a nice thing to have.

db.getSisterDB('admin').createRole({role : 'readWriteCollectionXY',
privileges : [ {resource : {db : "database_A", collections : ["***", "yyy"] }, actions : ["find", "insert", "update"]} ],
roles : []
})