If you highlight the following block of text (with a single selection):
```
The quick brown
fox jumps over
the lazy dog
```
and run `editor: convert to upper camel case`, you'll get:
```
TheQuickBrown
foxJumpsOver
theLazyDog
```
instead of:
```
TheQuickBrown
FoxJumpsOver
TheLazyDog
```
The same thing happens for `editor: convert to title case`. This happens
because [`to_case` crate](https://crates.io/crates/convert_case) doesn't
allow the user to define '\n' as a boundary. I wanted to fix this at the
lib level, so I filled [an
issue](https://github.com/rutrum/convert-case/issues/16) but I never
heard back. What's strange is VS Code and Sublime I think both exhibit
the same output as we do currently, but I don't personally think this
feels right (happy to hear opposing opinions). I'm just doing the naive
thing to hack around this limitation of the `to_case` crate.
I did some testing and it seems I only need to adjust `editor: convert
to title case` and `editor: convert to upper camel case`. The way the
other transformations are implemented in `to_case` don't seem to have
this issue.
Release Notes:
- Fixed a bug where running certain text transfomration commands on a
single selection covering multiple lines would not transform all
selected lines as expected.
Transition generate prompt for inline assist to leverage outline as
opposed to full file.
This enables, us to leverage the inline assist for large files.
Release Notes:
- Change inline assist to use tree-sitter based outlines for code
generation instead of full files
This PR adds a `Sized` bound to the `StyleHelpers` trait.
All of the individual methods on this trait already had a `Self: Sized`
bound, so moving it up to the trait level will make it so we don't have
to repeat ourselves so much.
There's an open question of whether we can hoist the `Sized` bound to
`Styleable`, but it's possible there are cases where we'd want to have a
`Styleable` trait object.
Release Notes:
- N/A
There were times when events with bad data were being emitted. What we
found was that places where certain collaboration-related code could
fail, like sending an invite, would still send events; those events
would be in a bad state, as certain elements, such as a room, weren't
constructed as expected, causing the event to have missing data. The new
API guarantees that we have data in the correct configuration. In the
future, we will add events for certain types of failures within Zed, to
cover things like invites failing.
Release Notes:
- N/A
There were time when events with bad data were being emitted. What we found was that places where certain collaboration-related code could fail, like sending an, would still send events, and those events be in a bad state, as certain elements weren't constructed as expected, thus missing in the event. The new API guarantees that we have data in the correct configuration. In the future, we will add events for certain types of failures within Zed.
Co-Authored-By: Julia <30666851+ForLoveOfCats@users.noreply.github.com>
Max Brunsfeld