In some situations outside JSX elements Tailwind will never
respond to a completion request, holding up the tsserver completions.
Only submit the request to Tailwind when we wouldn't get tsserver
completions anyway and don't submit to Tailwind when we know we won't
get Tailwind completions
Co-Authored-By: Kirill Bulatov <kirill@zed.dev>
See Linear description for the full explanation of the issue. This PR is
mostly a mechanical change, except for the one case where we do pass in
an explicit `next_id` instead of `model_id` in project.rs.
Release Notes:
- Fixed a bug where some results were not reported in project search in
presence of unnamed buffers.
This is the first batch of improvements to current project search. There
are few things we can do better still, but I want to get this out in
next Preview.
Most of the slowness at this point seems to stem from updating UI too
often.
Release Notes:
- Improved project search by making it report results sooner.
---------
Co-authored-by: Julia Risley <julia@zed.dev>
Use word_characters to feed completion trigger characters as well and
also recognize kebab as a potential sub-word splitter. This is fine for
non-kebab-case languages because we'd only ever attempt to split a word
with a kebab in it in language scopes which are kebab-cased
Co-Authored-By: Max Brunsfeld <max@zed.dev>
This isn't ready to go - I'm opening a PR to ask for some advice. When
activating a python virtual environment, the typical command used is
`source path_to_venv/bin/activate`. The problem is, the activatate
script isn't portable to all shells, so some additional scripts are
bundled in the env, for example, `activate.fish`. We don't have a good
way of knowing what shell we are in, in order to know what script to
run.
Julia gave the alternative of simply activating the virtual environment
while in the zsh context, before the user's custom shell is launched,
which I think does work, but because we activate the virtual environment
before we launch the custom shell, the shell isn't really aware that we
are in the virtual environment and it fails to display the information
in the prompt that is typically shown after activating.
Is there a clean way for us to know for a fact what shell is being ran,
so we know what script to run?
Check out the code comments below for more context.
---
https://github.com/zed-industries/zed/assets/19867440/ddb76aaa-152b-4c93-a513-3cd580b7c40f
I've used Zed to write Python scripts, but working on an actual project
has really magnified where Python dev is falling short. A huge
quality-of-life thing we can do is provide a setting to automaticaly
search for and activate virtual environments when found, when terminals
are created. Manually starting these up in every terminal instance is
such a drag.
A few quirks:
- We don't have a way of knowing if the prompt is ready before we try
run the command, which means we see the text inserted at the top of the
terminal and on the prompt - I dont think this should be a blocker
though.
- If a user has multiple python projects with mutliple virtual
environments, we only detect and activate the first one, since can't
really make any assumptions about which one to activate. I dont think
this should be a blocker either, as I think most users will have a
single project open in Zed.
Release Notes:
- Added a `detect_venv` setting for the terminal. When configured, the
Zed terminal will automatically activate Python virtual environments on
terminal creation.
Without holding all hints in host's cache, this is impossile.
Currenly, we keep hint caches separate and isolated, so this will not
work when we actually resolve.
This PR adds new config option to language config called
`word_boundaries` that controls which characters should be recognised as
word boundary for a given language. This will improve our UX for
languages such as PHP and Tailwind.
Release Notes:
- Improved completions for PHP
[#1820](https://github.com/zed-industries/community/issues/1820)
---------
Co-authored-by: Julia Risley <julia@zed.dev>
This PR adds new config option to language config called
`word_boundaries` that controls which characters should be recognised as
word boundary for a given language. This will improve our UX for
languages such as PHP and Tailwind.
Release Notes:
- Improved completions for PHP
[#1820](https://github.com/zed-industries/community/issues/1820)
---------
Co-authored-by: Julia Risley <julia@zed.dev>
Tailwind likes to throw a lot of completion data at us, this gets it to
send less. Previously it would respond to a completion with 2.5 MB JSON
blob, now it is more like 0.8 MB.
Relies on a local copy of lsp-types with the `itemDefaults` field added.
I don't have write perms to push to our fork of the crate atm, sorry :)
Follow-up to https://github.com/zed-industries/zed/pull/2777
Refs https://github.com/zed-industries/community/issues/1770
In this PR, I reworked the way that git statuses are retrieved. In a
huge repository like `WebKit`, the really slow part of computing a list
of git statuses is the *unstaged* portion of the diff. For the *staged*
diff, `git` can avoid comparing the contents of unchanged directories,
because the index contains hashes of every tree. But for the *unstaged*
portion, Git needs to compare every file in the worktree against the
index. In the common case, when there are no changes, it's enough to
check the `mtime` of every file (because the index stores the mtimes of
files when they are added). But this still requires an `lstat` call to
retrieve each file's metadata.
I realized that this is redundant work, because the worktree is
*already* calling `lstat` on every file, and caching their metadata. So
in this PR, I've changed the `Repository` API so that there are separate
methods for retrieving a file's *staged* and *unstaged* statuses. The
*staged* statuses are retrieved in one giant batch, like before, to
reduce our git calls (which also have an inherent cost). But the
`unstaged` statuses are retrieved one-by-one, after we load files'
mtimes. Often, all that's required is an index lookup, and an mtime
comparison.
With this optimization, it once again becomes pretty responsive to open
`WebKit` or `chromium` in Zed.
Release Notes:
- Optimized the loading of project file when working in very large git
repositories
Kirill Bulatov
Julia
Piotr Osiewicz
Joseph T. Lyons
KCaverlyandPiotr
Nathan Sobo