Fixes
https://linear.app/zed-industries/issue/Z-2208/outline-view-doesnt-differentiate-between-overloaded-functions
Fixes
https://linear.app/zed-industries/issue/Z-2205/elixir-syntax-highlighting-not-working-properly-for-doc-attributes-and
This PR improves syntax highlighting and outline view in Elixir. It's
common to overload elixir functions, with many different versions of the
function for different patterns of parameters, so I updated the outline
view to show functions' parameters in Elixir. But if we showed functions
the same way in the *breadcrumbs*, it would take up too much space.
So I added a new capture in languages' `outline` queries called
`@context.extra`, which is included in the outline view, but not in
breadcrumbs.
Release Notes:
- Improved syntax highlighting of doc attributes and special macros in
Elixir
- Updated the outline view in Elixir to display function parameters, to
allow differentiating between function overloads.
This PR adds live reloading of Tree-sitter queries when running in debug
mode, similar to what we do for the themes. This way, you can change a
highlighting query or an outline query, and immediately see the result
in the app.
Release Notes:
- N/A
Per conversation with Antonio, I've suggested enabling full LTO; right
now we use a crate-local ThinLTO, which does not inline function calls
across crates.
| Configuration | Current main (788f97e) | Thin LTO | Full LTO |
|------------------|------------------------|-----------|-----------|
| Size in bytes | 158806721 | 155868753 | 111115553 |
| % of `main` size | 100% | 98.14% | 69.96% |
| Size in bytes (no debug info) | 129186657 | 127942929 | 108281345 |
Previously, all static assets were embedded into Zed using a single
`RustEmbed` struct called `Assets`, which was in a crate of its own,
also called `assets`. Many crates depended on this crate. The problem
with this situation was that changing *any* static asset file caused
almost every crate in the codebase to need recompilation (because of
recursive dependencies on `assets`).
Now, most of the assets are embedded only into the top-level `zed`
crate. A few assets (such as settings JSON files and AI prompts) are
needed in lower-level crates such as `settings` and `ai`. For these,
I've created separate `RustEmbed` structs in those specific crates,
which embed those specific sub-folders of `assets`.
The result is that now, when you change a theme file, the only crate
that needs to recompile is `zed`.
Release Notes:
- N/A
Previously, project-specific settings were not discoverable. This PR
adds a `Zed > Preferences > Local Settings` application menu command
that creates a `.zed/settings.json` at the root of your current
worktree. This command works in both local and remote projects.
Limitations:
* Currently, if you have an empty project open, the command just shows a
notification that there are no folders open.
* The JSON-schema-based autocomplete is the same in local settings files
as in your main settings, even though not all settings can be locally
customized.
Release Notes:
- Added an application menu command - `Zed > Preferences > Local
Settings` for creating a folder-specific settings file.
Following https://github.com/zed-industries/zed/pull/2559 the project
panel entries become pretty wide again. This PR tries to mitigate that
and just make some general improvements to visual density in the project
panel.
- Reduces padding around items
- Removes top margin
- Slightly reduces the height of each item
- Fixes an issue where ignored files had the wrong color chevron
Release Notes:
- Improved density of the project panel and tidied up some visual
issues.
Problem is, I'm trying to trust the excerpt id of the selection head,
but it's a sentinel value and not the actual excerpt id of the message.
I think we probably need to resolve to offsets instead.
The `start-local-collaboration` script opens two instances of Zed, each
logged in as a different user, and each one taking up half of the
screen. But previously, when joining a remote project as one of the
collaborators, that newly-opened window would be full screen.
Now, each instance of Zed keeps *all* of its windows on its half of the
screen. This is implemented by respecting the `ZED_WINDOW_{SIZE,BOUNDS}`
env vars, even when joining *remote* projects.
Release Notes:
- N/A
Antonio Scandurra
Joseph Lyons
Max Brunsfeld
Piotr Osiewicz
Nate Butler
Mikayla Makiandmax