There are currently 4 cases where a ScreenTerminal is linked to a LineDescipleTerminal, these are linked via a special OutputStream.
DisplayTest: https://github.com/jline/jline3/blob/master/terminal/src/test/java/org/jline/utils/DisplayTest.java#L153-L200
TMux: https://github.com/jline/jline3/blob/master/builtins/src/main/java/org/jline/builtins/Tmux.java#L2090-L2136
SwingTerminal: https://github.com/jline/jline3/blob/master/builtins/src/main/java/org/jline/builtins/SwingTerminal.java#L253-L439
WebTerminal: https://github.com/jline/jline3/blob/master/builtins/src/main/java/org/jline/builtins/WebTerminal.java#L395-L487
The base premise is simple; Input bytes are fed to the LineDescipleTerminal (With e.g. processInputBytes or processInputByte, which does some processing and then writes resulting data to the OutputStream provided in the constructor. (This stream is being discussed here)
The stream then does some decoding based on the terminal's charset, and then writes the result to the ScreenTerminal.
-> DisplayTest and TMux are identical, what they do is a simple decode (The stream class is <50 lines), write to ScreenTerminal, and then write potential VT100 output back to the LineDescipleTerminal (sounds like a loop, but it does terminate).
-> WebTerminal is a bit more complicated, as it does manual UTF-8 decoding (Stream class ~100 lines), and it feels like this could be simplified using an UTF8 CharsetDecoder. IT does not feed VT100 output back to the LineDescipleTerminal however. The WebTerminal does not write data directly to the LineDescipleTerminal.processInputBytes, but it calls ScreenTerminal.pipe() before writing data to it to map stuff like arrow keys.
-> SwingTerminal's master outputstream is simply scary (close to 200 lines), I do not see why it has to be so complicated, and it could probably be simplified significantly. Like WebTerminal it does not feed VT100 output back to the LineDescipleTerminal. It also does not use ScreenTerminal.pipe(), so there is probably something missing here.
As a test I replaced the Web & Swingterminal master outputstream logic with that of TMux & DisplayTest (keeping the ScreenTerminal.pipe() from webterminal to map arrow keys ect, and using the correct charset), and it seemed to work fine. (All tests passed, and VT100 command response also worked where it did not before)
Because of the vast difference I didnt dare open a pull unifying all 4 methods like this (even though it worked on my small tests), although I feel some of the difference comes from AI usage, as manual UTF-8 decoding feels unneeded and in SwingTerminal there are redundant (re)initializers, null checks and dead fields.
I am interested to hear your opinion on this matter.
PS:
That being said, if standardizing around the DisplayTest/TMux method is acceptable I can open a pull later.
There are currently 4 cases where a ScreenTerminal is linked to a LineDescipleTerminal, these are linked via a special OutputStream.
DisplayTest: https://github.com/jline/jline3/blob/master/terminal/src/test/java/org/jline/utils/DisplayTest.java#L153-L200
TMux: https://github.com/jline/jline3/blob/master/builtins/src/main/java/org/jline/builtins/Tmux.java#L2090-L2136
SwingTerminal: https://github.com/jline/jline3/blob/master/builtins/src/main/java/org/jline/builtins/SwingTerminal.java#L253-L439
WebTerminal: https://github.com/jline/jline3/blob/master/builtins/src/main/java/org/jline/builtins/WebTerminal.java#L395-L487
The base premise is simple; Input bytes are fed to the LineDescipleTerminal (With e.g.
processInputBytesorprocessInputByte, which does some processing and then writes resulting data to the OutputStream provided in the constructor. (This stream is being discussed here)The stream then does some decoding based on the terminal's charset, and then writes the result to the ScreenTerminal.
-> DisplayTest and TMux are identical, what they do is a simple decode (The stream class is <50 lines), write to ScreenTerminal, and then write potential VT100 output back to the LineDescipleTerminal (sounds like a loop, but it does terminate).
-> WebTerminal is a bit more complicated, as it does manual UTF-8 decoding (Stream class ~100 lines), and it feels like this could be simplified using an UTF8 CharsetDecoder. IT does not feed VT100 output back to the LineDescipleTerminal however. The WebTerminal does not write data directly to the LineDescipleTerminal.processInputBytes, but it calls ScreenTerminal.pipe() before writing data to it to map stuff like arrow keys.
-> SwingTerminal's master outputstream is simply scary (close to 200 lines), I do not see why it has to be so complicated, and it could probably be simplified significantly. Like WebTerminal it does not feed VT100 output back to the LineDescipleTerminal. It also does not use ScreenTerminal.pipe(), so there is probably something missing here.
As a test I replaced the Web & Swingterminal master outputstream logic with that of TMux & DisplayTest (keeping the ScreenTerminal.pipe() from webterminal to map arrow keys ect, and using the correct charset), and it seemed to work fine. (All tests passed, and VT100 command response also worked where it did not before)
Because of the vast difference I didnt dare open a pull unifying all 4 methods like this (even though it worked on my small tests), although I feel some of the difference comes from AI usage, as manual UTF-8 decoding feels unneeded and in SwingTerminal there are redundant (re)initializers, null checks and dead fields.
I am interested to hear your opinion on this matter.
PS:
That being said, if standardizing around the DisplayTest/TMux method is acceptable I can open a pull later.