Better ingame Text Editor

[MunWolf]

I think the text editor sorely needs some better features, here is a list.

• Tabs (maybe?)
• Smart Indenting, aka the editor keeps the indent from the old line, could even add an indent if the line ends with a {.
• Auto-Complete (ok I guess this is a stretch, but would be nice)

I have been trying to implement some of this but I cant figure out where the logic behind the editor is :/

[Dunbaratu]

It's here: https://github.com/KSP-KOS/KOS/blob/develop/src/kOS/Screen/KOSTextEditPopup.cs

After I added telnet I sort of regained interest in the idea of the in-terminal editor instead of the popup, because the popup makes a schism between the telnet experience and the gui experience. But just the work involved is.. ugh too much effort when thee's better low-hanging fruit for me to aim for first.

[MunWolf]

So lets say I would try to implement a version of this, would you like me to use that Popup or do something else?

[erendrake]

@WolfGaming I think @Dunbaratu is saying he would like to revisit the editor interaction. I agree with him that having the extra popup window worked well until we added telnet.

So the Way i would like to see this go down is that we re-integrate the editor back into the main terminal and add these extra features there. Doing so in a way that allows telnet users to still have access to the feature.

[MunWolf]

ok sounds good I'll have a look at it if you haven't started it when I finish my finals.

[Dunbaratu]

I know that there's a plethora of freely available source code for text editors that operate on fixed-character-cell terminals in the unix world: vi, emacs, pico, etc. And a lot of it is GPL so having it in our project would mesh well, legally-speaking. I had once entertained the fantasy of connecting one of them to the terminal, but ran into three major blockages to that idea:

1 - They're not written in C#. They're mostly in ISO C (except for Emacs, which is weirdly in Lisp), so adding any of them to the codebase may be a challenge and would require writing some "bridges" between them and the C# code. 2 - I have no clue how to integrate them into Unity's callback system, since they're all basically written to assume they are "in charge" of the process, with their own main() function. 3 - The terminal is weird and doesn't quite operate like a real terminal with escape sequences.

Now with the telnet overhaul, It would be possible to fix 3 by basically using the telnet system's vt100-to-"unicode term" mapper, and I think I know how I'd fix 2, maybe, by running the editor code in a separate thread and talking back and forth to it like I do with the telnet server.

But I still don't know how to deal with bullet point 1. That's a nasty one since KSP, although it allows threads as long as you insulate them really well from Unity's API, doesn't allow the spawning of full blown separate processes, so I can't just run the non-C# code in a separate executable and redirect input/output to it.

So, basically, I think we are still stuck with having to have our own homebrew editor, even though borrowing one of the classic ones would give us a LOT of nice functionality. So to that end, trying to resurrect the old editor code might be the way to go.

Just so you know, the infrastructure is like so:

• There is a class called ScreenBuffer. It has the frame buffer of a terminal.
• There is a class called SubBuffer. It holds a smaller frame buffer meant to be overlaid atop a Screen. The Screen is built by layering all its ScreenBuffers atop each other.
• There is a class called TextEditor. It is derived from SubBuffer. It's a kind of Subbuffer that has some logic built in to do a bit of editing with arrow keys and the like.
• There is a class called Interpreter. It is derived from TextEditor. It's a kind of text editor that only lets you edit one line at a time. It's what the terminal uses to let you edit your command-line.

Re-enabling the in-terminal text editor would basically mean subclassing TextEditor into a variant that deals with a subBuffer filling the terminal, and maybe implementing some more arrow keys for up/down page up/pagedown and ctrl-C,ctrl-V etc.

The original code from Nivekk did this with a TextEditor SubBuffer that filled all but the topmost and bottommost lines of the screen, to hold the file content, and used the topmost and bottommost lines as additional sub buffers that held the status lines for the text editor.

Marianioapp is the one who originally removed that code as part of his major overhaul, saying he couldn't get it to work and it was clunky and he figured nobody was using it anyway. It's never been back since then. I think, given the age of the code and how much we've fiddled with the terminal system since then, that it would probably be easier to just re-write a similar solution again from scratch than to try to find and re-use that very old code. A lot of what you need is already there in the TextEditor derived class of SubBuffer.

[MunWolf]

Yeah that code was what was making it so hard to find the currently used code, I'll figure something out.