Before this change a diagnostic message with a trailing newline (e.g.
`line1\nline2\n`) would be rendered in a `Block` with `line_height: 2`.
But the content we then display in this block had 3 "lines", which
pushed the content out of the block.
This fixes the issue by trimming the newlines at the end from the
diagnostics.
Co-authored-by: Antonio <antonio@zed.dev>
This PR updates the tenses used by the summary line of doc comments to
match the [Rust API documentation
conventions](https://rust-lang.github.io/rfcs/1574-more-api-documentation-conventions.html#summary-sentence).
Specifically:
> The summary line should be written in third person singular present
indicative form. Basically, this means write ‘Returns’ instead of
‘Return’.
I'm sure there are plenty occurrences that I missed.
Release Notes:
- N/A
* gitignored entries are never auto revealed
* `project_panel::auto_reveal_entries = true` settings entry was added,
setting it to `false` will disable the auto reveal
* `pane::RevealInProjectPanel` action was added that activates the project panel and reveals the entry it got triggered on (including the gitignored ones)
The diagnostics are collected and available still, since that might become a settings/UI toggle later.
Also, buffer diagnostics are still updated for gitignored files.
Partially fixeszed-industries/community#575
This PR will see one more fix to the case I've spotted while working on
this: namely, if a project has several nested repositories, e.g for a
structure:
/a
/a/.git/
/a/.gitignore
/a/b/
/a/b/.git/
/a/b/.gitignore
/b/ should not account for a's .gitignore at all - which is sort of
similar to the fix in commit #c416fbb, but for the paths in the project.
The release note is kinda bad, I'll try to reword it too.
- [ ] Improve release note.
- [x] Address the same bug for project files.
Release Notes:
- Fixed .gitignore files beyond the first .git directory being respected
by the worktree (zed-industries/community#575).
Release Notes:
- Added documentation display for autocomplete items.
- Fixed autocomplete filtering blocking the Zed UI, causing hitches and
input delays with large completion lists.
- Fixed hover popup link not firing if the mouse moved a slight amount
while clicking.
- Added support for absolute path file links in hover popup and
autocomplete docs.
Release Notes:
- show host in the titlebar of shared projects
- clicking on faces in the titlebar will now always follow the person
(it used to toggle)
- clicking on someone in the channel panel will follow that person
- highlight the currently open project in the channel panel
- fixes a bug where sometimes following between workspaces would not
work
This PR mainlines the current state of new GPUI2-based UI from the
`gpui2-ui` branch.
Release Notes:
- N/A
---------
Co-authored-by: Nate Butler <iamnbutler@gmail.com>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Nate <nate@zed.dev>
This is a PR I built for a friend of a friend at StrangeLoop, who is
making a much better LSP for elixir that elixir folks want to experiment
with. This PR also improves the our debug log viewer to handle LSP
restarts.
TODO:
- [ ] Make sure NextLS binary loading works.
Release Notes:
- Added support for the experimental Next LS for Elxir, to enable it add
the following field to your settings to enable:
```json
"elixir": {
"next": "on"
}
```
Targeting Preview of 09.27.
This is still pending several touchups/clearups:
- We should watch multibuffer for changes and rescan the excerpts. This
should also update match count.
- Closing editor while multibuffer with 100's of changed files is open
leads to us prompting for save once per each file in the multibuffer.
One could in theory save in multibuffer before closing it (thus avoiding
unnecessary prompts), but it'd be cool to be able to "Save all"/"Discard
All".
Release Notes:
- Added "Replace in project" functionality
Copilot is being used in every buffer, but we do not see its logs that
easily.
In the future, prettier wrapper will pretend to be an LSP server, it is
better to log its messages somewhere, so prepare an infrastructure for
that.
<img width="1727" alt="image"
src="https://github.com/zed-industries/zed/assets/2690773/d31a257c-9608-46fa-8be1-f0a2a2bdbdb7">
Copilot seem to have no rpc messages logged for some reason now,
prettier wrapper might be a better case to investigate this, so leaving
as is.
Release Notes:
- N/A
This is still WIP, mostly pending styling. I added a pretty rudimentary
text field and no buttons whatsoever other than that. I am targeting a
Preview of 09.13, as I am gonna be on PTO for the next week.
I dislike the current implementation slightly because of `regex`'s crate
syntax and lack of support of backreferences. What strikes me as odd wrt
to syntax is that it will just replace a capture name with empty string
if that capture is missing from the regex. While this is perfectly fine
behaviour for conditionally-matched capture groups (e.g. `(foo)?`), I
think it should still error out if there's no group with a given name
(conditional or not).
Release Notes:
- Added "Replace" functionality to buffer search.
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
Deals with https://github.com/zed-industries/community/issues/752
Deals with https://github.com/zed-industries/community/issues/566
Currently, when converting from LSP to Zed objects, completions with
non-empty `additional_text_edits` are filtered out.
Later, all other completions form a list and the selected one gets the
`Editor::confirm_completion` call, which always queries an LSP
completion resolve request to get the `additional_text_edits` field.
Otherwise, `additional_text_edits` field is ignored entirely for the
rest of the completion lifetime — and we always pass the selected
completion through the resolve request.
The PR changes the logic, removing the `additional_text_edits` filtering
and instead of resolving every completion, now we check for
`additional_text_edits` in the completion before resolving: resolve
happens only if the data is absent.
Generally, feels like resolve has to happen before the completion
selection: LSP servers may send us markdown for completion documentation
preview pop ups and similar extra info.
Also, the server may lack resolve capabilities entirely, always sending
the request seems dangerous.
For now, the PR does not attempt to change either.
Release Notes:
- Brings rust-analyzer's postfix completions and others completions with
preresolved additional text edits
Instead of storing `initialization_options` in every LSP adapter as
before, store previous LSP settings in `Project` entirely.
This way, we can later have use multiple different project
configurations per single LSP with its associated adapter.
co-authored-by: Max Brunsfeld <max@zed.dev>
Language servers mixed `initialization_options` from hardcodes and user
settings, fix that to ensure we restart servers on their settings
changes only.
Language servers such as typescript-language-servers report a single
work event, ending right after server's startup.
Other servers might send more similar event, also during startup.
The rest of the events are diagnostic-related and we filter them out.
React on such events with /refresh-like hint update, that will check
only the visible part of the editor for hints and might be replaced by
other /refresh requests, if needed.
As part of an optimization in
https://github.com/zed-industries/zed/pull/2663, I changed the way that
the worktree ignores FS events within unloaded directories. But this
accidentally prevented us from detecting some events that occur inside
of `.git` directories.
In this PR, I've made further tweaks to which FS events we can ignore.
We now explicitly opt *in* to scanning `.git` (shallowly) directories
(even though they are ignored). Note that we still don't recursively
scan the git directory (including all of the files inside `objects`
etc). This seems like the correct amount of work to do, and from my
testing (and our unit tests that use the real FS and real git
repositories), it seems to work correctly.
Release Notes:
- Fixed a bug where Zed would not detect some git repository changes
(preview only).
These adapters have indicated some broader reason to the user why
they cannot be started, don't waste time/bandwidth attempting to
validate and reinstall them
Don't wait until populating that directory entry, for two reasons:
* In the case of submodules, .git is not a directory
* We don't eagerly populate .git directories, since their contents
are automatically ignored.
