Multiple language support via ibus

[archisman-panigrahi]

It would be nice to be able to connect this to iBus to automatically support hundreds of languages

[luginf]

@archisman-panigrahi tell me your usage and the current limitation you might have. Here is a resume of how to use WrithDeck with iBus:

GUI mode (Tcl/Tk)

Tk uses the XIM protocol natively on Linux/X11. Since iBus implements XIM, multilingual input (CJK, Arabic,
Indic scripts, etc.) already works in WrithDeck's GUI without any code changes. The user just needs to set the
environment before launching:

export XMODIFIERS="@im=ibus"
wish writhdeck.tcl

The one rough edge is the pre-edit window position: the floating composition popup tends to appear in a screen
corner rather than following the text cursor. Fixing this properly would require a few lines in gui.tcl to
report the cursor position to the XIM context.

On Wayland, iBus uses a different protocol (text-input Wayland) and Tk falls back to XWayland, which degrades
the IME experience. This is a Tk limitation, not something WrithDeck can fix on its own. On macOS, the system
IME works natively with Tk. On Windows, Tk's IME support is limited.

Bottom line for GUI: no code needed for basic support; a documentation note and optionally a cursor-position
fix would cover 95% of use cases.

TUI mode (terminal)

In TUI mode, WrithDeck never talks to iBus directly. The chain is:

iBus → terminal emulator → stdin (UTF-8 bytes) → WrithDeck

The terminal handles composition entirely; WrithDeck just receives the final composed character. As long as
chan configure stdin -encoding utf-8 is active (which it is), Tcl reads complete characters correctly — a
Japanese 日 arrives as one character, not three raw bytes.

What works out of the box: any script where one character occupies one terminal column (Latin, Cyrillic,
Greek, etc.) works with no changes.

Known issues:

┌───────────────────┬───────────────────────────────────────────────────────┬────────────────────────────┐
│       Issue       │                         Cause                         │           Impact           │
├───────────────────┼───────────────────────────────────────────────────────┼────────────────────────────┤
│ CJK double-width  │ Characters like 日, 한, 中 occupy 2 terminal columns; │ Display misalignment, not  │
│                   │  WrithDeck's line-wrap math assumes 1 char = 1 column │ data-corrupting            │
├───────────────────┼───────────────────────────────────────────────────────┼────────────────────────────┤
│ RTL text (Arabic, │ Terminals don't do bidirectional rendering by default │ Text appears in the wrong  │
│  Hebrew)          │                                                       │ visual order               │
├───────────────────┼───────────────────────────────────────────────────────┼────────────────────────────┤
│ Terminals without │ SSH sessions, virtual consoles, some minimal          │ No composition window, no  │
│  IME              │ emulators                                             │ IME input                  │
└───────────────────┴───────────────────────────────────────────────────────┴────────────────────────────┘

The double-width issue is fixable by replacing string length with a col-width helper that counts 2 columns for
CJK code points. RTL is a terminal-level limitation that WrithDeck cannot solve without a BiDi library.

Bottom line for TUI: UTF-8 input works today for most scripts. CJK display is usable but imperfect. RTL is
blocked at the terminal level and would require significant work to address properly.