From 01d85614464a8405a427669b73142c281f3a7faf Mon Sep 17 00:00:00 2001 From: Simon Tatham Date: Tue, 24 May 2022 17:43:48 +0100 Subject: [PATCH] do_bidi: initialise paragraphOverride correctly. I'd forgotten to initialise it at all, which meant it was set to zero by the initial memset of the whole BidiContext on creation. But in our enumeration of bidi character types, zero corresponds to L (the most common left-to-right alphabetic character class), and as a value for paragraphOverride, that is not neutral. As a result, a command such as this (assuming UTF-8) echo -e '\xD7\x90\xD7\x91' would produce Hebrew aleph and beth in the correct display order (aleph on the right), but aligned to the left margin of the terminal instead of the right margin, because the overall direction of the line was taken to be forcibly overridden to "left-to-right" instead of being inferred dynamically from the line contents. do_bidi() is a tiny wrapper on the inner function that does all the real work. And the inner function has been subjected to the whole Unicode 14 bidi conformance test. So naturally, the "trivial" but untested function just outside it is where the embarrassing bug was. --- terminal/bidi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/terminal/bidi.c b/terminal/bidi.c index a56570fd..128f84c5 100644 --- a/terminal/bidi.c +++ b/terminal/bidi.c @@ -3602,6 +3602,7 @@ void do_bidi(BidiContext *ctx, bidi_char *text, size_t textlen) #ifdef REMOVE_FORMATTING_CHARACTERS abort(); /* can't use the standard algorithm in a live terminal */ #else + ctx->paragraphOverride = ON; do_bidi_new(ctx, text, textlen); #endif }