Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dual Input & Output terminals #829

Open
eniv opened this issue Jan 21, 2021 · 4 comments
Open

Dual Input & Output terminals #829

eniv opened this issue Jan 21, 2021 · 4 comments
Labels
feature request Requested feature

Comments

@eniv
Copy link

eniv commented Jan 21, 2021

Hi,
This terminal is great.
I'm using a combination of two terminals one is in locked mode, sized for a single line and used as input, while the other one is read only and used as an output.
Something on the line of this (copied from vscode terminal):
image

And using react-console-emulator:
image

  • The single line height with lock enabled for the input terminal, sort of works, with the caveat that the scrollbar will appear after the first command (as seen in the screenshot above), and the prompt will shift up a bit.

  • I often used pushToStdOut for the output terminal when a command is invoked from the input terminal. It would be great if this function allowed to control the color of the content that is being pushed, so I can color the command echo and the result differently.

  • Also, it would be great if there was a catch all command, which could be used to display an invalid command message to the output terminal.

@linuswillner
Copy link
Owner

Hi,

  1. It appears you're printing from the top in the way that some terminal applications seem to be doing. I'll have to be honest in saying that I have absolutely no idea of how they do this, and haven't the slightest clue how I could emulate this behaviour.
  2. This is going to be very tricky to do in the library's current state, considering that the stdout logic has no bearing on styling - the styling is applied at render time. I'm feeling like, if I implemented per-message/message-defined colour support, I might as well just implement support for the actual syntax used for terminal colouring 😄 which actually is something that I think would be a good idea to implement. I'll look into that.
  3. This was also requested in Possibility of catch all command? #790. It's on my to-do list, although I'm a bit strapped for time to develop this library at present. I'll get there eventually though, I'm sure!

@eniv
Copy link
Author

eniv commented Jan 21, 2021

Thanks for your comments Linus!
For your first comment, is it challenging to auto scroll to the bottom (for the output terminal)?

@linuswillner
Copy link
Owner

linuswillner commented Jan 22, 2021

You mean auto-scroll when a new line is pushed to the terminal? Because automatic scrolling is already implemented for when a command is entered by the user (in order to accurately mimic a real-world terminal).

@eniv
Copy link
Author

eniv commented Jan 22, 2021

Yes, I actually found out that you have a scrollToBottom method which I can call on the reference. So I'm using the command callbacks of the bottom, one line, input terminal to inject content using pushToStdout to the top, read-only, terminal and then I scroll it to the bottom. This works great. I can even clear the top, output terminal, using the clear command that the reference exposes.
I also found out that I can make the small scrollbar on the input terminal disappear if I override the overflow attribute of the content in the styling to hidden.
I guess that what I'm trying to say is that the only thing missing for this two terminal solution to behave like a true dual input output terminal is the catch all callback. Since it could be used to inject an error message to the output terminal, once the input is invalid, where as now an invalid command simply provides no feedback to the user.
The syntax styling of pushToStdout (mentioned in the 2nd item above) will be a nice enhancement since you could color error messages red for example.

@linuswillner linuswillner added the feature request Requested feature label Feb 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Requested feature
Projects
None yet
Development

No branches or pull requests

2 participants