We can also just ignore x/term for the purposes of #11811.

How about moving https://godoc.org/golang.org/x/crypto/ssh/terminal#IsTerminal here?

@davecheney are you sure about CL number, 17611 is about compress/bzip2 - https://go-review.googlesource.com/#/c/17611

Submitted https://go-review.googlesource.com/c/38050/ and can work on #19503

@techtonik the CL you linked above got some reviews, but it seems like you didn't reply. Are you still interested in continuing work here?

I'm interested in this subrepo, so I can help with reviews and some of the work. It would be good for someone who's paid full-time to work on Go to take ownership, but if noone steps up, I can take that job with the free time I can find.

Out of curiosity, who is interested and/or would like to spend time on this subrepo in the future?

@mvdan thanks for the heads up. I've lost control over my emails and missed the notification. Looking at the CL right now.

No paid job and no expertise from my side, so don't expect me to take the responsibility. Since I wrote this code, some things happen. I lost hope in the terminal model with single input stream and single output stream. Not sure it is extensible. In Windows it was called console or cmd window and it was able to process text events much faster, because it didn't require parsing event stream from stream symbols and then converting the output the same way through complicated state machine into onscreen text. It was almost as simple as DOS video memory buffers in text mode, and thanks to that real-time TUI (text user interface) applications were much more responsive.

I am a very fan boy of https://www.farmanager.com/ but over two years I am completely on Linux and don't use Far anymore. In Linux TUI applications I can not chain key presses and go grab some coffee until all commands that spawned by keypresses finish execution. TUI interfaces based of parsing and visualizing every character instead of directly manipulating with the video buffer are very very slow. No OpenGL or Vulcan would fix that. I can not save events buffer before starting another process and restore it later, I can not use memory copy operations for showing animations in text mode with 100 FPS on 200x100 character matrix. It will be too slow.

Unfortunately, I don't have a link to a list of all problems with terminal model that is being the core of every and each terminal emulator. There are too many modes in these terminal emulator, options and cryptic keyboard shortcuts that just block user output. with no feedback. Still I really liked plugging just two wires into RaspberryPi and getting access to system console. It when I realized why it is so easy to connect to other Linux over the network or any other connection where you stdin and stdout. But as a former hardcore TUI user who believes in UX power of mouseless and blind interfaces over the GUI, I would say that terminal model is not perspective. Moreover, I think it is evil as it is giving so much hard time to new Linux users. Of course, over the time you learn it, but for now I am not sure that x/term module is able to fulfill the potential that TUI tools can bring to users.

For me, the terminal model is a serial console and I would investigate projects like https://mosh.org/ who can potentially reinvent it to something more useful.

EDIT: Making a good TUI module for golang would require changes on Linux level. I am afraid it is out of scope of this project, and there is no mechanism to go deeper. I also tried to find people who still know how deep is that terminal and how it works, and I don't believe that they are still alive. I spent 10 years until by a chance I discovered the concept of controlling terminal, and I am also getting old. My dream of having a fast responsive TUI in Linux would not come true, and Go can not change that. It can provide a really good interfaces to system level, but if the system level design is not quite right for the use case, I don't think it can be fixed with Go.

@techtonik thanks - it's fine if you've lost interest or don't have the time. I think the rest is a bit off-topic :) If you're not going to work on your CL, please abandon it.

I'll see if I can get this rolling again with others in the next couple of months. If that fails, I think we should remove the repository for the time being, as Dave suggested.

I still couldn't find an way to checkout my CL locally from Gerrit. Started editing it online, but then I can not run tests. Well, at least the fixes are just comments.

@mvdan updated online - https://go-review.googlesource.com/c/term/+/38050

CC @dmitshur @toothrot

Ironically, the term repo currently has a test flake on the android-amd64-emu builder:
https://build.golang.org/log/f3ca1fcb2170a38216ffbafb598bbc008616aac8

(Doubly-ironic, given that the repo has no code and that the Android platform has no terminal.)

/cc @matloob

Another package that cound be useful for x/term is https://github.com/yakshaveinc/go-keycodes - common agreement which numbers to assign to which keys in keyboard where is necessary to operate on keys rather than chars, such as in games.

I am not sure that x/term is a good name for it. Terminal is the most popular input/output interface, but not the best architecture with single stdin+stdout pair and many hacks on top of it. Now for keypresses for sure.

Closing in favor of #31044. The repo is not empty anymore anyway, so can't be removed. Adding things should be tracked in independent proposals.