krig (@[email protected])

One question that has been on my mind since I forked Zed is why it's such a huge project. It's a text editor. What does all that code really do? I still don't know if I understand why. I have looked at a fraction of the code at this point. What does it all do? Fuck if I know. But here, take a look at this for example... Python support in Gram (forked from Zed) is mainly provided by python.rs, a single file containing 2865 lines of code (as of today). One part of that code is a function which lists virtual environments available to the editor. The code to actually discover which venvs are available is handled by a dependency (the PET library from Microsoft) but sorting the venvs in order of importance is handled here: https://codeberg.org/GramEditor/gram/src/commit/b0f5dd51829e2b63bd6ca2d4b39a8313c55522ae/crates/languages/src/python.rs#L1184 It's a single call to the method sort_by on a variable confusingly named toolchains, containing a list of virtual environments. I have been trying to make sense of it for a while. Like, one sort criteria is filesystem distance, which kind of makes sense. Wouldn't it make sense to primarily sort by filesystem distance, and a second sort by Python version? Instead this is primarily sorting alphabetically by executable name, it's looking at multiple environment variables for priority, it's sorting alphabetically based on conda prefix(?)... Maybe I'm missing something, maybe I am not galaxy-brained enough to sort virtual environments with the big fellas. But I then compare this to helix which has no special handling for virtual environments, you just configure the LSP to use the venv you want to use, and I feel like maybe it didn't have to be this complicated?