Comment by tatterdemalion | Hacker News Reader

Comment by tatterdemalion | Hacker News Reader

Parent Full thread

The problem seems to be that they come at things from the wrong direction - you can't run vim without being backwards compatible with at minimum terminfo pages, very likely vim also makes an assumption also that the terminal communicates over a tty, and possibly you may just need to support actual ANSI Escape Codes. You can't run anything else without that either. Running vim should be the first thing this terminal can do.

Just like the web itself, any new teminal client needs to be backwards compatible with the capabilities of prior terminal clients, because programs that run in the terminal expect it. And if your terminal can't run the programs everyone runs in their terminals, no one will adopt your terminal. But many of these projects seem to have no intention of maintaining that backward compatibility. Some, like TermKit, fully conflate the terminal and the shell and even many UNIX utilities.

You can't hope to supplant ANSI compatible terminals when you let them have the enormous advantage of running all the software anyone wants to run in a terminal that already exists. It would be like saying you have a new, better web browser that can't open any existing web pages.

No idea if this particular project has learned from past examples and is backwards compatible or not. (EDIT: It doesn't have a terminfo page, so probably not.)

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.

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.

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.

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.

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

Reply on news.ycombinator.com