Ability to move the cursor in exec session
robinovitch61 opened this issue · comments
Dang, this is harder than I thought without implementing an actual terminal emulator...if I use a textinput component I can't trust the session's cursor position will always stay in sync with the textinput's cursor position as some shell session's don't support e.g. alt <-.
I'll have to handle the returned sequences and translate them to pseudo prompt positions on the last line of the viewport.
Isn't this the point of using Charm's tools? I'm only vaguely familiar with them but do they really not offer a solution to this?
Something you could do short-term is write-up a guide for using Wander via screen/tmux which would at least let you do things like highlight stuff for copy/pasting.
Isn't this the point of using Charm's tools? I'm only vaguely familiar with them but do they really not offer a solution to this?
Yes, charm provides the textinput bubble, which is used in wander for the command prompt pre-exec session and the save dialog. I could also use it for the filter input, but don't use it there yet. There's also a cool new textarea bubble for multiline editable text.
The issue I'm facing is that the nomad websocket api I'm using for the exec session works well when the response messages are parsed by something like xterm.js, which is what the nomad web api uses - a terminal emulator that translates everything from plain characters to ansii escape codes into an interactive view that resembles a terminal.
I haven't yet figured out terminal emulation with existing tools in go - I'm willing to bet it's very possible, but haven't cracked the code yet.
In addition, rather than an emulated terminal exactly, what I'd like to do in order to have the terminal output scrollable, wrap-toggleable, and saveable the same way as any view in wander, I'd like to "render" the "view" of an emulated terminal to the viewport, which is the subcomponent that enables scrolling, wrapping, and saving.
There's a modal nature to the exec session right now where if you're fully in the exec session, all keyboard input is forwarded to the websocket connection, the response is parsed and appended to the viewport. If you hit escape once, you enter the viewport interactive mode, such that you can scroll, wrap, and save the session's content. If you hit enter again, you re-enter the interactive exec session.
SO long story short, what I've done for that "parse the response" bit is a bit janky - strip away all ansii escape codes and the like and append the remaining plaintext to the viewport with a "pseudo prompt", i.e. a colored single space " ", to the end of it.
I think I can do something where instead, the last line of the viewport is a textinput, that would make it appear as if the cursor is moving as expected on screen. Where I have to be careful is to make sure that cursor movement also gets sent through the websocket and that the position of the cursor in the textinput is the same as the interpretation of the position of the cursor server-side such that there's never any behavior where you press enter and the command you see that you've edited isn't the same command that the server thinks has been entered. That's what this comment above tries to say in brief.
I think there's a way I can fake this whole thing or ensure that they are always in sync, but I'll have to play around with it a lot. Ideally I figure out how to use a proper terminal emulator and extract the view from it to put in a viewport so that I don't have to continue to implement a "barely good enough" terminal emulator myself :P. If anyone gets something working here, that would be great!
Something you could do short-term is write-up a guide for using Wander via screen/tmux which would at least let you do things like highlight stuff for copy/pasting.
I do use wander via tmux and copy/paste things sometimes with it, but don't think that I should recommend any specific terminal environments for folks to use wander in. Most terminals already support copy/pasting selected text out of the box. The reason all views in wander are left-aligned without a border is for copy/paste ease, and the reason every viewport is saveable is so that folks don't need to e.g. zoom out a ton until the whole viewport is rendered on screen and then copy paste through mouse selection/tmux/screen.
Long winding rant! Hopefully it illuminates some of the challenges I'm facing today with the way I've initially implemented this, and why this issue will be harder than I initially hoped :)
Closing in favor of #107