tomek-szczesny / notcurses-vt-proto Goto Github PK

Stuff that seems to be so obscure that FOR NOW I don't bother implementing that.

// \e(B                 // G0 character set -> USASCII 
// \e[22;0;0t           // Window Manipulation (XTWINOPS)
// \e[?12l              // Start/Stop blinking cursor

Learn how to do that stuff

// \e[2d                // Line Position Absolute (Default 1)
// \e[y;xH              // Move cursor to y,x

There are more cursor moving command that need to be identified for completeness. (CSI A,B,C,D off the top of my head)

Currenly 3/4/8-bit colors are hardcoded in vt_8bpal().
Instead, most SGRs probably should be passed through notcurses possibly unchanged.

My attempts to approach the Maintainer about that didn't get any response, probably will be faster to inspect existing code.

It works for color support, but is already getting messy and inflexible.

• Some SGRs have question marks at the beginning of a parameters list
• Arguments might be empty, indicating "default value", which may be 0 or 1, depending on a function.
• As of today, arguments list is being copied to internal buffer with fixed length (ouch)

I think this should be handled very differently!

• Figure out if SGR is complete ("final byte" has been identified)
• If it is, there's no stopping us from introducing more states instead of mammoth switch {}
• Make an elegant parser that fetches consecutive numbers and symbols straight outta buffer
• Assign negative ints to special cases:
  -1 to empty (default value)
  -2 to question mark
  (may be easily expanded in the future if needed)

I don't know what to make out of Maintainer's response, and my best guess is he doesn't have anything against "widgetizing" the whole VT thing.

I need to examine the widget code, but my best bet is that this should enable much more flexibility than screwing around with state-holding structs.

This may be a good opportunity to clean up everything (yet again).

This probably should happen before implementing alternative and scrollback buffers.

And the question is can I keep it outside the library for now, or should I work on a notcurses fork and deal with conflicts every day?

// \e[2J                // Erase in display (args 0-3) 
// \e[J                 // Erase in display 0
// \e[30X               // Erase 30 characters (Default 1)
// \e[K                 // Erase in line, args 0-2 (default 0)

What happens to the cursor after performing any of the above?

Do you pretend me to work on the repo straight ? Cause I can't clone it ... let me know

xavier@xavierbcn:~$ git clone [email protected]:tomek-szczesny/notcurses-vt-proto.git
Cloning into 'notcurses-vt-proto'...
The authenticity of host 'github.com (140.82.121.3)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com,140.82.121.3' (RSA) to the list of known hosts.
[email protected]: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

This is probably of the least concern right now, but would be handy to implement that as well. (Not a mandatory feature of a terminal after all). Also, how the hell a user is supposed to interact with it?

But even if, should Alternative buffer have scrollback capability as well?

dankamongmen/notcurses#1893 (reply in thread)

// \e[?7h // Auto wrap mode (DECAWM)

Again, what the fuck is the meaning of this? Isn't auto wrap the default behavior of all terminals?
Huh, maybe it's not.

// \e]0; ... \007 // ESC ] = OSC, terminated with BEL (0x07) or ST (0x1b \), or nothing

As far as I can tell, although OSC offers near infinite flexibility, this thing is mainly used for setting a window title in xterm.

I don't even know where to begin. What is all this shit?
(This topic is dedicated to discussing sequences with unclear meaning)

// \e=                  // Application Keypad (DECKPAM)
// \e[?1h               // Application cursor keys (DECCKM)
// \e[?1l               // Normal Cursor Keys

// \e[4h                // Set Mode (12 = Send/Receive; 20 = automatic newline; 4 = insert mode; +1)
// \e[4l                // Reset Mode (2 = Keyboard Action Mode, 4 = Replace mode; +2)

What the fuck are those all about?
Surely, this adds 4 bits to VT context, but what exactly do they all do?
Is really Insert mode a thing? Come ooon...

// \e[?1000h            // Send Mouse X & Y on button press and release. This is the X11 xterm mouse protocol.
// \e[?1000l            // Don't send...

So my understanding is that if the "Send..." sequence has been sent, a terminal will respond with mouse presses to the application.
Okay then, yet another context bit, and probably a callback function on each button press, I think?

@chromafunk, abort the mission. This thing already exists, is just not documented properly yet :D
ncplane_set_fg_palindex(n, 2)

The 256-color (8-bit) mode is still necessary though.