Closes#18565
I could use some advice on the color palette / theming. A couple
options:
1. The `drop_target_background` color could be used for the border if we
didn't use it for the background of the tab. In VSCode, the background
color of tabs doesn't change as you're dragging, there's just a border
between tabs. My only concern with this option is that the current
`drop_target_background` color is a bit subtle when used for a small
area like a border.
2. Another option could be to add a `drop_target_border` theme color,
but I don't know how much complexity this adds to implementation
(presumably all existing themes would need to be updated?).
Demo:
https://github.com/user-attachments/assets/0b7c04ea-5ec5-4b45-adad-156dfbf552db
Release Notes:
- Highlight where a dragged tab will be dropped between two other tabs
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Fixes#33869
The Animation page in the Component Preview had a few issues.
* The animations only ran once, so you couldn't watch animations below
the fold.
* The offset math was wrong, so some animated elements were rendered
outside of their parent container.
* The "animate in from right" elements were defined with an initial
`.left()` offset, which overrode the animation behavior.
I made fixes to address these issues. In particular, every time you
click the active list item, it renders the preview again (which causes
the animations to run again).
Before:
https://github.com/user-attachments/assets/a1fa2e3f-653c-4b83-a6ed-c55ca9c78ad4
After:
https://github.com/user-attachments/assets/3623bbbc-9047-4443-b7f3-96bd92f582bf
Release Notes:
- N/A
Closes#34111
In Helix mode, the `;` key should collapse the current selection without
moving the cursor. I've added a new action `vim::HelixCollapseSelection`
to support this behavior.
https://github.com/user-attachments/assets/1a40821a-f56f-456e-9d37-532500bef17b
Release Notes:
- Added `;` key binding to collapse the current text selection in Helix
mode
When [`drag_and_drop_selection` is
true](https://zed.dev/docs/configuring-zed#drag-and-drop-selection),
users can make a selection in the buffer and then drag and drop it to a
new location. However, the editor forces users to wait 300ms after mouse
down before dragging. If users try to drag before this delay has
elapsed, they will create a new text selection instead, which can create
the impression that drag and drop does not work.
I made two changes to improve the UX of this feature:
* If users do not want a delay before drag and drop is enabled, they can
set the `drag_and_drop_selection.delay_ms` setting to 0.
* If the user has done a mouse down on a text selection, the cursor
changes to a copy affordance as soon as the configured delay has
elapsed, rather than waiting for them to start dragging. This way they
don't need to guess at when the delay has elapsed.
The default settings for this feature are now:
```
"drag_and_drop_selection": {
"enabled": true,
"delay_ms": 300
}
```
Closes#33915
Before:
https://github.com/user-attachments/assets/7b2f986f-9c67-4b2b-a10e-757c3e9c934b
After:
https://github.com/user-attachments/assets/726d0dbf-e58b-41ad-93d2-1a758640b422
Release Notes:
- Migrate `drag_and_drop_selection` setting to
`drag_and_drop_selection.enabled`.
- Add `drag_and_drop_selection.delay_ms` setting to configure the delay
that must elapse before drag and drop is allowed.
- Show a ready to drag cursor affordance as soon as the delay has
elapsed
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
First time contributor here. 😊
I settled on markdown::MovePageUp and markdown::MovePageDown to match
the names the editor uses for the same functionality.
Closes#30246
Release Notes:
- Support PgUp/PgDown in Markdown previews