> I think they made some choices that eventually led to the parser being too complex, largely due to the problem of representing what was parsed.
No, the complexity of the parser can be attributed to the incremental parsing. ble.sh implements an incremental parser where one can update only the necessary parts of the previous syntax tree when a part of the command line is modified. I'd probably use the same data structure (but better abstracted using classes) even if I could implement the parser in C or in higher-level languages.
Thank you for your comment. I'm not sure for your specific case, but generally the performance largely depends on the terminal emulators in my experience. For example, xterm and Windows ConPTY are super slow which are sometimes 100 times slower than the fastest terminals. urxvt (rxvt-unicode), alacritty, terminology are usually fast. xfce4-terminal, qterminal, mintty are acceptable. VTE based terminals (GNOME terminal, lxterminal, etc.), termit, etc. are slow in my environments.
Actually one of the reason why I wrote this program is to test the terminal performances. When I'm searching the benchmark data of Alacritty, I found this issue https://github.com/alacritty/alacritty/issues/289#issue-2001... where the existing Matrix rain program "cmatrix" is mentioned. I tried "cmatrix" in my terminal (I'm using a terminal which I wrote from scratch for myself) and found that the Matrix rain of "cmatrix" is cheaper than I expected. That is the reason why I wrote "cxxmatrix", a version with additional optical effects written in C++.
No, the complexity of the parser can be attributed to the incremental parsing. ble.sh implements an incremental parser where one can update only the necessary parts of the previous syntax tree when a part of the command line is modified. I'd probably use the same data structure (but better abstracted using classes) even if I could implement the parser in C or in higher-level languages.