![]() Maybe there's no killer feature in this one to justify the extra weight, but neither do I see the need to pile hate on it because JavaScript even less because they had a bad experience in school writing a JavaScript project that was similar. But I love to see people innovating providing extendable architecture is the way we get great new features. I'm not really disagreeing with you about the terminal: Honestly I will keep my lighter terminal with tabs and good UI for most real uses. What salient points do you actually refer to? His other points were that, in the past, he had written a JavaScript terminal as a school project that he ended up hating, it took him thousands of lines of code, and he'd done it before Node existed to provide the batteries. It is not a "salient point," but simple JavaScript hate. The latter quote is from the comment I was replying to. >without having to write any JavaScript, which is its own achievement. >It's not hate when people bring up salient points. The CSS/HTML part can potentially provide interesting options as well. Point is to use them to do other cool things client-side. See the demo animation for a (silly yet awesome) example. >Standardised plugins: what standardised plugins? npm modules? Not sure what you mean here. C? Because C is secure by design? Ĭoding a terminal in Rust or even Go would be awesome, I admit. >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 |