Support for ANSI special chars

[gidim]

Standard terminal windows support special ANSI chars for styling.
For example try running this on any terminal window:

printf '%b\n' 'It is \033[31mnot\033[39m intelligent to use \033[32mhardcoded ANSI\033[39m codes!'

Can we add support for this?

[ayesc9000]

You should not use ANSI in web browsers. ANSI is a windows proprietary format (Unless we're talking about the ISO 8859-1 standard) and you should instead use Unicode. Unicode has the same characters and more and pretty much every device supports it fully nowadays.

[commanddotcom]

Actually ANSI is a common thing for terminal applications and it would be nice to have it.

[ayesc9000]

That is true but again, compatibility could be a little weird...

[normai]

I don't understand. We work in browsers, they speak UTF-8. What did I miss? What are ANSI special chars?

@gidim I wonder what the purpose may be to issue commands like in your initial post. And that example perfectly fits into UTF-8 anyway.

[commanddotcom]

@normai ANSI is widely used by native terminal applications to decorate prompt output (font weight and color). If TerminalJS will be used as a front-end with real terminal in the back-end then ANSI support might be required.

[normai]

@commanddotcom Please apologize my ignorance, I still cannot see the point.

Any 'real terminal' will not access TerminalJS directly, but through some intermediate layer like a XHR/PHP backend. It is the job of this backend to translate characters between ANSI and UTF-8. It should not be so difficult.

A different question is, whether TerminalJS shall obey to such control characters and do formatting or otherwise change behaviour. Is it this, what you are talking about?

Oh, after inspecting your link decorate prompt output, I think,: yes, you are talking about TerminalJS behaviour, not about an encoding problem. Isn't it?

[commanddotcom]

I think you're missing the point here: I'm not talking about ANSI to UTF-8. I'm talking about ANSI escape codes to HTML. And that sounds like a job for front-end to me.

[normai]

Yes. After a quick view into www.lihaoyi.com/post/BuildyourownCommandLinewithANSIescapecodes.html
I had the following idea to speculate.

First I would like to make the cursor navigation and backspace solid, so the arrow keys navigate the blinking cursor everywhere, possibly also up into the history lines, possibly also making the clipboard function. And the cursor should operate in overwrite and insert mode.

If that works, I will attempt to put ANSI escape sequence features on top, e.g. change colors. I think this order of implementation is advisible, because mastering the cursor position seems a very basic feature to me, which must work before anything else is can be set on top without causing chaos.

What I am not clear about, is the load feature from Lihaoyi's article, because that works with multiple independend loading bars at the same time. What shall those load e.g.? Perhaps 'progress bar' were a more neutral word, meaning just any background process.

BTW. For loading bars, a look back into MarkIvanowich's PR#2 might be interesting, because he already has realized such loading bar or 'pylon'.

This are only thoughts. I have no time to touch anything for the next weeks or month.

[ayesc9000]

Yes. After a quick view into www.lihaoyi.com/post/BuildyourownCommandLinewithANSIescapecodes.html
I had the following idea to speculate.

First I would like to make the cursor navigation and backspace solid, so the arrow keys navigate the blinking cursor everywhere, possibly also up into the history lines, possibly also making the clipboard function. And the cursor should operate in overwrite and insert mode.

If that works, I will attempt to put ANSI escape sequence features on top, e.g. change colors. I think this order of implementation is advisible, because mastering the cursor position seems a very basic feature to me, which must work before anything else is can be set on top without causing chaos.

What I am not clear about, is the load feature from Lihaoyi's article, because that works with multiple independend loading bars at the same time. What shall those load e.g.? Perhaps 'progress bar' were a more neutral word, meaning just any background process.

BTW. For loading bars, a look back into MarkIvanowich's PR#2 might be interesting, because he already has realized such loading bar or 'pylon'.

This are only thoughts. I have no time to touch anything for the next weeks or month.

If you want to do this, then go ham. But do note that Terminal.JS is meant to be a simple pseudo-terminal in your browser. If you want to make the cursor move around and have the ability to do other cool text things, then you will basically be rewriting Terminal.JS at that point. The way it's currently made basically makes it really hard or even near impossible to just "add" these features. Again, if you want to take on this challenge, then be my guest. But it would be more logical to make a new library from scratch at that point.

[normai]

If you want to do this, then go ham

;-))))) I said, this are thoughts to speculate. Nevertheless, I would not have written it, if I hadn't some faint suspicion how to realize it.

meant to be a simple pseudo-terminal

Simple, yes. But for whom? I say: For the users — not necessarily for the programmers. And who said 'pseudo'?

currently made basically makes it really hard or even near impossible to just "add" these features

I think the core design as provided by Eric and continued by Yevgen is a powerful seed, which will tolerate quite some extensions.

if you want to take on this challenge, then be my guest

Thank you. Have a look at my fork.

Please remember: I go slooow, will be inactive the next weeks or month.

[ayesc9000]

Simple, yes. But for whom? I say: For the users — not necessarily for the programmers. And who said 'pseudo'?

That was the goal for both sides as stated on the website (when it was still online)

I think the core design as provided by Eric and continued by Yevgen is a powerful seed, which will tolerate quite some extensions.

I need to get better at wording things right. The core design is pretty good, yes. But for something like a moving cursor, that could be problematic since the terminal simply adds text to a div. Trying to move text precisely inside of a div especially the way you want to would probably yield a redesign of how the terminal creates text on the webpage. Maybe rendering to a Canvas instead?

[normai]

That was the goal for both sides as stated on the website (when it was still online)

Maybe. But that is not carved in stone. At least not for a fork.

Maybe rendering to a Canvas instead?

Probably not. A canvas is graphical, dealing with coordinates for size measurement. Here, simple character counting coordinates are wanted. Perhaps a pre might be good. But I think the divs are fine, they are stacked like in an array, you can go up and down that stack. Perhaps they need some index added or so, for convenience.

I suspect more complicated will be the horizontal counting, when the strings may contain e.g. spans for color changing or so.

[ayesc9000]

Probably not. A canvas is graphical, dealing with coordinates for size measurement. Here, simple character counting coordinates are wanted. Perhaps a pre might be good. But I think the divs are fine, they are stacked like in an array, you can go up and down that stack. Perhaps they need some index added or so, for convenience.

I suspect more complicated will be the horizontal counting, when the strings may contain e.g. spans for color changing or so.

Yea a list of tracked divs might work. As long as you are using a monospace font that could work.

[normai]

monospace

The font does not matter when counting characters by string functions.

Going up/down, with non-monospace would be a bit zigzag. Only to smoothen that you would need to calculate character width. That would be nasty, that is the reason, why monospace would be preferrable.