TODO:
- [x] Add markdown rendering to channel chat
- [x] Unify (?) rendering logic between hover popover and chat
- [x] ~~Determine how to deal with document-oriented markdown like `#`~~
Unimportant until we want to do something special with `#channel`
- [x] Tidy up spacing and styles in chat panel
Release Notes:
- Added markdown rendering to channel chat
- Improved channel chat message style
- Fixed a bug where long chat messages would not soft wrap
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.
Release Notes:
- vim: Add v1 of command mode
([#279](https://github.com/zed-industries/community/issues/279)). The
goal was to cover 90% of what most people actually do, but it is very
incomplete. Known omissions are that ranges cannot be specified (except
that `:%s//` must always specify the % range), commands cannot take
arguments (you can `:w` but not `:w [file]`), and there is no history.
Please file feature requests on
https://github.com/zed-industries/community as you notice things that
could be better.
- `:` triggers zed's command palette. If you type a known vim command it
will run it, otherwise you get zed's normal fuzzy search. For this
release supported commands are limited to:
- - `:w[rite][!]`, `:wq[!]`, `:q[uit][!]`, `:wa[ll][!]`, `:wqa[ll][!]`,
`:qa[ll][!]`, `:[e]x[it][!]`, `:up[date]` to save/close tab(s) and
pane(s).
- - `:cq` to quit completely.
- - `:vs[plit]`, `:sp[lit]` to split vertically/horizontally
- - `:new`, `:vne[w]` to create a new file in a new pane above or to the
left
- - `:tabedit`, `:tabnew` to create a new file in a new tab.
- - `:tabn[ext]`, `:tabp[rev]` to go to previous/next tabs
- - `:tabc[lose]` to close tabs
- - `:cn[ext]`, `:cp[rev]`, `:ln[ext]`, `:lp[rev]` to go to the
next/prev diagnostics.
- - `:cc`, `:ll` to open the errors page
- - `:<number>` to jump to a line number.
- - `:$` to jump to end of file
- - `:%s/foo/bar/` (note that /g is always implied, the range must
always be %, and zed uses different regex syntax to vim)
- - `:/foo` and `:?foo` to jump to next/prev line matching foo
- - `:j[oin]`, to join the current line (no range is yet supported)
- - `:d[elete][l][p]`, to delete the current line (no range is yet
supported)
- - `:s[ort] [i]` to sort the current selection (case-insensitively)
- vim: Add `ctrl-w o` (closes everything except the current item) and
`ctrl-w n` (creates a new file in the pane above).
([#1884](https://github.com/zed-industries/community/issues/1884))
- all: Add a "Discard" option to prompt when saving a file with
conflicts (previously this only appeared on close, not on save).
Internal changes:
- The Picker will now wait for pending queries before confirming (to
handle people typing `: w enter` rapidly.
- workspace::save_item and Pane::save_item are now merged together, and
the behavior controlled by `workspace::SaveIntent`.
- Many actions related to closing/saving items now take an optional
`SaveIntent`.
-
Targeting Preview of 09.27.
This is still pending several touchups/clearups:
- We should watch multibuffer for changes and rescan the excerpts. This
should also update match count.
- Closing editor while multibuffer with 100's of changed files is open
leads to us prompting for save once per each file in the multibuffer.
One could in theory save in multibuffer before closing it (thus avoiding
unnecessary prompts), but it'd be cool to be able to "Save all"/"Discard
All".
Release Notes:
- Added "Replace in project" functionality
Users of keyboard layout with IME complained about the peculiar
behaviour where typing in "sss" and then removing all of it left behind
one 's' and also appended a closing brace. This was not reproducible on
a buffer without language, so I've suspected that brace insertion might
be a problem here. For whatever reason when the user removes the last
character from a run that triggered IME, we receive a notification about
an empty insertion. Sadly, brace completion does not handle an empty
input properly and we erroneously insert a closing brace when deleting
the followup characters. In fact, the brace inserted is always the
closing brace for the first entry in language's config.toml 'brackets'
field (see Scheme vs Markdown). This guard also allows for the proper
removal of the first character.
Closes community tickets zed-industries/community#877zed-industries/community#1329
Z-2869
Release Notes:
- Fixed handling of bracket completion for international keyboard
layouts that use IME. This led to Zed erroneously inserting the `}`
character while removing the first character that triggered IME.
This is still WIP, mostly pending styling. I added a pretty rudimentary
text field and no buttons whatsoever other than that. I am targeting a
Preview of 09.13, as I am gonna be on PTO for the next week.
I dislike the current implementation slightly because of `regex`'s crate
syntax and lack of support of backreferences. What strikes me as odd wrt
to syntax is that it will just replace a capture name with empty string
if that capture is missing from the regex. While this is perfectly fine
behaviour for conditionally-matched capture groups (e.g. `(foo)?`), I
think it should still error out if there's no group with a given name
(conditional or not).
Release Notes:
- Added "Replace" functionality to buffer search.
