Before this change up and down were in display co-ordinates, after this
change they are in fold coordinates (which matches the vim behaviour).
To make this work without causing usabliity problems, a bunch of extra
keyboard shortcuts now work:
- vim: `z {o,c}` to open,close a fold
- vim: `z f` to fold current visual selection
- vim: `g {j,k,up,down}` to move up/down a display line
- vim: `g {0,^,$,home,end}` to get to start/end of a display line
Fixes: zed-industries/community#1562
This isn't ready to go - I'm opening a PR to ask for some advice. When
activating a python virtual environment, the typical command used is
`source path_to_venv/bin/activate`. The problem is, the activatate
script isn't portable to all shells, so some additional scripts are
bundled in the env, for example, `activate.fish`. We don't have a good
way of knowing what shell we are in, in order to know what script to
run.
Julia gave the alternative of simply activating the virtual environment
while in the zsh context, before the user's custom shell is launched,
which I think does work, but because we activate the virtual environment
before we launch the custom shell, the shell isn't really aware that we
are in the virtual environment and it fails to display the information
in the prompt that is typically shown after activating.
Is there a clean way for us to know for a fact what shell is being ran,
so we know what script to run?
Check out the code comments below for more context.
---
https://github.com/zed-industries/zed/assets/19867440/ddb76aaa-152b-4c93-a513-3cd580b7c40f
I've used Zed to write Python scripts, but working on an actual project
has really magnified where Python dev is falling short. A huge
quality-of-life thing we can do is provide a setting to automaticaly
search for and activate virtual environments when found, when terminals
are created. Manually starting these up in every terminal instance is
such a drag.
A few quirks:
- We don't have a way of knowing if the prompt is ready before we try
run the command, which means we see the text inserted at the top of the
terminal and on the prompt - I dont think this should be a blocker
though.
- If a user has multiple python projects with mutliple virtual
environments, we only detect and activate the first one, since can't
really make any assumptions about which one to activate. I dont think
this should be a blocker either, as I think most users will have a
single project open in Zed.
Release Notes:
- Added a `detect_venv` setting for the terminal. When configured, the
Zed terminal will automatically activate Python virtual environments on
terminal creation.
In visual mode when your selection ends with a newline we show the
cursor at the end of the previous line (not the start of the current
line). We had only been accounting for this if the cursor was on-screen.
This way, only the visible part gets frequently queried on typing (and
hint /refresh requests that follow), with queries for invisible ranges
cancelled eagerly.
Often, hint ranges are separated by a single '<` char as in
`Option<Vec<u32>>`. When moving the caret from left to right, avoid
inclusive ranges to faster update the matching hint underline.
Without holding all hints in host's cache, this is impossile.
Currenly, we keep hint caches separate and isolated, so this will not
work when we actually resolve.
Optimization to the Semantic Indexing Engine.
We've transitioned from a framework in which the entire project tree is
walked at each index command, to an eager queuing method, in which an
initial queue of outstanding indexing work is initialized upon workspace
creation, and then subscriptions are leveraged for file change events to
continually keep an updated view on outstanding work.
This optimization contributes towards quicker user feedback, when
initializing or using Semantic Search functionality. It also opens the
doors towards better transparency across the system on outstanding
indexing work.
Release Notes:
- Refactored index operation queue to an eager queuing framework.
- Moved semantic search initialization to workspace creation.
- Adjusted rate limiting strategy on api delays to reduce time spent
waiting for rate limits.
### Todo
* [x] Snapshot channel buffers when everyone closes the buffer
* [x] Ensure that users who are in both a project and a channel note
have the same color in both places
* [x] Allow following project collaborators into channel notes
* [x] Expose notes for the current channel under "Current Call" section
of the collaboration panel
* [x] Offline state for the channel notes view
* [x] Make the channel context menu accessible to all members (to expose
the notes)
* [x] Wire in view and Item method overrides
Release Notes:
- N/A
Since the resizing rework on docks, I noticed a lot of cursor flickering
when dragging, that drags trigger hover states in underlying elements
instead of being ignored, and that clicking and dragging off a button
can leave that button's click style active. This PR fixes all three
bugs.
Release Notes:
- Fixed several styling bugs related to dragging the mouse cursor
This is a follow-up to a recent patch I've submitted to this crate to
improve compile time and runtime (in older versions file lookup was
essentially O(n) with respect to path count, now it's O(log n))
Release Notes:
- N/A
This is a deep cut. There's still more work to do until we start
building UI with this. I've approached this as additively as possible,
but I've made a few changes to the rest of the code that I think would
be good to upstream before proceeding too much further.
Most of the interesting pieces are in gpui/playground, which is a
standalone binary that opens a single window and renders a new kind of
element. The layout of these new elements is provided by the taffy
layout engine crate, which conforms to web conventions. The idea is that
playground is relatively cheap to build and work on. As concepts
coalesce in playground, we can drop them into gpui and start
transitioning.
- vim: support P for paste before
- vim: support P in visual mode for paste without overriding clipboard
- vim: fix position when using `p` on text copied outside zed
- vim: fix indentation when using `p` on text copied from zed
This PR adds new config option to language config called
`word_boundaries` that controls which characters should be recognised as
word boundary for a given language. This will improve our UX for
languages such as PHP and Tailwind.
Release Notes:
- Improved completions for PHP
[#1820](https://github.com/zed-industries/community/issues/1820)
---------
Co-authored-by: Julia Risley <julia@zed.dev>
This PR adds new config option to language config called
`word_boundaries` that controls which characters should be recognised as
word boundary for a given language. This will improve our UX for
languages such as PHP and Tailwind.
Release Notes:
- Improved completions for PHP
[#1820](https://github.com/zed-industries/community/issues/1820)
---------
Co-authored-by: Julia Risley <julia@zed.dev>
[This PR has been sitting around for a
bit](https://github.com/zed-industries/zed/pull/2845). I received a bit
of mixed opinions from the team on how this setting should work, if it
should use the full model names or some simpler form of it, etc. I went
ahead and made the decision to do the following:
- Use the full model names in settings - ex: `gpt-4-0613`
- Default to `gpt-4-0613` when no setting is present
- Save the full model names in the conversation history files (this is
how it was prior) - ex: `gpt-4-0613`
- Display the shortened model names in the assistant - ex: `gpt-4`
- Not worry about adding an option to add custom models (can add in a
follow-up PR)
- Not query what models are available to the user via their api key (can
add in a follow-up PR)
Release Notes:
- Added a `default_open_ai_model` setting for the assistant (defaults to
`gpt-4-0613`).
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
