Consider using monaco-editor in place of ace

[KSXGitHub]

Monaco is an embedded editor that is used by VSCode and TypeScript playground.

Why?

• It has more features out-of-the-box (such as right-click context menu, command palette F1, etc.).
• It is extensible (you can add themes, IntelliSense and whatnot).
• In theory, Rust Language Server should work well with Monaco as it does in VS Code. (related to Compile Rust Language Server into WASM to provide IntelliSense and completions #357)

[shepmaster]

• It has more features out-of-the-box (such as right-click context menu, command palette F1, etc.).

What purpose do these features serve? For example, what needs to go into the hypothetical context menu or command palette? How would these changes help the users of the playground?

• It is extensible (you can add themes, IntelliSense and whatnot).

Again, what purpose do these features serve? Who can add themes? If it's the playground implementers, that's already possible today. Who wants to add themes?

IntelliSense is a broad category of functionality. The current playground already has a form of autocomplete for crates. What aspects of IntelliSense do people want? What will provide the data for that?

• In theory, Rust Language Server should work well with Monaco as it does in VS Code

I'm pretty sure that there's several jumps to get from point A to point B here. Electron has access to many things that a browser does not.

[shepmaster]

I'm not against such a change, but I don't see any value in it at this moment. This feels like a "rewrite it in Rust" type of issue.

[KSXGitHub]

What purpose do these features serve? For example, what needs to go into the hypothetical context menu or command palette? How would these changes help the users of the playground?

Context menu allows extending functionality without cluttering UI.

What aspects of IntelliSense do people want?

All of RLS + VS Code:

• Pop-up that shows type annotation and documentation when user move their mouse cursor over a name.
• Jump to definition, peek definition.
• Symbols.
• Autocompletion.
• etc.

What will provide the data for that?

Electron has access to many things that a browser does not.

The same source the compiles and runs the code (which I'm pretty sure isn't the browser).

This feels like a "rewrite it in Rust" type of issue.

Unlike "rewrite it in Rust" which is essentially just refactoring into another language, this change changes functionality and user experience.

[shepmaster]

allows extending functionality without cluttering UI.

What functionality that doesn't exist now needs to be added? It seems like you are saying...

All of RLS

That's predicated on getting RLS to work at all in the playground environment. See a few points down.

• VS Code

This sounds like a misunderstanding of what Monaco and VS Code are. VS Code is much more than the editor. Using Monaco won't get you everything VS Code has, and that's before you consider VS Code extensions. For example, it appears that Monaco does not have Rust syntax highlighting at all. I have no doubt it could be added, but it's not "out of the box" functionality.

The same source the compiles and runs the code (which I'm pretty sure isn't the browser).

Now you are getting into internals of the playground. I suggest you skim the architecture summary to know how the playground works. There is no persistent process whatsoever, everything is done as a request/response cycle, completely creating an environment from scratch. RLS, on the other hand, is much more conceptually a long-running daemon process. The two concepts are fundamentally opposed to each other. That's why #357 focuses on getting it to work in WASM, so it could run in the browser.

which is essentially just refactoring into another language

None of the "other functionality" that you have proposed exists in the playground now and there's nothing to provide it, so yes, moving to Monaco is just moving to another language (well, library in this case) at this point in time.

this change changes functionality

Moving to Monaco will not magically cause any new functionality to appear. It might add new ways to access existing functionality, at best.

and user experience.

Changing user experience isn't (shouldn't be, at least) a goal of very many projects. User experience is a stepping stone to solving some greater problem. What are those problems that you are trying to solve?

It sounds like your goal is mostly to enable RLS-like functionality in the playground, and that may (or may not!) be a good idea, but doing that feels like an order of magnitude harder than changing the editor.

Once any aspect of that data is available, we can start to look at how to expose the information to the user. That might be via Monaco, it might be by using Ace, or there may be a completely different editor available at that point in time that's better than either.

[shepmaster]

Additionally:

❓ Is the [Monaco] editor supported in mobile browsers or mobile web app frameworks?

No.