[Enhancement] Expose terminal cursor

[Garek33]

I propose the following additions (and would be willing to implement them after christmas):

• Expose the terminal cursor as additional suffixes of terminal
  • cursorcol
  • get returns ScreenBuffer.CursorColumn
  • set calls ScreenBuffer.MoveCursor(ScreenBuffer.CursorRow, arg)
  • cursorrow
  • get returns ScreenBuffer.CursorRow
  • set calls ScreenBuffer.MoveCursor(arg, ScreenBuffer.CursorColumn)
• Create a way to print a string at the current cursor, moving the cursor, but without the newline appended by print
  • How about put? Traditionally, that would only output a character, but kOS doesn't differentiate between the two anyway
  • Even if this becomes a suffix of terminal, I'm against calling it print to avoid confusion.
  • as a builtin or as a suffix for terminal?
  • a builtin would fit with print and print at being builtins
  • a suffix for terminal would avoid increasing the number of builtins potentially colliding with user identifiers. I could create println and printat suffixes as well to keep consistency (keeping the print builtins obviously, because we don't want to break everything)

This would enable user build prompts to play nice with regular print output. Also, this would enable a user to work around problems like #1007. On a personal note, I want to get into kOS plugin development, and these additions would be useful for a kerboscript project of mine.

(Why not build a script-side screenbuffer using print at for output? Because then any script that wants to print output needs to know and use that because regular print would mangle it. And I'm trying to limit interdependencies like that.)

[MaraRinn]

For more advanced UI needs, there's always the option of creating a GUI where you can control the layout to some degree.

[Garek33]

The Point is, I'm not talking about something that advanced. In basicly every other language, one can use the standard output (i.e. print) for, well output, and the standard input (i.e. terminal:input) for prompts and everyhing just works. And while I'm okay with needing to implement the actual prompt with echoing user input etc. in kerboscript, one currently needs to use print at for that, which doesn't play nice with other scripts/functions that don't need to know anything about user input, but still want to print some stuff.

I mean, yeah, a workaround would be implementing the prompts in a GUI Textfield (although, can textfields span multiple lines? The documentation doesn't mention, and I don't have access to KSP right now) and leaving the regular terminal window to print output, but then, what's the harm in me adding those suffixes to KOS?

[MaraRinn]

Yeah, GUI is a bit of overkill when you just want some simple interaction :D

[Dunbaratu]

Tomorrow I'd like to put in some time to kOS so I'll check how hard this is. IT may be simple.

[Garek33]

I don't want to step on anybodys toes, but I'm kind of already working on this. See https://github.com/Garek33/KOS/tree/dev-2394.

I was implementing put, but now I'm debugging a problem where Shared.Screen.CursorColShow seems to always return 0, even if the internal field is set correctly. Any hints about that would be welcome? EDIT: So the ScreenBuffer used by the terminal is actually a TextEditor, which reuses CursorColumnShow. My current solution is changing TextEditor.CursorColumnShow.get to CursorColumn + cursorColumnBuffer. That works besides two minor inconveniences:

• setting cursorcolumn in the interpreter offsets the cursor on the next input, but not the text, until you press enter, then the text of that line is offset.
• if a script leaves with a non-zero value of cursorcolumn, the Program ended is offset by that.

But that's a similar level of wierd to the effects one can get with print at, so I'm inclined to leave that for the moment.

By the way, any opinion about put as a suffix of terminal vs an additional builtin?