1. 24

  2. 8

    Heh, this tears me apart a bit. I am a huge proponent of using full language semantics to drive all IDE features. It doesn’t feel right to me that the editor’s front-end does approximate tokenization, while there’s a language server that knows the semantics exactly and doesn’t have trouble with eg <. Ideally, we’d just always use the pedantically correct fully semantic aware answer, right?

    But there are features in IDEs which are latency-critical (block user typing basically), and using full-blown analysis for those would be prohibitively slow. But you actually do need at least the full parse tree to drive many such feature (cursor placement with correct indentation, adding new lines, extend selection). But solving incremental parsing is significantly harder than solving incremental brace matching, and it requires a significant chunk of per-language knowledge to be duplicated between the server and the client.

    1. 13

      This article is especially interesting to me, as it shows how VS Code still doesn’t have the “Emacs nature”. Even though I’m a 30-year Emacs user, I do hesitate to recommend it to younger programmers because it’s so alien, and VS Code has one of the essential characteristics of Emacs: the extension language and the implementation language are the same. But this article is a great example of how it doesn’t — extensions are limited to using an extension API, rather than having full access to the application’s internals. Maybe a good thing, if you’re a mass-market product worried about malicious extensions. But I’ll note that rainbow-delimiters-mode dates back to 2010, and has never noticeably slowed down loading or display of source files, even in languages with lots of delimiters like Lisp.

      1. 8

        Maybe a good thing, if you’re a mass-market product worried about malicious extensions.

        It may be partly about malicious extensions, but there are also potential performance wins to having extensions in a separate process (as noted in this post and also seen in Sublime Text). Maybe “performance win” is the wrong phrase here: It’s more about consistency of performance: a poorly written extension is not going to slow the core editor experience. I’ve worked on a couple of editors in the past, and it is a real concern that people will complain “your editor is slow and crappy” when the real issue is the extensions in use. There’s also a certain compatibility benefit to having a limited, supported API for extensions vs extensions just being able to reach in and change anything.

        This is not to say the VS Code/Sublime Text way is better than Emacs, to be clear. Just that there are more tradeoffs. Emacs has clearly been super successful with the tradeoffs it made, but it’s possible that the different audience has different expectations.

        1. 1

          Can you verify on checker.ts, please?

          1. 2

            I just tried it and while it is not 100% instant, it takes less than a tenth of a second and I don’t see a noticable spike in cpu usage when editing the file with the rainbow delimiters mode enabled.

            1. 1

              Is it accurate? Comments/strings excluded?

              1. 2

                Yes, it’s accurate and excludes comments and strings; I just tested this. On my machine (i5-3360M circa 2012, 8GB RAM, Fedora Linux, Emacs 28 with native compilation), I could not notice any slowdown loading the file, or editing near the top of the document. Near the bottom of the document, I do see a little slowdown when inserting or deleting delimiters, but I would also say it’s around 100ms. Even at the bottom of the document, scrolling or jumping around isn’t slowed down at all.

            2. 1

              Will do when I’m on a better connection.

          2. 3

            Nice. Only downside now is the bright colours make my editor look like angry fruit salad. Maybe with a really restrained colour palette.

            1. 1

              Yet they still don’t support the most fundametal feature most people I know miss about it: Multiple windows…