I want to use this on another branch, but it's a sweeping change, so
this prepares the ground for it. This can always be reverted if it
doesn't work out.
With this PR, I've eliminated almost all references to window ids
outside of the internals of GPUI. All public methods taking these ids
are now defined on `AnyWindowHandle`, which provides a more coherent
narrative around windows as a concept.
Instead of returning a usize for the window id, I'm instead returning a
`WindowHandle<V: View>` where `V` is the type of the window's root view.
@as-cii helped me with a cool technique using generic associated types
where methods on `WindowHandle` can return either T or Option<T>
depending on the `BorrowWindowContext::Result` associated type.
Some example usage...
```rs
let window = cx.add_window(|cx| MyView::new(cx));
let my_view = window.root(cx); // If cx is TestAppContext, returns MyView. Otherwise returns Option<MyView>, because the window could be closed.
```
This isn't insanely beneficial on its own, but I think it will help
clean up our testing story. I'm planning on making `window` more useful
in tests for laying out elements, etc.
- [x] Rework tests that call `add_window` 😅 to expect only a window in
return.
- [x] Get tests passing
- [x] 🚬 test
I want to use this on another branch, but it's a sweeping change,
so this prepares the ground for it. This can always be reverted if
it doesn't work out.
After #2641 we noticed that scrolling didn't take a count parameter, and
a few other issues with the way that we calculated the distance to
scroll.
Release Notes:
- Improved distance calculations for page-up/page-down
- vim: Allow counts to work with scrolling shortcuts.
Fixes: zed-industries/community#1690
I'm not sure this is the correct way to fix this...
* A simpler approach would be to just say `!showing_code_actions` in the
binding file (as `showing_completions` can only happen in insert mode -
and `VimControl` will be false). This seemed a little error prone if
more menus were added in the future.
* A more complicated approach would be to copy the way this is done from
the MouseContextMenu, which registers its own keyboard shortcuts, and as
such uses those when it's open. This seems "more correct", but is a
major refactoring for a very small reward.
Release Notes:
- vim: Fix code actions menu
([#1690](https://github.com/zed-industries/community/issues/1690))
To turn any struct into a composite element, you can implement a render
method with the following signature:
```rs
fn render<V: View>(&mut self, view: &mut V, cx: &mut ViewContext<V>) -> AnyElement<V>;
```
Then add #[derive(Element)] to the struct definition.
This will make it easier to introduce higher-level components that are
expressed in terms of other elements. Instead of calling functions that
return elements, we can now make any struct into an element fairly
easily. The advantage is that we can use method chaining to express
optional state on these components, and they blend in better with other
elements.
cc @mikayla-maki @osiewicz @iamnbutler
Release Notes:
- N/A
To turn any struct into a composite element, you can implement a render method
with the following signature:
fn render<V: View>(&mut self, view: &mut V, cx: &mut ViewContext<V>) -> AnyElement<V>;
Then add #[derive(Element)] to the struct definition.
This will make it easier to introduce higher-level components that are expressed in
terms of other elements.
Release Notes:
- In vim mode you can now use count modifiers with arrow keys (`5<down>`
will go down 5 lines).
- In vim mode `ctrl+]` and `ctrl+o` now work to go to definition and
back
🚧 We have a couple more refinements to this to add 🚧
Release Notes:
You can now join lines with `ctrl-j` or `shift-J` in Vim normal mode.
🍐'd with @ConradIrwin
Since we don't want tabs, I think it would be better to render the toolbar
for ourselves directly and handle switching between conversations.
Co-Authored-By: Julia Risley <julia@zed.dev>
Still need to implement loading / listing.
I'd really be rather write operations to a database. Maybe we
should be auto-saving? Integrating with panes? I just did
the simple thing for now.
I'd like to follow up to allow roles to be cycled for the selected range
and support multi-cursors, but this is a start and contains a
refactoring, so going to merge.
Release Notes:
- Added the ability to cycle roles in the assistant with `ctrl-r`
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.
I was having fun, but it was too much. It makes the assistant too
annoying to be useful.
Release Notes:
Use `N/A` in this section if this item should be skipped in the release
notes.
Add release note lines here:
* Dialed back the system prompt on the assistant.
Each message is represented as a multibuffer excerpt to allow for
fluid editing of the conversation transcript.
Co-Authored-By: Antonio Scandurra <antonio@zed.dev>
This adds basic ability to interact with OpenAI inside a buffer.
Release Notes:
* If`OPENAI_API_KEY` is defined in your environment, you can now run the
`ai: assist` command to pass the text of your current buffer to GPT-4.
If you're editing a file with a `.zmd` extension, you can also invoke
the model with `cmd-enter.` (preview-only)
Nathan Sobo
