Repository navigation
fix(xdisp): mode-line multibyte identity follows inputs, not content (#470) #473
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,77 @@ | ||
| #![cfg(unix)] | ||
| //! Issue #470: a Unicode dot in the mode line must not degrade to a literal | ||
| //! `\267` escape after initially rendering correctly. | ||
| //! | ||
| //! GNU displays a raw eight-bit character as `\` plus its octal byte | ||
| //! (src/xdisp.c:8649-8662, `%03o` of CHAR_TO_BYTE8), so a literal `\267` on | ||
| //! screen is the signature of the mode-line text having been re-derived with | ||
| //! the multibyte U+00B7 turned into a raw byte. The regression drives real | ||
| //! PTYs: boot a GNU/neomacs pair, install a mode line containing both a | ||
| //! literal U+00B7 and `(string 183)`, then force repeated mode-line | ||
| //! re-evaluations and require the dot to stay a dot on both sides across | ||
| //! every redisplay. | ||
|
|
||
| use crate::support::{ | ||
| boot_pair, eval_expression, settle_session, use_backend_only_vc_mode_line, | ||
| use_deterministic_emacs_version, | ||
| }; | ||
| use neomacs_tui_tests::TuiSession; | ||
| use std::time::Duration; | ||
|
|
||
| const INSTALL_DOT_MODE_LINE: &str = | ||
| "(setq mode-line-format (list \"A\" \"·\" \"B\" (string 183) \"C\"))"; | ||
|
|
||
| fn boot_pair_plain() -> (TuiSession, TuiSession) { | ||
| let (mut gnu, mut neo) = boot_pair(""); | ||
| settle_session(&mut gnu); | ||
| settle_session(&mut neo); | ||
| // Strip the VC segment so both mode lines are stable text. | ||
| use_backend_only_vc_mode_line(&mut gnu, &mut neo); | ||
| use_deterministic_emacs_version(&mut gnu, &mut neo); | ||
| (gnu, neo) | ||
| } | ||
|
|
||
| /// Install the dot mode line and force N full mode-line re-evaluations with | ||
| /// redisplays on both sessions. | ||
| fn install_and_force_updates(gnu: &mut TuiSession, neo: &mut TuiSession, rounds: usize) { | ||
| eval_expression(gnu, neo, INSTALL_DOT_MODE_LINE); | ||
| for _ in 0..rounds { | ||
| eval_expression( | ||
| gnu, | ||
| neo, | ||
| "(progn (force-mode-line-update t) (redisplay) (sit-for 0))", | ||
| ); | ||
| std::thread::sleep(Duration::from_millis(100)); | ||
| } | ||
| } | ||
|
|
||
| #[test] | ||
| fn mode_line_unicode_dot_stays_a_dot_across_forced_updates() { | ||
| let (mut gnu, mut neo) = boot_pair_plain(); | ||
| install_and_force_updates(&mut gnu, &mut neo, 5); | ||
|
|
||
| // The reporter saw a CORRECT first frame and a later escaped one, so the | ||
| // assertion must hold after arbitrarily many re-evaluations, not only on | ||
| // the first render. Probed on real GNU 31.1 (PTY, LC_ALL=C.UTF-8): the | ||
| // installed mode line renders `A·B·C` -- BOTH the literal "·" and the | ||
| // `(string 183)` element show the dot glyph, because GNU's `concat` makes | ||
| // the integer character 183 a MULTIBYTE string holding U+00B7 (princ | ||
| // emits c2 b7 for both), never a raw byte. A `\267` on screen is | ||
| // therefore the raw-byte degradation signature on either element. | ||
| let gnu_screen = gnu.screen().contents(); | ||
| let neo_screen = neo.screen().contents(); | ||
| assert!( | ||
| gnu_screen.contains('·'), | ||
| "GNU lost the dot after forced updates:\n{gnu_screen}" | ||
| ); | ||
| assert!( | ||
| neo_screen.contains('·'), | ||
| "neomacs degraded the dot after forced updates:\n{neo_screen}" | ||
| ); | ||
| // Exact parity: neomacs must match GNU's `A·B·C` -- neither element may | ||
| // degrade to its octal escape. | ||
| assert_eq!( | ||
| gnu_screen, neo_screen, | ||
| "mode lines must render identically after forced updates" | ||
| ); | ||
| } |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
127 changes: 127 additions & 0 deletions
127
crates/neovm-core/src/emacs_core/display/xdisp/tests/mode_line_multibyte_identity.rs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,127 @@ | ||
| //! Issue #470: the mode-line result's multibyte identity must come from the | ||
| //! FORMAT INPUTS, never from whether the accumulated characters happen to fit | ||
| //! in one byte. | ||
| //! | ||
| //! `into_display_output' used to derive `multibyte` as "any code > 0xFF", so | ||
| //! a mode line whose only non-ASCII character is a Latin-1-supplement | ||
| //! character (U+0080..U+00FF, e.g. U+00B7 MIDDLE DOT) was re-encoded as a | ||
| //! UNIBYTE string of raw bytes -- and a raw byte displays as GNU's octal | ||
| //! escape (`\267`, src/xdisp.c:8649-8662 `"%03o"` of CHAR_TO_BYTE8). That is | ||
| //! exactly the reported "dot renders, then turns into a literal `\267`". | ||
| //! GNU never re-encodes: a string's multibyte flag follows its inputs | ||
| //! (the `concat' rule -- multibyte iff any argument is multibyte), so U+00B7 | ||
| //! stays U+00B7 across every mode-line re-evaluation. | ||
|
|
||
| use super::*; | ||
| use crate::emacs_core::Context; | ||
|
|
||
| fn interactive() -> Context { | ||
| let mut eval = Context::new(); | ||
| eval.set_variable("noninteractive", Value::NIL); | ||
| eval | ||
| } | ||
|
|
||
| fn render(eval: &mut Context, elements: Vec<Value>) -> ModeLineDisplayOutput { | ||
| let buffer_id = eval.buffers.current_buffer().expect("current buffer").id; | ||
| let frame_id = eval | ||
| .frames | ||
| .create_frame("mode-line-multibyte-identity", 800, 600, buffer_id); | ||
| let window_id = eval.frames.get(frame_id).expect("frame").selected_window; | ||
| format_mode_line_for_display_with_sources( | ||
| eval, | ||
| Value::list(elements), | ||
| Value::make_window(window_id.0), | ||
| Value::make_buffer(buffer_id), | ||
| 80, | ||
| ) | ||
| } | ||
|
|
||
| /// `(multibyte, bytes)` of the rendered output string. | ||
| fn output_identity(output: &ModeLineDisplayOutput) -> (bool, Vec<u8>) { | ||
| let value = output.value(); | ||
| let string = value | ||
| .as_lisp_string() | ||
| .expect("mode-line output is a string"); | ||
| (string.is_multibyte(), string.as_bytes().to_vec()) | ||
| } | ||
|
|
||
| #[test] | ||
| fn mode_line_middle_dot_stays_multibyte_like_its_input() { | ||
| crate::test_utils::init_test_tracing(); | ||
| let mut eval = interactive(); | ||
| let output = render( | ||
| &mut eval, | ||
| vec![Value::string("A"), Value::string("·"), Value::string("B")], | ||
| ); | ||
| let (multibyte, bytes) = output_identity(&output); | ||
| assert!( | ||
| multibyte, | ||
| "a mode line built from multibyte inputs must stay multibyte; \ | ||
| got unibyte bytes {bytes:?} -- U+00B7 degrades to a raw byte and \ | ||
| displays as \\267 (issue #470)" | ||
| ); | ||
| assert_eq!(bytes, b"A\xC2\xB7B".to_vec()); | ||
| } | ||
|
|
||
| #[test] | ||
| fn mode_line_latin1_supplement_band_is_multibyte_not_raw_bytes() { | ||
| // The whole degrading band U+0080..U+00FF: every character in it has a | ||
| // code that fits in one byte, which is exactly what the old content | ||
| // heuristic got wrong. | ||
| crate::test_utils::init_test_tracing(); | ||
| let mut eval = interactive(); | ||
| let band: String = (0x80u32..=0xFF).flat_map(char::from_u32).collect(); | ||
| let output = render(&mut eval, vec![Value::string(&band)]); | ||
| let (multibyte, bytes) = output_identity(&output); | ||
| assert!(multibyte); | ||
| assert_eq!(bytes, band.as_bytes().to_vec()); | ||
| } | ||
|
|
||
| #[test] | ||
| fn mode_line_re_derivation_keeps_the_multibyte_identity() { | ||
| // The issue's observed transition: a later mode-line re-evaluation must | ||
| // not change the identity of the first result. Feed the rendered output | ||
| // back through the walker and require byte-identical, still-multibyte | ||
| // output. | ||
| crate::test_utils::init_test_tracing(); | ||
| let mut eval = interactive(); | ||
| let first = render( | ||
| &mut eval, | ||
| vec![Value::string("A"), Value::string("·"), Value::string("B")], | ||
| ); | ||
| let second = render(&mut eval, vec![first.value()]); | ||
| let (multibyte, bytes) = output_identity(&second); | ||
| assert!(multibyte, "re-derived mode line lost multibyteness"); | ||
| assert_eq!(bytes, b"A\xC2\xB7B".to_vec()); | ||
| } | ||
|
|
||
| #[test] | ||
| fn mode_line_unibyte_raw_byte_input_stays_unibyte_like_gnu() { | ||
| // GNU parity control: a UNIBYTE input with a raw byte keeps unibyte | ||
| // identity (and therefore displays as the raw-byte escape `\267`, | ||
| // exactly as GNU displays a unibyte string's raw byte). The fix must | ||
| // not "repair" raw bytes that GNU also leaves raw. | ||
| crate::test_utils::init_test_tracing(); | ||
| let mut eval = interactive(); | ||
| let raw = Value::heap_string(crate::heap_types::LispString::from_unibyte(vec![0xB7])); | ||
| let output = render(&mut eval, vec![Value::string("A"), raw, Value::string("B")]); | ||
| let (multibyte, bytes) = output_identity(&output); | ||
| assert!(!multibyte, "unibyte input must not become multibyte"); | ||
| assert_eq!(bytes, b"A\xB7B".to_vec()); | ||
| } | ||
|
|
||
| #[test] | ||
| fn mode_line_multibyte_input_with_high_codepoints_stays_multibyte() { | ||
| // Regression guard above the degrading band: U+2014 EM DASH already | ||
| // forced multibyteness under the old content heuristic (> 0xFF); the | ||
| // input-driven rule keeps it. | ||
| crate::test_utils::init_test_tracing(); | ||
| let mut eval = interactive(); | ||
| let output = render( | ||
| &mut eval, | ||
| vec![Value::string("A"), Value::string("—"), Value::string("B")], | ||
| ); | ||
| let (multibyte, bytes) = output_identity(&output); | ||
| assert!(multibyte); | ||
| assert_eq!(bytes, "A—B".as_bytes().to_vec()); | ||
| } |
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.