rainbow-delimiters VS vscode-python

I'm a big fan of rainbow-delimiters, available on Melpa.

rainbow-delimiters ( https://github.com/Fanael/rainbow-delimiters/ ) does this for parenthesis/braces etc but is somewhat bound to the syntax tree of whatever major mode is currently in use, it also scans on a per-character basis, where I'd need to scan for regex.

> Lighting up the active scopes

As you had guessed a little later, there are a few different emacs packages that do this. One of them is "rainbow parentheses" that gives every bracket a different colour (remember that emacs supports lisp, so differentiating between lots of different parentheses is arguably more useful in emacs than any other editor). [0].

Another one is highlight parentheses [1] which highlights all parens that enclose the cursor position, and gives a darker colour to those "further away" from the cursor.

[0] https://github.com/Fanael/rainbow-delimiters

[1] https://sr.ht/~tsdh/highlight-parentheses.el/

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](https://github.com/Fanael/rainbow-delimiters/) 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.

Using highlight-parentheses-mode, which is an additional package, helps. There are also show-paren-mode (build in) and rainbow-delimiters (additional package), whose could help there.

Ah, Chrome and slow spinners.

Python tests were taking ages on VSCode due to an SVG spinner:

https://bugs.chromium.org/p/chromium/issues/detail?id=103626...

https://github.com/microsoft/vscode-python/issues/9216

It seems to be a problem caused by the new version of the Python extension. Here is a GitHub link for you to follow up.

For the python extension, please file your issue here: https://github.com/microsoft/vscode-python/issues

There seems to be a focus on feature velocity, and as the big parts start to stabilize (language server stuff, refactoring, extension framework, general UI/UX expectations), I hope we'll see some more attention paid to the default experience. But changing defaults in an ecosystem where users embrace configurability is tough, see the pythonPath fiasco, so I don't know the way forward. Core dev Brett Cannon seems to support the opinionated path for the VSCode Python experience going forward, so we'll see where that takes us.

I filed a GitHub report, you can always follow up.

Jedi said it had a fix on this post which links to this but isn't that just the Jedi source code showing fixes? The only reference I see in there is " Autocomplete inherited methods when overriding in child class ", but I just want it to autocomplete when typing a method from the parent class on a subclass instance.

If you still want to use python3.3.1 in vscode, you can submit a report on GitHub to consult the official staff.

It works fine on my machine after testing, can you provide your test code and show your personal settings(settings.json)? If you are convinced that this is a problem with python extensions, you can file a report on GitHub.

Does this help? Maybe you are opening the workspace at the wrong folder level?

Actually, it looks like it might be an issue with syntax highlighting ("Intellisense" in MS terminology) in Microsoft VS Code. Here is almost an identical post to mine in their forum.