This step without the '-p' works fine for regular releases but it can
fail if the CI is running when this file changes or on a branch
matching 'patch/ci-release-*'.
The 'dtolnay/rust-toolchain' action ignores the rust-toolchain.toml
file, but the installed 'cargo' respects it. This can create a version
mismatch if the MSRV is different from the stable rust version. Any
additional targets installed by rustup like aarch64-darwin might not
be installed for the correct version. To fix this, we remove the
rust-toolchain.toml file before calling 'cargo'.
* changelog: Checkpoint 2023-01-10
commit: 927fa112ec
* changelog: Checkpoint 2023-02-05
commit: 9c98043c1c
* changelog: Checkpoint 2023-03-17
commit: bd473928ae
* changelog: Checkpoint 2023-03-27
commit: 5323020c3f
* Set a tentative release date for 2023-03-31
* Update CHANGELOG.md
* Mention virtual text PR in inlayed type hints feature links
* Fix description for 5097
* Rebalance features, usability improvements and fixes
* Reorganize some out-of-place changes to the proper sections
* Eliminate the LSP configurations section
This has a lot of overlap with the 'new languages' section with newly
supported LSP configurations. Smaller changes to LSP configurations
are not so common so I folded those into the 'updated languages and
queries' section.
Utf-8 support has been around for a while as an unstable feature but
utf-32 is fairly new. A bunch of LS (like rust-analyzer) added this in
a pinch, but it's pretty broken right now. The performance overhead is
not very large (still a lot better than utf-16). We can switch back
once the ecosystem has matured.
The current implementation didn't reload the theme if no no theme was
explicitly configured (so the default theme was used). This commit
brings `refresh_theme` in line with the initialization code.
the previous implementation used set_string_truncated. This is not only
awkward with this kind of "streaming" string (and therefore lead to an
inefficient and incorrect initial implementation) but that function also
truncates strings of width 1 when there is only a single char available.
The implementation here is performant, correct and also handles the
single width case correctly.
The last update introduced a bug with comments where a comment would
be recognized as a message if there were multiple newlines between
the last message or subject and the comment, causing a noticeable
change in highlighting. This change fixes that behavior.
Add new theme highlight keys, for setting the colour of the breakpoint
character and the current line at which execution has been paused at.
The two new keys are `ui.highlight.frameline` and `ui.debug.breakpoint`.
Highlight according to those keys, both the line at which debugging
is paused at and the breakpoint indicator.
Add an indicator for the current line at which execution is paused
at, themed by the `ui.debug.active` theme scope. Update various themes
to showcase how the new functionality works.
Better icons are dependent on #2869, and as such will be handled in the
future, once it lands.
Closes: #5952
Signed-off-by: Filip Dutescu <filip.dutescu@gmail.com>
If the terminal doesn't send the primary device attributes response to
the query, the `terminal::supports_keyboard_enhancement` function from
crossterm may timeout and return an Err.
We should interpret this error to mean that the terminal doesn't support
the keyboard enhancement protocol rather than an error in claiming the
terminal.
The update includes a fix for comments in commit messages where there
was no space separating the '#' and the comment text.
The comment textobject can be useful occasionally to jump to the
summary part of the commit edit message.
char_idx_at_visual_row_offset asssumed that a single line/block break
always corresponded to a vertical offset of 1. However conceal can hide
the line break (in which case the certical offset would be 0) and line
annotations (or softwrapped inlay hints at the end of the line) can insert
addtional vertical lines.
To correctly account for these cases we simply compute the visual offset
of the start of the next block from the previous block instead of the
visual offset of the block end. This means that the line breaks at the
end of the block (however many there may be) are automatically included
and we don't need to manually add 1 to the `row_offset` anymore.
While scrolling (with the `scroll`) command scrolloff was calculated
slightly differently than in `ensure_cursor_in_view` which could cause
the cursor to get stuck while scrolling
Virtual text lines (either caused by softwrapped inlay hints that take
multiple or line annotations) currently block scrolling downwards.
if the visual offset passed to char_idx_at_visual_offset or
visual_offset_from_block is within a virtual text line then the char
position before the virtual text and a visual offset are returned.
We previously ignored that visual offset and as a result the cursor
would be stuck at the start of the virtual text. This commit fixes
that by simply moving the cursor to the next char (so past the virtual
text) if this visual offset is non-zero
Using `partition_point` ensures we always find the first entry.
With binary search it is "random" (deterministic but implementation
specific) which index is retruned if there are multiple equal elements.
`partition_point` was added to the standard library to cover extactly
the usecase here.
The top of a view is marked by a char idx anchor. That char idx is
usually the first character of the visual line it's on. We use a char
index instead of a line index because the view may start in the middle
of a line with soft wrapping. However, it's possible to temporarily
endup in a state where this anchor is not the first character of the
first visual line. This is pretty rare because edits usually happen
inside/after the view. In most cases we handle this case correctly.
However, if the cursor is before the anchor (but still in view)
there can be crashes or visual artifacts. This is caused by the fact
that visual_offset_from_anchor (and the positioning code in view.rs)
incorrectly assumed that the (cursor) position is always after the
view anchor if the cursor is in view. But if the anchor is not the
first character of the first visual line this is not the case anymore.
In that case crashes and visual artifacts are possible. This commit
fixes that problem by changing `visual_offset_from_anchor` (and
callsites) to properly consider that case.
