Comment continuation (copy `//` to next line on enter) in VS Code?


Does anyone know how to configure, or what plugins can be used, to obtain comment continuation in VS Code? I'm finding myself writing a lot of doc comments in it lately, and it'd be great to have comment prefixes auto-inserted on newline.The behavior I'm looking for is as follows:

If I'm writing here:

//! some text here<cursor here>

And I press enter, I would like it to end up here:

//! some text here
//! <cursor here>

(I currently just end up with this:)

//! some text here
<cursor here>

I know I've found this behavior in other editors, like IntelliJ and kakoune. But I'm hoping to get this working in VS Code, as it's my current best option for writing Rust.

I'm asking this here as I would assume some of you have run into this - VS Code is one of the favored editors for Rust, and Rust's choice to prefer //! to block comments makes writing docs without this kind of feature pretty annoying.


1 Like

Unfortunately, this isn't implemented in vscode :frowning:

1 Like

Hmm, looking at that issue it seems like it should be implemented in the language extension?

Here's a PR for the RLS extension implementing it, as well:

Maybe I just need to install that? Currently, my only rust-related extension is rust-analyzer - I was worried about potential conflicts installing anything else.

Works for me although I wish it didn't since I find it annoying having to delete the comment in order to start writing code. :smiley:

I'm using rust and vim extensions. And some others but I don't know how relevant they are.

1 Like

Ah cool! It looks like installing the Rust extension adds it for me.

The only thing I'm worried about is the Rust extension supporting autocomplete, and somehow having settings for RLS, rust-analyzer and racer? I guess I'll try working with this and see if/how much it conflicts with the official rust-analyzer extension.


which rust extension. Not working for me. I'm using the official extension and rust analyzer

Rust extension lets you choose between RLS and rust-analyser although I didn't have much luck with that.

I ended up using a separate rust-analyser extension as well. It used to work fine before but now I've switched to VSCode running in Windows but the building happens "remotely" in WSL and maybe there's some interaction I haven't figured out.

I installed I already had/have installed.


Well, hmm. Maybe we can get this functionality PR'd into the rust-analyzer plugin, like it was into the RLS one? (assuming there isn't other functionality in the Rust plugin you're depending on)

For now running both of them concurrently seems to be working for me, though I haven't given it a thorough test. I've disabled the "Auto Start Rls" and "Enable code completion using racer" options in Rust, as well as switched the engine to rust-analyzer.

This used to be part of rust-analyzer, but it was causing problems. When rust-analyzer crashed or was slow, any enter press would be delayed for several seconds or never happen at all:

If you want you can add a keybinding:

"Preferences: Open Keyboard Shortcuts (JSON)"

    "command": "rust-analyzer.onEnter",
    "key": "enter",
    "when": "editorTextFocus && !suggestWidgetVisible && editorLangId == rust && ! || vim.mode == 'Insert' && editorTextFocus && !suggestWidgetVisible && editorLangId == rust"

To clarify, it is still very much a part of rust-analyzer, but it is opt-in, via defining a keybinding. The reason why it is opt-in is because we implement this feature in a non-conventional way, by using a real syntax tree and not a regular expression approximation. This is the proper ™ way to do this, but unforunately VS Code lacks an API to express this cleanly. So, we have to resort to a keybinding hack, which interracts poorly with, for example, vim extension.


And completely fails when the language server crashes (or fails to start up) :sweat_smile:

Is there a condition we can add to that long string to disable the keybind when the language server isn't running as well?

See this fixme:

If it's already implemented this way, I don't suppose the rust-analyzer plugin would accept a PR adding this to the plugin side (not the long server)? It would be more incorrect, but I'd much rather have that than to either need to install other rust plugins, or accept the lag on enter.

I didn't realize that this behavior is what was causing the lag, but I definitely appreciate it now being disabled by default. Having weird character lag and misplaced edits every time I made a newline was not pleasant, and one of the reasons I resisted using vs code for editing for quite a while.

I guess now I would be fine with accepting this as a PR. Rust-analyzer is moving into official-production, so it makes sense to compromise on the right way to do things in favor of better user experience. Would need to find a way to disable this for myself though :slight_smile: