>Firstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator. Just because the web platform is open and everybody is using it right now doesn't mean that it's perfect or above criticism. Javascript hate: It's not hate when people bring up salient points. Standardised plugins: what standardised plugins? npm modules? Not sure what you mean here.Ĭan't open web pages locally: Why should a terminal do that? As a party trick? I don't want to stand in the way of improvement, here, but I also have no problem opening a separate web browser to browse the web. I sure as hell don't want random unaudited code running in the same application that I use to administer systems. In my opinion, it doesn't, and this circles back around to the fact that a terminal needs to be secure. npm has tons of redundant or ill-maintained packages, and that's even before we discuss whether having a bunch of available packages makes a terminal better at all. Blitting characters to the screen is easy, and platform independence certainly isn't worth 123mb of overhead.Ģ50k+ Node modules: The number of packages in a package repository is a poor metric for determining anything except the number of packages in the package repository. Supporting exactly one OS: again, the OS specific bits aren't the hard part. I would first like to point out that the HyperTerm OSX zip is 43mb, and the unzipped HyperTerm.app is 123mb. The hard part isn't drawing characters to the screen (which is what HTML and CSS would help with), it's the VT100 parsing and logic, which can be written in.well, anything, really. Hey, I have a few issues with your attitude.įirstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator. How do terminal emulators on tablets handle keyboard input? Do any of them offer guided hints? But it'd still need information about the underlying environment (easy if local, hard if remote). I could see this being pulled into the terminal, rather than the shell itself. This'd be equivalent to the hints on many mobile OS keyboards. And you'd want to collect the users history to customize it. Might be able to grab these from man/info pages, but formatting is likely inconsistent. You'd want usage statistics on common commands, and you'd need to assemble a database of command line options. Others are showing other matches of the currently typed value + one letter. `cat` first because of frequency of use (in general) and recent use. ![]() This could be wrapped up in the terminal, but needs to be aware of the environment in which it's being executed which moves beyond the purview of most terminal emulators and into the area of the shell itself. This would be filled in based off of common usage, and knowledge of binaries avialable in the path, knowledge of the command line arguments of common tools (git-prompt.sh is really nice for getting my new-to-git coworkers started, for instance). Use the model of something like is common with a lot of MUD clients, all text input occurs in a field at the bottom (look at tinyfugue).īelow that have a set of autocomplete hints. Something like what Reason does for OCaml, but done for the the unix command line. A teaching shell might be more important.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |