wezterm/bidi/Cargo.toml

[package]
name = "wezterm-bidi"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[features]
use_serde = ["serde"]

[dependencies]
log = "0.4"
serde = {version="1.0", features = ["derive"], optional=true}

[dev-dependencies]
k9 = "0.11.0"
pretty_env_logger = "0.4"
Add wezterm-bidi crate In order to support RTL/BIDI, wezterm needs a bidi implementation. I don't think a well-conforming rust implementation exists today; what I found were implementations that didn't pass 100% of the conformance tests. So I decided to port "bidiref", the reference implementation of the UBA described in http://unicode.org/reports/tr9/ to Rust. This implementation focuses on conformance: no special measures have been taken to optimize it so far, with my focus having been to ensure that all of the approx 780,000 test cases in the unicode data for unicode 14 pass. Having the tests passing 100% allows for making performance improvements with confidence in the future. The API isn't completely designed/fully baked. Until I get to hooking it up to wezterm's shaper, I'm not 100% sure exactly what I'll need. There's a good discussion on API in https://github.com/open-i18n/rust-unic/issues/273 that suggests omitting "legacy" operations such as reordering. I suspect that wezterm may actually need that function to support monospace text layout in some terminal scenarios, but regardless: reordering is part of the conformance test suite so it remains a part of the API. That said: the API does model the major operations as separate phases, so you should be able to pay for just what you use: * Resolving the embedding levels from a paragraph * Returning paragraph runs of those levels (and their directions) * Returning the whitespace-level-reset runs for a line-slice within the paragraph * Returning the reordered indices + levels for a line-slice within the paragraph. refs: https://github.com/wez/wezterm/issues/784 refs: https://github.com/kas-gui/kas-text/issues/20 2022-01-21 18:42:44 +03:00			`[package]`
			`name = "wezterm-bidi"`
			`version = "0.1.0"`
			`edition = "2021"`

			`# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html`

bidi: tag Line with bidi mode This commit refines bidi property handling: * experimental_bidi has been split into two new configuration settings; `bidi_enabled` (which controls whether the terminal performs implicit bidi processing) and `bidi_direction` which specifies the base direction and whether auto detection is enabled. * The `Line` type can now store those bidi properties (they are actually split across 3 bits representing enabled, auto-detection and direction) * The terminal now has a concept of active bidi properties and default bidi properties * The default properties are pulled from the wezterm configuration * active bidi properties are potentially set via escape sequences, BDSM (which sets bidi_enabled) and SCP (which sets bidi_direction). We don't support the 2501 temporary dec private mode suggested by the BIDI recommendation doc at this time. * When creating new `Line`'s or clearing from the start of a `Line`, the effective bidi properties are computed (from the active props, falling back to default propr) and applied to the `Line`. * When rendering the line, we now look at its bidi properties instead of just the global config. The default bidi properties are `bidi_enabled: false` and `bidi_direction: LeftToRight` which corresponds to the typical bidi-unaware mode of most terminals. It is possible to live reload the config to change the effective defaults, but note that they apply, by design, to new lines being processed through the terminal. That means existing output is left unaffected by a config reload, but subsequently printed lines will respect it. Pressing CTRL-L or otherwise contriving to have the running application refresh its display should cause the refreshed display to update and apply the new bidi mode. refs: #784 2022-01-30 19:22:17 +03:00			`[features]`
			`use_serde = ["serde"]`

