Restrict user input requests

[0xHericles]

Also, you bring up a good point that I have been thinking about. The mechanism of socket triggering on every button is really slowing down the input of the user. I am thinking of an enhancement in the form of a buffer in the front-end so that the command is executed only when return is pressed. The input delay, is an issue that needs to be addressed before the software can have a functional release. Any thoughts @hericlesme ?

Originally posted by @satanb4 in #42 (comment)

[0xHericles]

Actually, every keydown event is triggering a request to the python backend. A good solution would be to wait for the user to press return so that the request would be made with the command to be executed. This would also simplify the logic in the backend. As @satanb4 said.

[satanb4]

I'll look into this. This would also allow for a more comprehensive log file.

[0xHericles]

Okay, @satanb4! Yes, of course, greatly simplifying the logger and will help us create a better view of the commands. When resolved, we will only receive the commands that are executed. 😁

[satanb4]

Assign me this Issue

[0xHericles]

@satanb4 sure! 🚀

[satanb4]

@hericlesme I have a major issue here. We need to update to a newer version of XtermJs to support advanced cursor movement, better buffer security and also general speed. There is implementation of cursor controls on the XtermJS from the Node package manager and hence I propose that we migrate to that. Otherwise we're already developing an application that will be outdated when released.
Take a look at this and this. There's issues that are based on this dependency as this. Would need to discuss the migration.

[vladdoster]

@hericlesme I have a major issue here. We need to update to a newer version of XtermJs to support advanced cursor movement, better buffer security and also general speed. There is implementation of cursor controls on the XtermJS from the Node package manager and hence I propose that we migrate to that. Otherwise we're already developing an application that will be outdated when released.
Take a look at this and this. There's issues that are based on this dependency as this. Would need to discuss the migration.

Good catch on this @satanb4. Maybe open up a migration issue for discussion? I would like to ask a few questions maybe about building a bundle for our frontend deps with webpack?

[jerch]

So you want something like a local echo mode. As you already figured, xterm.js does not provide anything like that out of the box, as it mainly mimicks functionality of DEC terminals, which are seen as dumb terminals always relying on the input --> pty --> process --> pty --> output cycle (in contrast to "intelligent" terminals in the 80s, which had local mirroring and editing functionality).

It is still possible to get this done, but it is more involved. Things to consider:

• Will the local echoing violate the rule, that the pty output is solely responsible for what gets shown? Here you will have to implement a backtracking of what was inserted ahead-of-time and possibly has to be removed again, if the pty output does not match.
• Closely track termios changes - If termios is set to raw mode, local echoing should be switched off in any case, as the process might have a completely different idea of what to make out of the input. Thats how most cmdline editors operate and provide changes to the screen by just one keystroke. If ECHO is switched of in termios settings, local echoing should never apply (often used for password inputs). There are more intermediate modes to be considered, see termios manpage.
• Implement termios char replacements. Depending on the active termios settings the tty might do several character replacements like '\r' -> '\r\n'. Example - Enter will trigger '\r' to be sent, but the pty will echo back '\r\n', if ICRNL and ONLCR is set (default in ICANON mode).
• Do not implement local echo with direct access to terminal internals (like direct buffer access, cursor manipulations triggered from custom key listeners). This will most likely lead to desync artefacts. Instead rely on on data from the terminal (onData event) and data from the pty to do the backtracking. If a state change of the terminal is needed, use sequences (thats important to stay in sync with the band data, as the whole pty-->term communication is stream based). You can find an updated version of the supported sequences on CI server (not yet merged into public, the wiki document will be deleted soon).

I think mosh implements local echoing and pty decoupling to a very good degree, might be worth looking at it.