Commit graph

7 commits

Author SHA1 Message Date
Piotr Osiewicz
08b3c03241
project: Allow running multiple instances of a single language server within a single worktree (#23473)
This PR introduces a new entity called Project Tree which is responsible
for finding subprojects within a worktree;
a subproject is a language-specific subset of a worktree which should be
accurately tracked on the language server side. We'll have an ability to
set multiple disjoint workspaceFolders on language server side OR spawn
multiple instances of a single language server (which will be the case
with e.g. Python language servers, as they need to interact with
multiple disjoint virtual environments).
Project Tree assumes that projects of the same LspAdapter kind cannot
overlap. Additionally project nesting is not allowed within the scope of
a single LspAdapter.

Closes https://github.com/zed-industries/zed/issues/5108
Re-lands #22182 which I had to revert due to merging it into todays
Preview.

Release Notes:

- Language servers now track their working directory more accurately.

---------

Co-authored-by: João <joao@zed.dev>
2025-01-22 21:19:02 +01:00
Piotr Osiewicz
da406ae07e
Revert "project: Allow running multiple instances of a single language server within a single worktree" (#23472)
Reverts zed-industries/zed#22182
I've merged the build too soon as I wanted it to be excluded from todays
Preview.
2025-01-22 11:42:50 -05:00
Piotr Osiewicz
bed917b0b1
project: Allow running multiple instances of a single language server within a single worktree (#22182)
This PR introduces a new entity called Project Tree which is responsible
for finding subprojects within a worktree;
a subproject is a language-specific subset of a worktree which should be
accurately tracked on the language server side. We'll have an ability to
set multiple disjoint `workspaceFolder`s on language server side OR
spawn multiple instances of a single language server (which will be the
case with e.g. Python language servers, as they need to interact with
multiple disjoint virtual environments).
Project Tree assumes that projects of the same LspAdapter kind cannot
overlap. Additionally **project nesting** is not allowed within the
scope of a single LspAdapter.

Closes #5108

Release Notes:

- Language servers now track their working directory more accurately.

---------

Co-authored-by: João <joao@zed.dev>
2025-01-22 17:31:14 +01:00
Piotr Osiewicz
c9534e8025
chore: Use workspace fields for edition and publish (#23291)
This prepares us for an upcoming bump to Rust 2024 edition.

Release Notes:

- N/A
2025-01-17 17:39:22 +01:00
Nate Butler
6152230152
Fix DynamicSpacing docs (#20509)
In #20504 the CustomSpacing enum variants ended up not having docs. This
PR fixes that, now docs correctly show for variants.


https://github.com/user-attachments/assets/8cc409c9-7b71-4c21-a538-3fd5dded3e00

Release Notes:

- N/A
2024-11-11 12:58:39 -05:00
Nate Butler
94d8ead270
Refactor Spacing into DynamicSpacing using proc macro (#20504)
Density tracking issue: #18078 

This PR refactors our spacing system to use a more flexible and
maintainable approach. We've replaced the static `Spacing` enum with a
dynamically generated `DynamicSpacing` enum using a proc macro.

Enum variants now use a `BaseXX` format, where XX = the pixel value @
default rem size and the default UI density.

For example:

`CustomSpacing::Base16` would return 16px at the default UI scale &
density.

I'd love to find another name other than `Base` that is clear (to avoid
base_10, etc confusion), let me know if you have any ideas!

Changes:

- Introduced a new `derive_dynamic_spacing` proc macro to generate the
`DynamicSpacing` enum
- Updated all usages of `Spacing` to use the new `DynamicSpacing`
- Removed the `custom_spacing` function, mapping previous usages to
appropriate `DynamicSpacing` variants
- Improved documentation and type safety for spacing values

New usage example:

```rust
.child(
    div()
        .flex()
        .flex_none()
        .m(DynamicSpacing::Base04.px(cx))
        .size(DynamicSpacing::Base16.rems(cx))
        .children(icon),
)
```

vs old usage example:

```
.child(
    div()
        .flex()
        .flex_none()
        .m(Spacing::Small.px(cx))
        .size(custom_spacing(px(16.)))
        .children(icon),
)
```

Release Notes:

- N/A
2024-11-11 11:08:55 -05:00
Nate Butler
fac9ee5f86
Add ui_macros crate & DerivePathStr derive macro (#17811)
This PR adds the `ui_macros` crate to allow building supporting macros
for the `ui` crate.

Additionally, it implements the `DerivePathStr` derive macro and the
`path_str` attribute macro. These macros work together to generate a
`path` method for enum variants, which is useful for creating
standardized string representations of enum variants.

The `DerivePathStr` macro provides the following functionality:
- Generates a `path` method for each enum variant.
- Allows specifying a prefix (required) and suffix (optional) for all
paths.
- Supports `strum` attributes for case conversion (e.g., snake_case,
lowercase).

Usage example:

```rust
#[derive(DerivePathStr)]
#[path_str(prefix = "my_prefix", suffix = ".txt")]
#[strum(serialize_all = "snake_case")]
enum MyEnum {
    VariantOne,
    VariantTwo,
}

// Generated paths:
// MyEnum::VariantOne.path() -> "my_prefix/variant_one.txt"
// MyEnum::VariantTwo.path() -> "my_prefix/variant_two.txt"
```

In a later PR this will be used to automate the creation of icon & image
paths in the `ui` crate.

This gives the following benefits:

1. Ensures standard naming of assets as paths are not manually
specified.
2. Makes adding new enum variants less tedious and error-prone.
3. Quickly catches missing or incorrect paths during compilation.
3. Adds a building block towards being able to lint for unused assets in
the future.

Release Notes:

- N/A
2024-09-13 16:45:16 -04:00