Hmm. To make this extension work, we completely overload the enter key and handle line breaks and stuff. As you said its random, my guess would be that the extension host is crashing and the associated command does no longer execute.

But: It doesn't have to be this extension that is causing the host crash, I've seen this behaviour with a couple of other commands too in the past.

If it happens again, would you mind checking the Developer Tools (Menu Help->Toggle Developer Tools) and share the most recent lines from there? That might give at least a clue where to start looking…

I just now had the same issue. It only happens to certain files and disabling endwise fixed the issue. I restarted code several times as well.

I managed to reproduce the issue with this file:

#
module A
  module B
    module C
      module D
        module E
          class F

            description <<-EOD.strip_heredoc
            Blah blah
            EOD

          end
        end
      end
    end
  end
end

When I hit enter the Code Helper process goes to 100% cpu.

UPDATE: Well I've now done another couple of hours of extension wack a mole and I apologize because it seems endwise is not the issue. Not sure how I got to that in the first round.

The offending extension for me is highlight-matching-tag.

@wulffeld Already thought so, the code example didn't look to fancy to cause a problem in itself.

The way VSCode's extension architecture is designed makes it a little tough to find the proper cause of a freeze. There is a clear separation with the extension host running in a separate process to protect the editor itself from misbehaving plugins, which is brilliant.

But on the other side of the fence, all extensions run in the same process and have pretty much the same problem as every Node application: If a part of the system blocks the event loop, everyone gets stuck.

When I started this extension, I already had a bad gut feeling realising that I need to take over the Enter key completely as a keybinding. Not only does it need to handle the "end" 2 lines below the current cursor position, it literally writes the newline symbol, figures out the auto-indentation that would normally occur and then moves the cursor to the end of the next line.

I would have really preferred to just listen to a keypress event, let VSCode do its thing on the first line and only handle the next one appending the "end". But there is currently no API for doing so (as I remember, there was a reasoning behind not having keypress events).

Long story short, as soon as something is available to either use keypress events or release the binding when the extension host freezes, I try to work around this problem. But currently we are stuck with this and can only hope that other extension authors write code that doesn't crash. (But hey, at least I can now blame other programmers from time to time, that's nice too :D)