I have just found out that my recent Windows Terminal version
supported rendering undercurl (see
https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-20-release
). However, looking at the source, terminfo is required for helix to
emit the undercurl control code, which isn't available on Windows AFAIK.
This commit make helix respects the `editor.undercurl` option when
there is no terminfo.
Tested on Windows Terminal Preview 1.20
Signed-off-by: Khang Nguyen <khang.nguyenduycse@hcmut.edu.vn>
* match instead of crash
* pulling bracketedpaste out, refactor, tracking for bracketed paste
* sending disable bracketed paste only when supports true
* move disable bracketed paste to throwaway
* rust-toolchain.toml: bump MSRV to 1.70.0
With Firefox 120 released on 21 November 2023, the MSRV is now 1.70.0.
* Fix cargo fmt with Rust 1.70.0
* Fix cargo clippy with Rust 1.70.0
* Fix cargo doc with Rust 1.70.0
* rust-toolchain.toml: add clippy component
* .github: bump dtolnay/rust-toolchain to 1.70
* helix-term: bump rust-version to 1.70
* helix-view/gutter: use checked_ilog10 to count digits
* helix-core/syntax: use MAIN_SEPARATOR_STR constant
* helix-view/handlers/dap: use Display impl for displaying process spawn error
* WIP: helix-term/commands: use checked math to assert ranges cannot overlap
When Application::run is exiting, either Terminal::restore or
Terminal::force_restore will be called depending
on if a panic occured or not.
Both of these functions will reset the cursor to terminal's default.
After this is done, Terminal::drop will be called.
If terminal.cursor_kind == Hidden, then
the cursor will be reset to a CursorKind::Block,
undoing the work of restore or force_restore.
This commit just removes the drop implementation,
as its job is already better handled in restore and force_restore.
This picks up changes to the `editor.mouse` option at runtime - either
through `:set-option` or `:config-reload`. When the value changes, we
tell the terminal to enable or disable mouse capture sequences.
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.
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.
* 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>
In my testing this takes around 3-4ms in terminals that support the
enhanced keyboard protocol (Kitty, WezTerm) and a few hundred
microseconds in terminals that don't (st, Alacritty).
Wether the host terminal supports keyboard enhancement can be cached
for the lifetime of a Helix session.
Caching this lookup prevents a potential lockup within crossterm's
event reading system where the query for the keyboard enhancement
support waits on the next keyboard event, which can happen if the
crossterm event stream is checked by `tokio::select!` in another
thread.
This moves the `Application::claim_term` and
`helix-term::application::restore_term` functions into the helix-tui
crate. How the terminal should be claimed and restored is a TUI concern
and is implemented differently through different TUI backends.
This cleans out a lot of crossterm and TUI code in Application and
makes it easier to modify claim/restore based on information we query
from the terminal host. The child commit will take advantage of this
to cache the check for whether the host terminal supports the keyboard
enhancement protocol. Without this change, caching that information
takes much more code which is not easily reusable for anything else.
The code to restore the terminal is somewhat duplicated by this patch:
we want to restore the terminal in cases of panics. Panic handler hooks
must live for `'static` and the Application's terminal does not.