Add wezterm-bidi crate In order to support RTL/BIDI, wezterm needs a bidi implementation. I don't think a well-conforming rust implementation exists today; what I found were implementations that didn't pass 100% of the conformance tests. So I decided to port "bidiref", the reference implementation of the UBA described in http://unicode.org/reports/tr9/ to Rust. This implementation focuses on conformance: no special measures have been taken to optimize it so far, with my focus having been to ensure that all of the approx 780,000 test cases in the unicode data for unicode 14 pass. Having the tests passing 100% allows for making performance improvements with confidence in the future. The API isn't completely designed/fully baked. Until I get to hooking it up to wezterm's shaper, I'm not 100% sure exactly what I'll need. There's a good discussion on API in https://github.com/open-i18n/rust-unic/issues/273 that suggests omitting "legacy" operations such as reordering. I suspect that wezterm may actually need that function to support monospace text layout in some terminal scenarios, but regardless: reordering is part of the conformance test suite so it remains a part of the API. That said: the API does model the major operations as separate phases, so you should be able to pay for just what you use: * Resolving the embedding levels from a paragraph * Returning paragraph runs of those levels (and their directions) * Returning the whitespace-level-reset runs for a line-slice within the paragraph * Returning the reordered indices + levels for a line-slice within the paragraph. refs: https://github.com/wez/wezterm/issues/784 refs: https://github.com/kas-gui/kas-text/issues/20 2022-01-21 18:42:44 +03:00			`[dependencies]`
			`log = "0.4"`
bidi: tag Line with bidi mode This commit refines bidi property handling: * experimental_bidi has been split into two new configuration settings; `bidi_enabled` (which controls whether the terminal performs implicit bidi processing) and `bidi_direction` which specifies the base direction and whether auto detection is enabled. * The `Line` type can now store those bidi properties (they are actually split across 3 bits representing enabled, auto-detection and direction) * The terminal now has a concept of active bidi properties and default bidi properties * The default properties are pulled from the wezterm configuration * active bidi properties are potentially set via escape sequences, BDSM (which sets bidi_enabled) and SCP (which sets bidi_direction). We don't support the 2501 temporary dec private mode suggested by the BIDI recommendation doc at this time. * When creating new `Line`'s or clearing from the start of a `Line`, the effective bidi properties are computed (from the active props, falling back to default propr) and applied to the `Line`. * When rendering the line, we now look at its bidi properties instead of just the global config. The default bidi properties are `bidi_enabled: false` and `bidi_direction: LeftToRight` which corresponds to the typical bidi-unaware mode of most terminals. It is possible to live reload the config to change the effective defaults, but note that they apply, by design, to new lines being processed through the terminal. That means existing output is left unaffected by a config reload, but subsequently printed lines will respect it. Pressing CTRL-L or otherwise contriving to have the running application refresh its display should cause the refreshed display to update and apply the new bidi mode. refs: #784 2022-01-30 19:22:17 +03:00			`serde = {version="1.0", features = ["derive"], optional=true}`
Add wezterm-bidi crate In order to support RTL/BIDI, wezterm needs a bidi implementation. I don't think a well-conforming rust implementation exists today; what I found were implementations that didn't pass 100% of the conformance tests. So I decided to port "bidiref", the reference implementation of the UBA described in http://unicode.org/reports/tr9/ to Rust. This implementation focuses on conformance: no special measures have been taken to optimize it so far, with my focus having been to ensure that all of the approx 780,000 test cases in the unicode data for unicode 14 pass. Having the tests passing 100% allows for making performance improvements with confidence in the future. The API isn't completely designed/fully baked. Until I get to hooking it up to wezterm's shaper, I'm not 100% sure exactly what I'll need. There's a good discussion on API in https://github.com/open-i18n/rust-unic/issues/273 that suggests omitting "legacy" operations such as reordering. I suspect that wezterm may actually need that function to support monospace text layout in some terminal scenarios, but regardless: reordering is part of the conformance test suite so it remains a part of the API. That said: the API does model the major operations as separate phases, so you should be able to pay for just what you use: * Resolving the embedding levels from a paragraph * Returning paragraph runs of those levels (and their directions) * Returning the whitespace-level-reset runs for a line-slice within the paragraph * Returning the reordered indices + levels for a line-slice within the paragraph. refs: https://github.com/wez/wezterm/issues/784 refs: https://github.com/kas-gui/kas-text/issues/20 2022-01-21 18:42:44 +03:00
			`[dev-dependencies]`
			`k9 = "0.11.0"`
			`pretty_env_logger = "0.4"`