This is a follow-up to #22615 and fixes the issue of `alacritty`
resulting in broken shell/CLI apps if `alacritty` is not in the terminfo
database.
Closes #ISSUE
Release Notes:
- Set `TERM` to `xterm-256color` in Zed's built-in terminal
Closes#17991
Release Notes:
- Set the `TERM` environment variable inside the terminal
Currently the terminal inherits the `TERM` variable from the parent
process. However this can cause issues with programs that rely on this
variable to make sure certain features are present. For example not
supporting backspaces making the terminal almost unusable.
Closes#10325
Release Notes:
- Fixed an issue inside the integrated terminal where clicking on URLs
that started with `file://` would sometimes not work when the path
included a line number (e.g. `file:///Users/someuser/lorem.txt:221:22`)
Expands #18715
Release Notes:
- Added arrow keys movement to the built-in terminal's [vi
mode](https://github.com/alacritty/alacritty/blob/master/docs/features.md#vi-mode)
(which is using Alacritty under the hood).
Details
--
A minuscule improvement on #18715 to allow user with alternative
keyboard layouts to use the terminal's vi mode with the arrow keys.
The goal is to be able to hide these lines from a task output:
```sh
⏵ Task `...` finished successfully
⏵ Command: ...
```
---------
Co-authored-by: Peter Tripp <peter@zed.dev>
This PR prevents `[]` from being sanitized into an empty string and thus
becoming a "valid", clickable file link in the integrated terminal.
Whenever you type `[]` into the terminal and hover over it while
pressing `cmd`, an empty popup appears and the cursor indicates that
this is a clickable element. Once you click on the brackets, the
worktree root is selected and focused within the file picker.
<img width="87" alt="grafik"
src="https://github.com/user-attachments/assets/01790323-88be-4373-a1ec-a345bcf2521e">
This is because in #2906 support was added for sanititzing file links
like `[/some/path/[slug].tsx]` to `/some/path/[slug].tsx`. In the case
`[]` where an empty string is returned from the sanitation, the string
is considered a valid file path and thus `[]` becomes a valid and
clickable navigation target.
Given that this an edge-case just for this specific one set of brackets
and otherwise no empty strings are matched from the regexes `URL_REGEX`
and `WORD_REGEX`, it seemed that this was the best place to fix this
bug.
Release Notes:
- `[]` is no longer considered a clickable link in the terminal
Before this change, we would save the working directory *on the client*
of each shell that was running in a terminal.
While it's technically right, it's wrong in all of these cases where
`working_directory` was used:
- in inline assistant
- when resolving file paths in the terminal output
- when serializing the current working dir and deserializing it on
restart
Release Notes:
- Fixed terminals opened on remote hosts failing to deserialize with an
error message after restarting Zed.
- Fixes modal closing when using the remote modal folder
- Fixes a bug with local terminals where they could open in / instead of
~
- Fixes a bug where SSH connections would continue running after their
window is closed
- Hides SSH Terminal process details from Zed UI
- Implement `cmd-o` for remote projects
- Implement LanguageServerPromptRequest for remote LSPs
Release Notes:
- N/A
terminal: Improve default locale handling
* Use `LANG` instead of `LC_ALL` (`LC_ALL` is the highest priority which
will override any other end-user settings; when that isn't set things
fall back to separate `LC_*` variables; and when those aren't set things
fall back to `LANG`). [0]
* Only set `LANG` for our child if necessary (if it already exists in
the parent, then the child will inherit that, no need for us to do
anything)
[0]
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02
Tested cases:
- `unset LANG ; cargo run`: locale inside zed's terminal is set to
`en_US.UTF-8`
- `export LANG=en_GB.UTF-8 ; cargo run`: locale inside zed's terminal is
set to `en_GB.UTF-8`
Release Notes:
- Use the system locale in the terminal instead of forcing `en_US.UTF-8`
[terminal] Consider "main.cs(20,5)" to be a single clickable word
First, adding unit tests for the regexes because I'm not certain how
these regexes are _intended_ to work, and unit tests work nicely as
demonstrations of intended behaviour.
The comment string, and the regex itself, seem to imply that
"main.cs(20,5)" is supposed be a single "word" (for the purposes of
being clicked on)... but the regex doesn't actually work like that. This
PR makes it work :)
(I don't know _why_ "word with an optional `(\d+,\d+)` on the end"
doesn't match the full string, while "word with a required `(\d+,\d+)`
on the end" _does_ match the full string - aren't regexes supposed to
match as much as possible, so it should take the optional extra whenever
the extra exists? Either way, "word with a required (\d+,\d+), or word
by itself" has the correct behaviour, as demonstrated by the unit test)
Release Notes:
- N/A
Closes#7417
Release Notes:
- Added basic support for Alacritty's [vi
mode](https://github.com/alacritty/alacritty/blob/master/docs/features.md#vi-mode)
to the built-in terminal (which is using Alacritty under the hood.) The
vi mode can be activated with `ctrl-shift-space` and then supports some
basic motions to navigate through the terminal's scrollback buffer.
## Details
Leverages existing selection functionality from mouse_drag and the
ViMotion API of alacritty to add basic vi motions in the terminal.
Please note, this is only basic functionality (move, select, and yank to
system clipboard) and not a fully functional vim environment (e.g.
search, configurable keybindings, and paste). I figured this would be an
interim solution to the long term, more fleshed out, solution proposed
by @mrnugget.
Ctrl+Shift+Space to enter Vi mode while in the terminal (Same default
binding in alacritty)
This is a follow-up to #18530 thanks to this comment here:
https://github.com/zed-industries/zed/pull/18530#issuecomment-2382870564
In short: it fixes the `blinking` setting and the `cursor_shape` setting
as it relates to blinking.
Turns out our `blinking` setting was always the wrong value when using
`terminal_controlled` and the terminal _would_ control the blinking.
Example script to test with:
```bash
echo -e "0 normal \x1b[\x30 q"; sleep 2
echo -e "1 blink block \x1b[\x31 q"; sleep 2
echo -e "2 solid block \x1b[\x32 q"; sleep 2
echo -e "3 blink under \x1b[\x33 q"; sleep 2
echo -e "4 solid under \x1b[\x34 q"; sleep 2
echo -e "5 blink vert \x1b[\x35 q"; sleep 2
echo -e "6 solid vert \x1b[\x36 q"; sleep 2
echo -e "0 normal \x1b[\x30 q"; sleep 2
echo -e "color \x1b]12;#00ff00\x1b\\"; sleep 2
echo -e "reset \x1b]112\x1b\\ \x1b[\x30 q"
```
Before the changes in here, this script would set the cursor shape and
the blinking, but the blinking boolean would always be wrong.
This change here makes sure that it works consistently:
- `terminal.cursor_shape` only controls the *default* shape of the
terminal, not the blinking.
- `terminal.blinking = on` means that it's *always* blinking, regardless
of what terminal programs want
- `terminal.blinking = off` means that it's *never* blinking, regardless
of what terminal programs want
- `terminal.blinking = terminal_controlled (default)` means that it's
blinking depending on what terminal programs want. when a terminal
program resets the cursor to default, it sets it back to
`terminal.cursor_shape` if that is set.
Release Notes:
- Fixed the behavior of `{"terminal": {"blinking":
"[on|off|terminal_controlled]"}` to work correctly and to work correctly
when custom `cursor_shape` is set.
- `terminal.cursor_shape` only controls the *default* shape of the
terminal, not the blinking.
- `terminal.blinking = on` means that it's *always* blinking, regardless
of what terminal programs want
- `terminal.blinking = off` means that it's *never* blinking, regardless
of what terminal programs want
- `terminal.blinking = terminal_controlled (default)` means that it's
blinking depending on what terminal programs want. when a terminal
program resets the cursor to default, it sets it back to
`terminal.cursor_shape` if that is set.
Demo:
https://github.com/user-attachments/assets/b3fbeafd-ad58-41c8-9c07-1f03bc31771f
Co-authored-by: Bennet <bennet@zed.dev>
This builds on top of @Yevgen's #15840 and combines it with the settings
names introduced in #17572.
Closes#4731.
Release Notes:
- Added a setting for the terminal's default cursor shape. The setting
is `{"terminal": {"cursor_shape": "block"}}``. Possible values: `block`,
`bar`, `hollow`, `underline`.
Demo:
https://github.com/user-attachments/assets/96ed28c2-c222-436b-80cb-7cd63eeb47dd
This changes the Zed CLI `zed` to pass along the environment to the Zed
project that it opens (if it opens a new one).
In projects, this CLI environment will now take precedence over any
environment that's acquired by running a login shell in a projects
folder.
The result is that `zed my/folder` now always behaves as if one would
run `zed --foreground` without any previous Zed version running.
Closes#7894Closes#16293
Related issues:
- It fixes the issue described in here:
https://github.com/zed-industries/zed/issues/4977#issuecomment-2305272027
Release Notes:
- Improved the Zed CLI `zed` to pass along the environment as it was on
the CLI to the opened Zed project. That environment is then used when
opening new terminals, spawning tasks, or language servers.
Specifically:
- If Zed was started via `zed my-folder`, a terminal spawned with
`workspace: new terminal` will inherit these environment variables that
existed on the CLI
- Specific language servers that allow looking up the language server
binary in the environments `$PATH` (such as `gopls`, `zls`,
`rust-analyzer` if configured, ...) will look up the language server
binary in the CLI environment too and use that environment when starting
the process.
- Language servers that are _not_ found in the CLI environment (or
configured to not be found in there), will be spawned with the CLI
environment in case that's set. That means users can do something like
`RA_LOG=info zed .` and it will be picked up the rust-analyzer that was
spawned.
Demo/explanation:
https://github.com/user-attachments/assets/455905cc-8b7c-4fc4-b98a-7e027d97cdfa
Partially addresses #8497 (namely, the occurring with `delta`)
As I mentioned in
https://github.com/zed-industries/zed/issues/8497#issuecomment-2226896371,
zed currently replies to OSC color requests (`OSC 10`, `OSC 11`, ...)
out of order when immediately followed by another request (for example
`CSI c`). All other terminals that [I have
tested](https://github.com/bash/terminal-colorsaurus/blob/main/doc/terminal-survey.md)
maintain relative order when replying to requests.
## Solution
Respond to the `ColorRequest` in `process_event` (in the same place
where other PTY writes happen) instead of queuing it up in the internal
event queue.
## Alternative
I initially thought that I could handle the color request similarly to
the `TextAreaSizeRequest` where the size is stored in `last_content` and
updated on `sync`. However this causes the terminal to report
out-of-date values when a "set color" sequence is followed by a color
request.
## Tests
1. `OSC 11; ?` (request bg color) + `CSI c` (request device attributes):
```shell
printf '\e]11;?\e\\ \e[c' && cat -v
# Expected result: ^[]11;rgb:dcdc/dcdc/dddd^[\^[[?6c
# Current result: ^[[?6c^[]11;rgb:dcdc/dcdc/dddd^[\ (❌)
# Result with this PR: ^[]11;rgb:dcdc/dcdc/dddd^[\^[[?6c (✅)
# Result with alternative: ^[]11;rgb:dcdc/dcdc/dddd^[\^[[?6c (✅)
```
2. `OSC 11; rgb:f0f0/f0f0/f0f0` (set bg color) + `OSC 11; ?` (request bg
color)
```shell
printf '\e]11;rgb:f0f0/f0f0/f0f0\e\\ \e]11;?\e\\' && cat -v
# Expected result: ^[]11;rgb:f0f0/f0f0/f0f0^[\
# Current result: ^[]11;rgb:f0f0/f0f0/f0f0^[\ (✅)
# Result with this PR: ^[]11;rgb:f0f0/f0f0/f0f0^[\ (✅)
# Result with alternative: ^[]11;rgb:OUT_OF_DATE_COLOR_HERE^[\ (❌)
```
Release Notes:
- N/A
For future reference: WIP branch of copy/pasting a mixture of images and
text: https://github.com/zed-industries/zed/tree/copy-paste-images -
we'll come back to that one after landing this one.
Release Notes:
- You can now paste images into the Assistant Panel to include them as
context. Currently works only on Mac, and with Anthropic models. Future
support is planned for more models, operating systems, and image
clipboard operations.
---------
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Jason <jason@zed.dev>
Co-authored-by: Kyle <kylek@zed.dev>
This implements #15412. Row-column parsing is changed into a regex to
support more complex patterns like the MSBuild diagnostics. Terminal
`word_regex` is also relaxed to match those suffixes.
Release Notes:
- N/A
Otherwise, ctrl-c makes them stuck being held from time to time
Follow-up of https://github.com/zed-industries/zed/pull/13898 that
reverts the macOS-related part of the PR.
Release Notes:
- N/A
There were two issues:
1. the `ModifiersChanged` event was never emitted on windows.
macOS, x11 and wayland have separate events for this, while on windows
they are sent via the usual `keyup` and `keydown` events, but
`parse_keydown_msg_keystroke` just ignored them.
2. the word segmenting regex didn't include '\' so paths weren't
correctly detected
fixes https://github.com/zed-industries/zed/issues/12321
Release Notes:
- N/A
Part of https://github.com/zed-industries/zed/issues/5141
* adds "run selection" and "run file" tasks for bash and Python.
* replaces newlines with `\n` symbols in the human-readable task labels
* properly escapes task command arguments when spawning the task in
terminal
Caveats:
* bash tasks will always use user's default shell to spawn the
selections, but they should rather respect the shebang line even if it's
not selected
* Python tasks will always use `python3` to spawn its tasks now, as
there's no proper mechanism in Zed to deal with different Python
executables
Release Notes:
- Added tasks for bash and Python to execute selections and open files
in terminal
Currently, terminal will emit resize event every seconds, even if the
size not changed.
this PR fixed only emit resize event when size is changed.
Release Notes:
- N/A
New list (used tasks are above the separator line, sorted by the usage
recency), then all language tasks, then project-local and global tasks
are listed.
Note that there are two test tasks (for `test_name_1` and `test_name_2`
functions) that are created from the same task template:
<img width="563" alt="Screenshot 2024-04-10 at 01 00 46"
src="https://github.com/zed-industries/zed/assets/2690773/7455a82f-2af2-47bf-99bd-d9c5a36e64ab">
Tasks are deduplicated by labels, with the used tasks left in case of
the conflict with the new tasks from the template:
<img width="555" alt="Screenshot 2024-04-10 at 01 01 06"
src="https://github.com/zed-industries/zed/assets/2690773/8f5a249e-abec-46ef-a991-08c6d0348648">
Regular recent tasks can be now removed too:
<img width="565" alt="Screenshot 2024-04-10 at 01 00 55"
src="https://github.com/zed-industries/zed/assets/2690773/0976b8fe-b5d7-4d2a-953d-1d8b1f216192">
When the caret is in the place where no function symbol could be
retrieved, no cargo tests for function are listed in tasks:
<img width="556" alt="image"
src="https://github.com/zed-industries/zed/assets/2690773/df30feba-fe27-4645-8be9-02afc70f02da">
Part of https://github.com/zed-industries/zed/issues/10132
Reworks the task code to simplify it and enable proper task labels.
* removes `trait Task`, renames `Definition` into `TaskTemplate` and use
that instead of `Arc<dyn Task>` everywhere
* implement more generic `TaskId` generation that depends on the
`TaskContext` and `TaskTemplate`
* remove `TaskId` out of the template and only create it after
"resolving" the template into the `ResolvedTask`: this way, task
templates, task state (`TaskContext`) and task "result" (resolved state)
are clearly separated and are not mixed
* implement the logic for filtering out non-related language tasks and
tasks that have non-resolved Zed task variables
* rework Zed template-vs-resolved-task display in modal: now all reruns
and recently used tasks are resolved tasks with "fixed" context (unless
configured otherwise in the task json) that are always shown, and Zed
can add on top tasks with different context that are derived from the
same template as the used, resolved tasks
* sort the tasks list better, showing more specific and least recently
used tasks higher
* shows a separator between used and unused tasks, allow removing the
used tasks same as the oneshot ones
* remote the Oneshot task source as redundant: all oneshot tasks are now
stored in the inventory's history
* when reusing the tasks as query in the modal, paste the expanded task
label now, show trimmed resolved label in the modal
* adjusts Rust and Elixir task labels to be more descriptive and closer
to bash scripts
Release Notes:
- Improved task modal ordering, run and deletion capabilities
Refs #9647
Fixes https://github.com/zed-industries/zed/issues/9792
This pull request moves the computation of scrollbar markers off the
main thread, to prevent them from grinding the editor to a halt when we
have a lot of them (e.g., when there are lots of search results on a
large file). With these changes we also avoid generating multiple quads
for adjacent markers, thus fixing an issue where we stop drawing other
primitives because we've drawn too many quads in the scrollbar.
Release Notes:
- Improved editor performance when displaying lots of search results,
diagnostics, or symbol highlights in the scrollbar
([#9792](https://github.com/zed-industries/zed/issues/9792)).
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Nathan <nathan@zed.dev>
