Python Syntax highlighting is broken

zed-industries / zed

Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.

https://zed.dev

Other

49.5k stars 3.02k forks source link

Python Syntax highlighting is broken #14892

Open pantheraleo-7 opened 3 months ago

pantheraleo-7 commented 3 months ago

Check for existing issues

[X] Completed

Describe the bug / provide steps to reproduce it

I haven't checked for other languages hence the title, but I suspect it's a problem with themes as a whole.

First of all, there's zero documentation that I could find explaining what each style does or even how many there are. The schema is not helpful at all and there's nothing at the website. It should be a priority to provide a proper documentation.

Some styles don't apply at all like many string ones, punctuation ones, comment.doc (docstring?), terminal.foreground, etc., and when they do they apply to things they shouldn't (see below screenshots)

Related issue: #9461

Alas, see the attached screenshots where I've explained few issues with comments

Environment

Zed: v0.144.4 (Zed) OS: macOS 14.5.0 Memory: 8 GiB Architecture: aarch64

If applicable, add mockups / screenshots to help explain present your vision of the feature

Punctuations are broken. Objects are highlighted as per their case and not their actual type, etc.

If applicable, attach your Zed.log file to this issue.

Zed.log

tslaton commented 2 months ago

I noticed the following Python syntax issues as well:

in scoped as operator rather than keyword (debatable, but it looks odd when writing for... in and is inconsistent with eg., VS Code)
given @classmethod, just @ is scoped as a function instead scoping all of @classmethod
imports are scoped as types instead of variables
- I think this last one actually applies to multiple languages, if not all (observed with javascript/typescript, too)

pantheraleo-7 commented 2 months ago

I think the issue is that syntax highlighting is not based on types inferred by the LSP, and is just case-based. In the completion menu (provided by PyRight), objects are highlighted correctly, but in the buffer they are not.

in scoped as operator rather than keyword (debatable, but it looks odd when writing for... in and is inconsistent with eg., VS Code)

I noticed it as well, but technically in is an operator in Python. And I actually prefer it this way.

pantheraleo-7 commented 2 months ago

imports are scoped as types instead of variables

while they are variables, they should be highlighted differently than variables.

given @classmethod, just @ is scoped as a function instead scoping all of @classmethod

I guess this is subjective since in @something, something isn't necessarily a function. For ex., classmethod is implemented as a class.

rainx0r commented 1 month ago

Adding some more problems I've noticed:

All caps class names are highlighted as constant, when they should just be highlighted as type. This is a problem even if the programmer follows pythonic naming conventions because for example this standard library's abc.ABC is highlighted wrong this way.
Future imports aren't styled for some reason, perhaps fixed by:

17984?
Imported modules are highlighted as variable (refer to the first screenshot where abc is highlighted as a variable. It's been imported with import abc at the top of the file). This isn't necessarily wrong but other editors and syntax highlighting systems allow you to style imported modules to differentiate them from other variables, and this is very useful when following Google's Python Style Guide.
Built in collection types are highlighted as variable when used in type hints. In this screenshot list and tuple should be highlighted as some subscope of type probably (type.builtin ?):