bidi support in the extension

First - i tried to save you time and use report an issue in the extension but failed to find it. Do remember most of your users are stone age :) - provide an instruction of where to find ibm i report an issue (not in ctl+shift+p my friend).
Extension version 2.15.3
Vs code
Version: 1.100.3 (user setup)
Commit: 258e40fedc6cb8edf399a463ce3a9d32e7e1f6f3
Date: 2025-06-02T13:30:54.273Z
Electron: 34.5.1
ElectronBuildId: 11369351
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.22631

Ibm version – 7.4

Description

CCSID 424 is EBCDIC-based and not compatible with modern editors. UTF-8 (CCSID 1208) is required for:
• Unicode compliance
• Proper display in VSCode
• Integration with Git and modern tooling
• UTF-8 uses Unicode BiDi rules for rendering CONTEXTUAL RTL/LTR text.
• Mixing Hebrew with Latin, digits, or punctuation causes reordering.
• Parentheses, colons, and quotes may appear in unexpected positions.
• CCSID 424 assumes fixed directionality, while UTF-8 rendering engines do not.
• The above is true for other languages as well such as Arabic and farsi.
• This is not an issue in RDI since RDI uses 424 -> 1255 conversion, but this is not possible for VSCODE.
• I want to control the reordering in vscode

Example:
In order to visualize the problem in rpg I take image snapshot from green screen and vscode
Source:

Vscode member – it is not compileable

Work around tested – tried to set my user id for different CCSID 62211, received message in vscode

The CCSID of the SSH connection (424) does not match the job CCSID (62211). This may cause issues with objects with variant characters.

And nothing improved. Why did the ssh connection is 424 for user with 62211 ?

Tried different work around (probably not sufficient most customers but does improve something) issued cpytostmf from my member -> intermediate file with 62211 -> ifs file with 1208 – results are good.
Request for fix \ work around

1. I would even volunteer on doing it if I know where it make sense. If (I think this is the case ) data leaves the system I in ebcdic in icon and translated just before going to vscode then this is code in the extension. If the extension just perform copy on the as400 then this can be changed on the as400. This is a MUST, unless it is handled no one that uses bidi languages will adopt vscode (8.5% of world population mind you 😊)
2. Rdi offers lrm and rlm insertion for writing bidi in the code , this we can live if not present but it is nice and probably not difficult.
Due to AI integration this becomes a top priority for most of my customers.

Reporduction material:

• Restore the save file to an as400
• Connect to the as400 using user profile with ccsid set to 424
• Open the only member . It will show scramble Hebrew.


No repository files, tests, or entry points are named. Start by reproducing the issue with an IBM i connection using CCSID 424 and the supplied Hebrew RPG member, then trace how the extension transfers and decodes member contents. Done means bidirectional Hebrew, Arabic, and Farsi text renders correctly in VS Code, with any requested LRM/RLM behavior documented or supported.

Written by the indexing model from the issue text.