- Tighten up toolbar
- Reduce intensity of active tools
- Remove divider between project + branch
- Add a styletree for toolbar + move breadcrumb into it
- Some ts theme tidying
[[PR Description]]
Release Notes:
- Improved density and contrast of a number of UI elements.
This PR polishes the search bar UI, making the layout more dense, and
the spacing more consistent with the rest of the app. I've also
re-ordered the toolbar items to reflect some of @iamnbutler's original
search designs. The items related to the search query are on the left,
and the actions that navigate the buffer (next, prev, select all, result
count) are on the right.
This changes vim motions to be relative to fold lines, not display
lines, to match the behaviour of vim.
This is necessary for relative line numbers to make sense (as the most
important thing is you can do `3j` to get th e line that is numbered 3).
Release Notes:
- vim: Fix handling of motions when `soft_wrap` is enabled in zed. Like
in vim `j,k,up,down,$,^,0,home,end` will all now navigate in file
coordinates not display coordinates.
- vim: Add `g {j,k,up,down,$,^,0,home,end}` to navigate in display
coordinates.
- vim: Add `z o` and `z c` to open and close folds.
- vim: Add `z f` in visual mode to fold selection.
Note: this may be a jarring change if you're grown used to the current
behaviour of `j` and `k`. You can make the issue less acute by setting
`"soft_wrap":"none"` in your settings; or you can manually copy the
bindings for `g j` to the binding for `j` (etc.) in your keymap.json to
preserve the existing behaviour.
Lately, I've been finding Rust-analyzer unusably slow when editing large
files (like `editor_tests.rs`, or `integration_tests.rs`). When I
profile the Rust-analyzer process, I see that it sometimes saturates up
to 10 cores processing a queue of code actions requests.
Additionally, sometimes when collaborating on large files like these, we
see long delays in propagating buffer operations. I'm still not sure why
this is happening, but whenever I look at the server logs in Datadog, I
see that there are remote `CodeActions` and `DocumentHighlights`
messages being processed that take upwards of 30 seconds. I think what
may be happening is that many such requests are resolving at once, and
the responses are taking up too much of the host's bandwidth.
I think that both of these problems are caused by us sending way too
many code action and document highlight requests to rust-analyzer. This
PR adds a simple debounce between changing selections and making these
requests.
From my local testing, this debounce makes Rust-analyzer *much* more
responsive when moving the cursor around a large file like
`editor_tests.rs`.
Omit in buffers with one or zero running language servers with the
capability to provide completions
Co-Authored-By: Antonio Scandurra <antonio@zed.dev>
Terminal has to accept `[` and `]` as valid word parts, due to
`[slug].tsx` being a valid file name.
Yet, terminal has to exclude these to match paths in strings like
`[/some/path/[slug].tsx]`.
* Use a single row, instead of centering the search bar within a double-row toolbar.
* Search query controls on the left, navigation on the right
* Semantic is the final mode, for greater stability between buffer and project search.
* Prevent query editor from moving when toggling path filters
Rather than adding primary toolbar item that renders as empty,
don't add an item at all. This prevents spurious spacing from
being added after other primary toolbar items.
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.
Miltibuffer emits edit events even if it only got an excerpt
added/removed/etc.
Separate buffer edits and trigger hint invalidation refresh for them
only, also trigger hint new lines refresh on excerpt addition events.
This PR adds the wiring to both the server and the client for sending
and receiving individual feature flags, as well as a client side API for
convenient access to these feature flags.
Release Notes:
- N/A
This fixes a bug where text moved up and down by one pixel in the buffer
search query editor, while typing.
Release notes:
* Fixed a bug where editors didn't auto-scroll when typing if all
cursors could not fit within the viewport.
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>
* Scroll to the newest cursor if all cursors can't fit in the viewport.
* Refuse to layout an editor less tall than one line height.
Co-authored-by: Nathan <nathan@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>
Before this change up and down were in display co-ordinates, after this
change they are in fold coordinates (which matches the vim behaviour).
To make this work without causing usabliity problems, a bunch of extra
keyboard shortcuts now work:
- vim: `z {o,c}` to open,close a fold
- vim: `z f` to fold current visual selection
- vim: `g {j,k,up,down}` to move up/down a display line
- vim: `g {0,^,$,home,end}` to get to start/end of a display line
Fixes: zed-industries/community#1562
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.
