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.
Simple highlight query file with keywords and builtin types
matching. Many VHDL types however are defined in std libraries
which do not currently get matched on.
This is because the grammar doesn't consider them builtin types.
* build(deps): bump bitflags from 1.3.2 to 2.0.2
Bumps [bitflags](https://github.com/bitflags/bitflags) from 1.3.2 to 2.0.2.
- [Release notes](https://github.com/bitflags/bitflags/releases)
- [Changelog](https://github.com/bitflags/bitflags/blob/main/CHANGELOG.md)
- [Commits](https://github.com/bitflags/bitflags/compare/1.3.2...2.0.2)
---
updated-dependencies:
- dependency-name: bitflags
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
* deps: Resolve bitflags 2.0 breaking changes
Bitflags 2.0 release made some breaking changes requiring some small
changes to the Helix codebase.
Almost all of the necessary changes are to manually `#[derive(..)]`
trait implementations which are no longer automatically derived for
all bitflags. All of these were previously automatically derived:
#[derive(PartialEq, Eq, PartialOrd, Ord, Hash, Debug, Clone, Copy]
I have derived the minimum traits for each bitflag type.
The other change was to the `.bits` field. This is now a `.bits()`
method so the usage of this has been updated in the `Borders` type.
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
