[shockone]

It does indeed support ANSI codes. Not fully compatible with VT100 yet, but that's where I'm moving. Vim is functioning, but there are a lot of bugs. https://dl.dropboxusercontent.com/spa/dlqheu39w0arg9q/xxy316...

The problem with terminfo is that not every tool relies on it. I've seen many examples (hello, exa), when the codes are hard-coded to operate with xterm-256. So, I decided to pretend to be an xterm.

[tatterdemalion]

Hey thanks for replying & I hope my comments didn't seem snooty. I've thought a lot about how to solve this problem and was disappointed by the way some past attempts have just ignored the infrastructure that ensconses current terminals. And its a real shame that so many tools just hard-emit ANSI escape codes - there are even some TUI frameworks that do it.

The problem I see is that you seem to have the terminal doing things like fuzzy matching input against PATH executables. But that's the shell's domain. The terminal should just expose commands for adding text items to a drop down under the cursor, and the shell should send the matches to the terminal. And capabilities like this should be clearly defined in a terminfo page (which you should definitely have, even if for non-custom capabilities it uses the same definitions as xterm), so that well-written apps can send this information if and only if those capabilities are defined.

Of course this is a huge challenge, because if you do it this way your terminal doesn't do anything new until someone writes a program to run in it using its extended capabilities. So this creates a chicken and egg problem. But you can't come up with nearly as many interesting things for your terminal to do with cursor dropdowns as everyone in the world can if you're just exposing that in the same way the character grid is exposed.

[shockone]

Hey. Not snooty at all. I understand your pain: once I tried to open Vim in this Kickstarter terminal project - Xiki - and was disappointed in the same way.

Perhaps unexpectedly, Black Screen is both a terminal emulator and a shell. I tried hard to avoid going with writing a shell, but the existing ones simply don't fit. It's even hard to know when a child execution has finished. And I want smart autocompletion, so I have to at least extend a shell.

Traditionally these two are separated, and it must be a good design, but my current goal is to prove the concept. Perhaps, later I'll extract the shell.

[tatterdemalion]

I think for this to work you just have to create a shell and a terminal, to have a killer app that your terminal is the paltform for (realizing this is what kept me from ever moving on the idea). But my point is that I think the shell component absolutely must communicate with the terminal component over the tty subsystem using an extension of ANSI Escape Codes, defined in a terminfo page, so that the terminal component is only concerned with how the information is displayed, and not what the information is.

[shockone]

What problems will I face if they don't communicate over a TTY?