Input vs. Output

[datenreisender]

I am confused by what is considered “input” and what is “output” in this project.

My first idea was: All what users enter is the input (e.g. with a shell that could be ls) and all what the terminal displays back is the output (for ls that could be the list of files).

But it seems that is only partially true: In NrfTerminalCommander.ts there are functions clearInput and replaceInputWith which do fit my understanding. But contrary to my understanding, the getter output actually returns the current user input and likewise when I use registerOutputListener the registered callback is not invoked on every terminal output but instead on every change to the input to the terminal.

So, I assume either the naming is strange or I do not get it yet: What is meant by input and output? What is the difference between the two?

[deerob4]

Throughout the library, output refers to the line or command that's currently being written, and that will be processed when <enter> is pressed. This could either be a series of characters typed in directly by the user, or a string set programmatically, as the HistoryAddon does. The output is then cleared whenever the current line or command is run.

It makes sense if you think of the terminal as a kind of typewriter, where the user's input causes an output to be written to the screen. That's the mental model promoted by XTerm.js, so that's what made the most sense when I was writing the character handling functionality.

In the case of the clearInput and replaceInputWith functions, they should be renamed to output if they're to correctly follow the naming scheme. Probably I was going back and forth between the two names and forgot to update those.

I can definitely see how it would be unintuitive if you're not thinking from that perspective though, so feel free to write a PR renaming it to input or something if you feel that's a better choice.

[datenreisender]

I probably would have been less confused if output would really contain all of the output of the terminal (e.g. in the case of a terminal also the the responses the modem sends back) but obviously that is not the intention of the output concept here.

This project is still considered so much in flux, that I can rename anything without having to consider keeping things compatible, right?

I know that the intention of this project is to use it also in the VS code project. Is this already done somewhere, so I can see whether some changes in concepts might lead to major troubles there?

[deerob4]

Yes, please feel free to refactor however you see fit!

We will be integrating it with the VS Code extension, but that's not the focus for at least the next few sprints. So no need to worry about breaking things there. The only two constraints are that:

1. The library should be loadable through the XTerm.js loadAddon method.

2. Any additional DOM elements that need to be drawn should be created using the browser's DOM API, not with a library like React. That's a pretty heavy dependency to pull into VS Code, and I'd prefer this library be as light as possible.

[datenreisender]

Will do. Thanks for the answers.