How well does it deal with copious amounts of text scrolling across the screen. It's been a while since I've used it, but IIRC Gnome Terminal had big issues with this for a long time (due to the underlying library that they were using).
A terminal emulator is not a shell. Using bash has nothing to do with the decision whether you use the OS X Terminal or some third party terminal emulator.
I would not recommend iTerm2 to a beginner. The iTerm developers believe in the kitchen sink approach to preferences, which is not very beginner-friendly. And there's not much reason to use iTerm2 in general anyway now that Terminal.app has mouse support, I'm only aware of a few relatively esoteric features that iTerm2 has that Terminal doesn't (support for colors outside of the 256-color palette, and built-in support for showing tmux panes as iTerm window splits).
pretty sure that iTerm2 for a beginner is pretty much identical to Terminal. At that stage don't know enough to leverage it's fancy capabilities so they don't get in the way and confuse you. When you're ready for them, they're there for you. In Terminal you have something that looks and works almost identical but when you want more you can't have it.
This looks very well executed and really cool, but I'm honestly really tired of all the node/electron terminals. In its favor, this project looks a lot more clean and less opinionated than that 'Black Screen' monstrocity.
In my experience, it's very slow and clunky, but the real problem is that it attempts to impose a lot of styling and decoration _on top_ of the terminal.
For example, the command prompt isn't just a command prompt, it has this silly chevron decoration with autocomplete functionality. It can probably be turned off in the settings, but I find it to be a really annoying default. It just assumes I don't have my own prompt how I want it or my own autocorrect system.
I have to explicitly disable half the 'features' before I get anything actually useful to work with.
I use two tools daily that are built on Electron and they are great. Not only that, but it's never obvious they run on Electron. I'm curious, what do you hate so much about it?
On the one hand side people complain that Turbo Pascal and WordPerfect (or even UNIX for that matter) worked extremely fast on an 386SX with 4MB RAM and that modern software eats hundreds of megabytes of memory and seems slower, without providing much new functionality.
This attitude (replacing a lean and fast terminal, by one rendered using a web browser engine) is exactly why modern machines that are 1000x faster and with 1000x the memory still seem to be slow for basic tasks.
Of course, it's a free choice. You can waste resources by replacing small programs by browsers ;). But it's reasonable that many people find it a waste.
My iTerm process is using about 170mb of memory, though that's admittedly less than half of what Slack is using. Big picture, with 8gb of ram, this is not a problem.
I can honestly say that I have never been inconvenienced even slightly by an application that takes up between 0 and 500mb on disk.
If it starts to get into the multi-GB range it can hurt to download, but below that it's all identical to me. If it means that i don't need to run a specific version of a library installed globally on my machine, and i don't need to manage a big chain of dependencies myself, and it runs on multiple platforms, i don't care if it's 1mb or 500mb, and i don't care how many copies of it I'm running.
My ssd has 60gb remaining on it after a few years of daily use and i haven't needed to worry about program space yet.
I'm curious why there's so much node/electron negativity circulating. (Although I guess asking for positivity when it comes to electron is a bit of a stretch :P)
I think a good terminal emulator is far from trivial.
Edit: I'm not sure I do know what you mean. I agree that building trivial apps in Electron probably doesn't make sense. But my terminal emulator is something I spend most of my day using. If building that on top of 14 million lines of C++ gives me a better piece of software, I'm all for it.
Perhaps not as feature comlpete, and not my daily use terminal emulator, but it's only 110k lines of code. And it's not just a terminal emulator, that's just one thing it does in that 110k lines of code.
EDIT: I was going to look up others but I'm distracted by other obligations. My point being: Terminal Emulators aren't actually that complex.
The biggest complexity is dealing with legacy terminals... and you can really just target the handful of xterm features programs actually use and get something working without a huge amount of code.
Does it though? iTerm2 is the most feature-rich terminal I've ever used, and even then it's several orders of magnitude smaller then Electron (cloc says it's around 111K lines of Objective-C, with around 38K more lines split across Python and C++).
Maybe it's not better. That wasn't really my point though. I'm just saying that LOC is a fairly useless metric for evaluating software. Especially from an end user perspective.
I agree with you, with regards to the end user caring or not, but there aren't many tech-unsavvy people using terminal emulators on the regular. So when Putty and iTerm2 both weigh in between 100-200k LOC and this is in the 14m LOC space, it's difficult to not make the presumption that that's a lot for a terminal emulator.
> I'm just saying that LOC is a fairly useless metric for evaluating software.
That's just not true.
Most open-source people want to be able to read, audit, fix, and (if it comes to it) maintain other people's code. 14+ million lines of code make this virtually impossible. (To be fair: Electron-based apps aren't the best example for the point I'm trying to make.)
How so? It affects load time, understandability, binary size, dependency payload...
I personally hate the load times. Node apps always seem to need to think for a second or too. Sublime Text v VSCode is pretty bad. Sublime Text v Atom is even worse.
When you're moving fast and in your flow, it gets to be really annoying.
I was talking more about how it affects end users. Understandability of the code and dependencies are irrelevant in this case. Load time is important, but LOC is only a proxy for that metric. It's not totally unreasonable to imagine a well-written app with twice the code start faster than a poorly written one.
git clone git://git.suckless.org/st
cloc --quiet st
http://cloc.sourceforge.net v 1.60
T=0.09s
(45.8 files/s, 56588.2 lines/s)
------------------------------------
Language files blank comment code
------------------------------------
C 1 497 253 3654
C/C++ Header 2 40 124 313
make 1 13 2 45
------------------------------------
SUM: 4 550 379 4012
------------------------------------
[ed: Actually, this get even more extreme for the terminal I actually use everyday, sakura[1]:
apt-get source sakura
(cloc sakura)
Gives a total of 2490 lines of code, of which 2380 are C, the rest is CMake, make and Bourne Shell... that is cheating of course, as sakura uses libvte: which clocks in at ~45K lines of C - and a total of ~103K loc all together. Still a far cry from millions of lines of code...
Sure. I wasn't arguing that millions of lines of code are necessary for a terminal. Thanks for the pointer to Sakura though! I quite like it and I might have to give it a try :)
I agree, but I'd take it a step further - the 15+ million Lo(memory-unsafe!)C for the unix kernel other (all?) trivial apps sits on is also not a good thing.
For the majority of applications, I'd imagine there's a negligible performance difference. Besides, any app built on Electron will run infinitely faster than one which wasn't built at all since the developer didn't want to learn another language. I'm not saying Electron is suitable for everything, but I think it has its place.
I still question Electron for "commercial quality" apps. The Electron runtime by itself is about 100mb. I've built an internal Electron app for work and for that it's absolutely fantastic.
Using Atom or VS Code instead of Emacs cuts my battery life by a few hours. The Spotify desktop app that uses a ton of JavaScript is also horribly inefficient and has a big impact on battery life.
On top of this, chrome/chromium versus safari is another 1-2 hours of battery. I think people vastly underestimate the energy requirements of web technologies.
On the other hand, my Emacs starts up in more than thirty seconds. To fully start up it needs to read some 2k loc of my own ELisp code and hundreds of thousands loc of required libraries.
I use Emacs as a Jabber client, Python and Clojure development environments, file manager, image and pdf viewer, HTTP server, spreadsheet and note-taking app and (polyglot) Literate Programming environment. And that's just the beginning of what it can be used for.
In other words, giving Emacs as an example of small and fast, natively written application is a bit unfortunate. Not to mention most of Emacs is written in ELisp, so the "natively" part is not even factually correct.
They're slow, big, and outrageously inefficient. Most electron apps also come with this weird web influenced "I'm kinda native y'all trust me" UI design which makes it even worse. My battery and eyes simply can't stand the things.
Interesting. I haven't experienced the slowness of Electron apps. And outrageously inefficient doesn't really matter to me if it's efficient enough for me not to notice any slowdown.
But if we are going to accept the computational inefficiency, what do we gain for it?
If our only answer, collectively, as developers, is the richness of the ecosystem, then perhaps we should be moving our time and energies to make a rich ecosystem in either a language/runtime environment that performs better (C/Rust/OCaml/Whatever) or one that encourages correctness and/or speed of development.
I know some people think javascript is the latter, and I can't prove them wrong, but I suspect that is not true.
I have tried to edit a file with a little bit of long JSON that came from a server (less than 50K) and atom completely froze trying to display it.
This was two weeks ago. I've ditched Atom entirely.
But maybe we are willing to accept 50x worse performance and higher memory requirements and slower startup time because the language is nice and guarantees correctness....Well no, it is javascript, not Haskell or Lisp. So, what is the win here? Why have we collectively decided javascript is a good tool for making applications for the desktop?
No it can't. After that whole fiasco npm has made it so packages once published cannot be removed after a 24 hour window without npm manually doing it on your behalf, that is to make sure this instance never does happen again.
I can't agree more, There is no reason that editing text files would need a full web browser which is buggy and slow. Many of these javascript apps which are replacing native apps use 500mb of ram, at some point you will have 5-10 of these things churning memory and consuming battery life and cpu cycles. (Note Atom, HyperTerm, Chrome, Slack, and Kitematic is already 5 browser apps)
* We've decided to use JavaScript because the community is there. Go ahead and write an IDE in Haskell - have fun rewriting all the libraries that already exist in JavaScript and soliciting for open source contributions when a tiny fraction of all programmers can understand it.
I love Haskell and lisp, but you have to face the facts.
* TypeScript is actually a good language, and gives pretty darn good correctness guarantees.
* Your benchmark does not test against VSCode, which is much faster than Atom.
I don't think that anyone argued TypeScript is 100% sound, nor is that a meaningful goal to hit. I find TS to be a solid language that gives me reasonable confidence in my code. (The tooling is also great!)
You guys just can't stop making cool stuff can you? now.sh, now-serve, micro.. I'm not the biggest Node fan, but these are really well done. Execution on these ideas has always been 10/10.
It is outrageously silly but maybe that's the point - it carries a message that you can do whatever you want with it (and implies - without much effort, if you can do silly things like this).
There is unexplored area sitting just right there.
Imagine having easy access to ncurses replacement, jupyter kernels like output from any of your "console" tools - that would be awesome.
Edit: I'm surprised more people in the HN crowd aren't familiar with HyperTerm (Yes that is the name and what everyone called it for many many years) It was bundled with Windows up to 7, and is still used heavily in industrial control areas.
A very similar name for a product sitting in the same space (terminal emulator). That's generally an unwise decision as it can create confusion for both projects, and the one with the trademark (especially since this new one's name is a substring of the older project) is in a position to make a valid claim against the new project.
If someone created a new project called Steem to deliver video games to end users[, would you] be surprised if Valve took issue with their choice of name?
isn't it true that companies have to take issue, otherwise they lose their trademark? I used to be angry when large corporations would sue a little guy or nonprofit over name squabbles, but then I heard that the big company can lose their trademark if they dont.
HyperTerminal was commonly referred to as "HyperTerm" in the BBS community, probably because the executable was hypertrm.exe. Also possibly because most other dial-up terminal emulators had names ending in "Term".
The free version was bundled with Windows for 10+ years, and although it wasn't a particularly great terminal, its ubiquity came in handy when trying to bring new people into the bulletin board system world.
> On February 20, 2004, the developers of wxWindows announced that the project was changing its name to wxWidgets, as a result of Microsoft requesting Julian Smart to respect Microsoft's United Kingdom trademark of the term Windows. [1]
That being said, I think if MS doesn't ask them to change it, there isn't much to worry about. "wxWindows" was originally started in 1992.
IIRC, Microsoft licensed Hyperterminal from a company called Hilgraeve (sp?). It was never an official part of Windows, although IMHO it should have been.
Regardless of who owns/owned the trademarks in whatever countries, it's not appropriate to reuse the name. It will lead to unnecessary confusion. Bad call, even if no lawyers get involved.
that probably wouldn't be different enough to satisfy a trademark infringement. you could easily make a case that those are confusable, and obviously similar types of products (both terminal emulators).
That's a gross misunderstanding of the Constitution.
Some very simple searching lands you at this page, which has some helpful information about trademarks, how to pick one, and how to enforce it. Properly enforced, trademarks are a source of financial stability for entrepreneurs, and it is entirely in the realm of the US government to regulate them. http://www.uspto.gov/trademarks-getting-started/trademark-ba...
Unfortunately my current network appears to block that site. Perhaps you could paste a quote from that page that is relevant to this discussion?
The argument here is that this use is non-commercial (we are also apparently arguing about a non-respondent trademark), so the financial stability of entrepreneurs is irrelevant.
Intellectual property is still intellectual property, even if a non-profit is using it. Your argument would allow any nonprofit to use the trademarks of any business in the United States, which is clearly neither good for entrepreneurs nor legal.
If this comment isn't a troll, it's epsilon from it. We don't need to litigate the Constitution; a simple Google search for [trademark noncommercial] will suffice.
This is what I found on the front page of that Google search:
> At the same time, the statute characterizes certain activities as non-actionable “exclusions,” including “any noncommercial use of a mark.”
anyany
any
That was from the beginning text of a link on the first page of Google results for the search that you told me to make. Did you read any of the pages? Or is your comment just trolling?
For context, I was responded with:
> That's not how trademarks work.
Care to retract?
Edit: Multiple links on the front page of that search appear to validate my thesis. You have provided no corroborative evidence.
Edit2: Wow, my previous comment was flagged. Brutal. And not even a valid response could be generated.
Edit3: Another choice quote from the front page: "Non-commercial use cannot be prevented, except if that use harms the distinctiveness of the trademark."
Edit4: "The good news is that courts have consistently protected the public's right to use the trademarks of others in order to engage in criticism, commentary, news reporting and other forms of noncommercial expression." First link.
Edit5: "Many companies claim trademark infringement or dilution when pursuing unauthorized uses of their names or logos on the Web - but it's not entirely clear how these laws apply to noncommercial activity on the Net." Contradicts the "definitely" claim that I first responded to.
Edit6: Good thing my post was censored. Might not want to get these claims widely visible.
>consisting of or combining two or more separable aspects or qualities.
I recommend the Wikipedia article [0] as well. Here is a snippet:
>A portmanteau (Listeni/pɔːrtˈmæntoʊ/, /ˌpɔːrtmænˈtoʊ/; plural portmanteaus or portmanteaux /-ˈtoʊz/) or portmanteau word is a linguistic blend of words,[1] in which parts of multiple words, or their phones (sounds), and their meanings are combined into a new word.[1][2][3] The word "portmanteau" comes from the French for overcoat stand (porte manteau), where many coats may be placed on top of coats that are already on the stand, which continues to function as a coat stand.
>A portmanteau word fuses both the sounds and the meanings of its components, as in smog, coined by blending smoke and fog,[2][4] or motel, from motor and hotel.[5] In linguistics, a portmanteau is defined as a single morph that represents two or more morphemes.[6][7][8][9]
...
(3) Exclusions The following shall not be actionable as dilution by blurring or dilution by tarnishment under this subsection:
(A) Any fair use, including a nominative or descriptive fair use, or facilitation of such fair use, of a famous mark by another person other than as a designation of source for the person’s own goods or services, including use in connection with —
(i) advertising or promotion that permits consumers to compare goods or services; or
(ii) identifying and parodying, criticizing, or commenting upon the famous mark owner or the goods or services of the famous mark owner.
(B) All forms of news reporting and news commentary.
*(C) Any noncommercial use of a mark.*
...
Do you know of another section, subsection, or other that would validate your claim?
That's exactly how it ought to work. I hope this gets noticed despite you being so heavily down-voted (and flagged... wtf?). I'd like to see it get properly refuted if it's not true.
This only covers trademark dilution which is one cause of action for trademark infringement, but not the only possible cause of action. Usually trademark dilution is argued when the products are dissimilar. In this case, they are not dissimilar. And as such, this is the regular definition of infringement and is not covered by 15 U.S.C. § 1125(c)(3). It falls distinctly under § 1125(a).
PS - You linked to 15 U.S.C. § 1127, but quoted 1125.
Unfortunately HN didn't allow me to edit the comment. 1127 however contains the definition of many terms and I believe the same conclusion can be drawn from them (Trademark does not apply to noncommercial use).
Here is 1125(a):
(1) Any person who, on or in connection with any goods or services, or any container for goods, *uses in commerce any word*, ...
As such, it does not apply in this situation.
Further, 1125(c)(3)(C) is an exclusion across the entire 1125 subsection (and yes, for dilution, which is what has been argued here).
"Is Windows XP Embedded a real-time OS?
Windows XP Embedded satisfies the vast majority of performance requirements. However, if you require a more powerful real-time support for your Windows XP Embedded OS, you can utilize one of the real-time extensions that are available through third-party vendors."
There are apparently third-party real-time extensions available, but if that counts then the existence of CONFIG_PREEMPT_RT makes Linux a RTOS and I think that'd be a pretty silly claim too.
A while ago I wrote something similar to this as a school project, but instead of being a local terminal, it was for a remote server. There was a sort of virtual file system the user interacted with, with metadata stored in MySQL, as one does for school projects.
The moral of the story is that I hated having a terminal in JavaScript for a remote server, so I have no idea why I would want one for my local computer.
I'm curious why you hated the fact that it was in JavaScript? Was it because it ran in the browser? Because this one probably can, but it runs natively by default as far as I can tell.
It wasn't really the browser. In fact the fact that it even ran in a browser was pretty cool.
It was just the lack of full terminal support, and how if I wanted to add even the most basic of features, it would take thousands of lines of code (this was before things really took off and there were libraries for everything, not that it makes it too much better).
Instead I can make a terminal that's significantly more efficient and responsive, with a fraction of the amount of code, and without having to write any JavaScript, which is its own achievement.
>Instead I can make a terminal that's significantly more efficient and responsive
...and that runs on exactly one OS, and doesn't support the 250k+ Node modules, and that doesn't support standardized plugins, and that can't open web pages locally...
I don't have any skin in this but I don't understand what it means for a terminal to "support the 250k+ Node modules," or any of the features you listed, honestly
Ooh, 250,000+ modules with an average of less than one active user, little to no documentation or tests, and which may or may not be trivial one-liners. Above all, any given module has at least one other module that provides that same functionality.
Meanwhile, plenty of other languages run on many operating systems, have standardized library behaviour, and can trivially ask the operating system to open a file:// uri.
>Above all, any given module has at least one other module that provides that same functionality.
In practice this means that you can often find a module that does exactly what you want.
I find that most modules have great test coverage, and I've found it easy to contribute to several high profile projects in the Node ecosystem. The concept of trying to contribute to, say, Boost, makes me cringe. I would just assume that anything I suggested would be killed or mangled in committee discussion, and this despite the fact that I have a friend on the committee. [1]
95% of the modules I'm using are either relatively high profile build tools or they have TypeScript definitions in DefinitelyTyped, which has a much more modest ~1800 modules. Still I've occasionally needed obscure functionality and have been able to find appropriate libraries for it.
[1] Actually, don't know if he still is, but when I was in closer touch with him it seemed like an unapproachable task.
It reads like Javascript development is largely a process of cementing together small rocks; in contrast to development elsewhere, which is largely a process of mortaring together large bricks and/or building new framework.
At some point you reach a maximum load and the structure becomes too brittle; the materials and process chosen dictate what that maximum load is. Corollary, they dictate how difficult it is to quickly throw together a simple walk path.
Firstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator. 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.
I would first like to point out that the HyperTerm OSX zip is 43mb, and the unzipped HyperTerm.app is 123mb.
Supporting exactly one OS: again, the OS specific bits aren't the hard part. Blitting characters to the screen is easy, and platform independence certainly isn't worth 123mb of overhead.
250k+ 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. 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. In my opinion, it doesn't, and this circles back around to the fact that a terminal needs to be secure. I sure as hell don't want random unaudited code running in the same application that I use to administer systems.
Standardised plugins: what standardised plugins? npm modules? Not sure what you mean here.
Can'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.
Javascript hate: It's not hate when people bring up salient points. Just because the web platform is open and everybody is using it right now doesn't mean that it's perfect or above criticism.
>Firstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator.
So you prefer one written in ... C? Because C is secure by design? <rim shot>
Coding a terminal in Rust or even Go would be awesome, I admit...
>Standardised plugins: what standardised plugins? npm modules? Not sure what you mean here.
See the demo animation for a (silly yet awesome) example.
>250k+ Node modules
Point is to use them to do other cool things client-side. It's a Really Big Toolbox. The CSS/HTML part can potentially provide interesting options as well.
>It's not hate when people bring up salient points.
>>>without having to write any JavaScript, which is its own achievement.
The latter quote is from the comment I was replying to. It is not a "salient point," but simple JavaScript hate. 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. What salient points do you actually refer to?
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. But I love to see people innovating; providing extendable architecture is the way we get great new features.
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.
> So you prefer one written in ... C? Because C is secure by design? <rim shot>
You missed the point. A program that is 2,500,000 lines of code of interpreted JavaScript, and was written by some guy in a few weeks who pulled in hundreds of unaudited third party libraries, is definitely less secure than a 100,500 line C application that has been slowly developed, improved, and audited for some 25 years or more.
>See the demo animation for a (silly yet awesome) example.
A plugin is inherently not "standard" if it does not work on terminals other than the one it's designed for. Zsh has many plugins, albeit not "standard", and almost definitely fulfills all of the functionality you could want out of this project.
>Point is to use them to do other cool things client-side. It's a Really Big Toolbox. The CSS/HTML part can potentially provide interesting options as well.
As said before, I don't want to do really cool things with CSS and HTML _in my terminal_. That's what I use a proper browser, IDE, or other functional-specific application for. And even if I did want a program that did absolutely everything, I'd rather use Emacs than some random NodeJS terminal emulator somebody wrote.
> The latter quote is from the comment I was replying to. It is not a "salient point," but simple JavaScript hate.
JavaScript is objectively a bad language, and to simply say "JavaScript hate is so 2010" is a cheap redirect of actual criticisms of the language. (And no, I don't think ES6 makes it that much better, although at the very least it becomes bearable that way.)
JavaScript is not objectively bad. I have 30 years experience programming in probably 15 languages and both formal and informal education in language theory to back that assertion up.
It's objectively not perfect, but then most languages have problems. There are a few regretful mistakes in the design, but they can be worked around by using programming style decisions enforced by a linter.
JavaScript has some of the most advanced features of languages available today, including lambdas, closures, and asynchronous coding patterns that make it faster at dealing with IO than naive C implementations.
Most of what sucks about using JavaScript is dealing with the DOM and browser differences in DOM implementations, but that's not JavaScript, that's just dealing with multiple browser platforms. Which you don't have to do in Node or Electron.
>"JavaScript hate is so 2010" is a cheap redirect of actual criticisms
No, it was a cheap comeback at substance-free hate directed at the language. If you want to argue details, read JavaScript, The Good Parts (or watch the YouTube video of the same name), and get back to me with what parts of JavaScript are actually, objectively bad. And in order to meet the "objectively" threshold, be sure to cite studies, because otherwise it's just your opinion.
> It's objectively not perfect, but then most languages have problems.
Let me be clear here: JS is not really any better or any worse than any other interpreted languages. Yeah, I can name a few language-level problems (whoever decided that Promises should silently eat exceptions was wrong), but the big problems are not unique. Things like awful numeric performance (I've done crypto in JS), horrible multithreading support (Python and Ruby have GILs so it's roughly the same thing), etc etc.
The difference is that JS/web programmers seem to be the only ones saying that things written in their language and platform of choice (JS/HTML/CSS webapps, inside or outside of Electron) are the future everybody wants. Like the ego-stroking whenever somebody posts a new Node or Electron tool that had no reason to be written in JS except that the developer just didn't want to use another language isn't weird. Like 123mb for a terminal emulator isn't ridiculous.
Javascript brings nothing to the table except that it's the only language you can use for web programming. Nothing.
The execution model is awful as well, since apparently in order to get any sort of decent performance in a webapp these days you need to maintain a shadow copy of the DOM just so you can hack around the browser's layout engine.
> JavaScript has some of the most advanced features of languages available today, including lambdas, closures, and asynchronous coding patterns that make it faster at dealing with IO than naive C implementations.
30 years programming experience and you want to compare an interpreted language to a naïve C implementation? Come on. Did you see the Python libuv asyncio implementation that is 2x faster than the equivalent code running in Node [0]? Python, using Node's own supporting libraries (http-parser also) is better than Node at Node's own game.
> So you prefer one written in ... C? Because C is secure by design? <rim shot>
> Coding a terminal in Rust or even Go would be awesome, I admit...
So, if Javascript hate is "so 2010," is C hate all the fashion now? If you're going to get on somebody's case for trashing a programming language than you might as well practice what you preach.
C certainly isn't secure by design, but there are plenty of demonstrably secure projects developed in C and C++ (and it's not like Node is self-bootstrapped, either). To answer your question, yes, I would prefer one written in C. Any day of the week.
> Point is to use them to do other cool things client-side. It's a Really Big Toolbox. The CSS/HTML part can potentially provide interesting options as well.
Dragging along such a massive runtime environment is such a heavy cost for that, though. And, again...in a terminal? I'm not judging every since Electron app, right now, I'm just judging HyperTerm.
> The latter quote is from the comment I was replying to. It is not a "salient point," but simple JavaScript hate. 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. What salient points do you actually refer to?
Honestly? Parent didn't make any. I'm just tired of people defending programming languages like they're more than just tools. It's fine to hate tools. Obviously this person's JS hate is coming from an informed place, because they've written a fair chunk of it.
This makes me want to re-implemented "commando" from AUX/MPW (I've never understood why this idea didn't take off).
If you don't know, when you typed an ellipsis after a command in AUX or MPW a dialog box would be displayed showing the most popular toggles and options for the command (and allowing graphical file-picking). When you clicked "ok" it would type the command for you, so it made the command line both easier to use and easier to learn.
(I just downloaded and tried it out and lost my enthusiasm. There's no attempt to provide a proper GUI.)
What did you lose enthusiasm for? commando or HyperTerm? I've been toying with the idea of a "teaching terminal" for learning the command line as well, and building off of HyperTerm seems like a good approach.
A teaching shell might be more important. Something like what Reason does for OCaml, but done for the the unix command line.
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).
Below that have a set of autocomplete hints. 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).
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.
`cat` first because of frequency of use (in general) and recent use. Others are showing other matches of the currently typed value + one letter, ... indicating more than one option.
You'd want usage statistics on common commands, and you'd need to assemble a database of command line options. Might be able to grab these from man/info pages, but formatting is likely inconsistent. Could at least get started that way. And you'd want to collect the users history to customize it. This'd be equivalent to the hints on many mobile OS keyboards.
I could see this being pulled into the terminal, rather than the shell itself. But it'd still need information about the underlying environment (easy if local, hard if remote).
How do terminal emulators on tablets handle keyboard input? Do any of them offer guided hints?
you're right this is probably better inside the shell. That'd make it more cross platform too.
I was thinking a different approach on how it'd work. Since the goal is teaching, I'd prepopulate it with support for really basic stuff like cat, ls, echo etc. And the bottom portion would be focused on teaching how these commands work and guiding through most common use cases. Then as the user advances, they could install new modules. Maybe they now want to start text processing so could recommend they install the grep, awk or sed modules and then begin taking those tools on.
You mention OCaml, so you probably are aware, but others may not be: there is an `utop` project, which does exactly this for OCaml REPL. It looks like this:
> I just downloaded and tried it out and lost my enthusiasm. There's no attempt to provide a proper GUI.
That was always my take on Commando. In theory, there's an idea there. In practice, it's not clear who it was supposed to appeal to. If one has to mouse around, just provide a proper GUI wrapper for the tool.
As an Acme user, I find the extensibility feature very interesting: Once you are used to Acme's contextual (and programmable) handling of text, it's hard to go back to a normal terminal.
Thanks...followed the Wikipedia link to the Rob Cox demo video. Mind blowing to have an editor as an OS filesystem that can intercept OS events. If I hadn't spent the last 20 years learning vi I would grab a copy and give it a try.
Yeah, plan 9 did a lot of cool things and fixed many of Unix fundamental warts. Taking the "everything is a file" much further, and namespaces as a fundamental primitive rather than something bolted on afterwards, for starters.
Bored at first, then was forced to smile with glee. Now I must download it, even though I was originally poo-pooing "another terminal" in my head. Well done, well done.
Anybody remember TermKit[0]? This was my first thought when I saw "JS/HTML/CSS Terminal". It was built on WebKit (five years ago, before the everything-in-JS craze really began) and had a lot of really promising features like smart MIME-type support... and then development sort of stopped.
I'd love to see the concept revisited with present-day technologies and platforms.
ES6 fixes most of my biggest problems with JavaScript as a language, and adds a few things I didn't think of, but are nice. Generators, destructuring assignment, nicer class syntax, etc. I found this series of blog posts helpful: https://hacks.mozilla.org/category/es6-in-depth/
Sure, there's still a lot of old code out there to read, but I would guess this project is using mostly modern patterns. Most Node projects do.
Follow the instructions from the GitHub page [1] the ones under the "Contribute" title, that will be enough for you. If you don't know how to work with a Node.JS project then wait for their official Windows release.
Their installation notes involve executing a bash script.
Also, the node package `child_pty` is part of the dependency tree - which doesn't support Windows. This is all totally fine but now I'm genuinely curious about how this builds on Windows.
It definitely looks cool, but may I ask what's the problem that is being solved here? Does it support tmux or at least window splits?
Which problems does this solve that the regular Terminal didn't solve? I'm kind of lost here, "I need some fireworks while I type in my terminal" is not a problem that I have often to be honest.
266 comments
[ 4.1 ms ] story [ 295 ms ] thread(I'm running it on linux, ymmv).
For example, the command prompt isn't just a command prompt, it has this silly chevron decoration with autocomplete functionality. It can probably be turned off in the settings, but I find it to be a really annoying default. It just assumes I don't have my own prompt how I want it or my own autocorrect system.
I have to explicitly disable half the 'features' before I get anything actually useful to work with.
https://github.com/electron/electron/issues/673
This attitude (replacing a lean and fast terminal, by one rendered using a web browser engine) is exactly why modern machines that are 1000x faster and with 1000x the memory still seem to be slow for basic tasks.
Of course, it's a free choice. You can waste resources by replacing small programs by browsers ;). But it's reasonable that many people find it a waste.
Well thats subjective. I might not be as cool as you but I get my work done using these tools.
So, for one Javascript-written terminal app, you can install a full Linux system with X and a window manager 10 times (Hyperterm.app is 122 MB).
If it starts to get into the multi-GB range it can hurt to download, but below that it's all identical to me. If it means that i don't need to run a specific version of a library installed globally on my machine, and i don't need to manage a big chain of dependencies myself, and it runs on multiple platforms, i don't care if it's 1mb or 500mb, and i don't care how many copies of it I'm running.
My ssd has 60gb remaining on it after a few years of daily use and i haven't needed to worry about program space yet.
When I check the battery status on my Mac, only Chrome is listed in the "Apps that use significant energy" list.
[0]: http://electron.atom.io/
Edit: @michaelmior I think you know what I mean.
Edit: I'm not sure I do know what you mean. I agree that building trivial apps in Electron probably doesn't make sense. But my terminal emulator is something I spend most of my day using. If building that on top of 14 million lines of C++ gives me a better piece of software, I'm all for it.
Perhaps not as feature comlpete, and not my daily use terminal emulator, but it's only 110k lines of code. And it's not just a terminal emulator, that's just one thing it does in that 110k lines of code.
EDIT: I was going to look up others but I'm distracted by other obligations. My point being: Terminal Emulators aren't actually that complex.
The biggest complexity is dealing with legacy terminals... and you can really just target the handful of xterm features programs actually use and get something working without a huge amount of code.
That's just not true.
Most open-source people want to be able to read, audit, fix, and (if it comes to it) maintain other people's code. 14+ million lines of code make this virtually impossible. (To be fair: Electron-based apps aren't the best example for the point I'm trying to make.)
Rate of change is another very useful metric.
I personally hate the load times. Node apps always seem to need to think for a second or too. Sublime Text v VSCode is pretty bad. Sublime Text v Atom is even worse.
When you're moving fast and in your flow, it gets to be really annoying.
[1] https://bugs.launchpad.net/sakura ]
OpenJDK: 6.8 million
.NET: 10.5 million
Source: https://www.openhub.net/
Please correct me if I'm wrong.
Using Atom or VS Code instead of Emacs cuts my battery life by a few hours. The Spotify desktop app that uses a ton of JavaScript is also horribly inefficient and has a big impact on battery life.
None of this is negligible.
I use Emacs as a Jabber client, Python and Clojure development environments, file manager, image and pdf viewer, HTTP server, spreadsheet and note-taking app and (polyglot) Literate Programming environment. And that's just the beginning of what it can be used for.
In other words, giving Emacs as an example of small and fast, natively written application is a bit unfortunate. Not to mention most of Emacs is written in ELisp, so the "natively" part is not even factually correct.
If our only answer, collectively, as developers, is the richness of the ecosystem, then perhaps we should be moving our time and energies to make a rich ecosystem in either a language/runtime environment that performs better (C/Rust/OCaml/Whatever) or one that encourages correctness and/or speed of development.
I know some people think javascript is the latter, and I can't prove them wrong, but I suspect that is not true.
That is a huge sell.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses".
--Bjarne Stroustrup
I'm pretty sure that applies to language runtimes as well.
> Although I guess asking for positivity when it comes to electron is a bit of a stretch
I like to stay current, and in this charged environment, I'd be shocked if anode runtime wasn't at the nucleus of every accelerator.
I'm sure Dijkstra is half-spinning in his grave.
But maybe we are willing to accept 50x worse performance and higher memory requirements and slower startup time because the language is nice and guarantees correctness....Well no, it is javascript, not Haskell or Lisp. So, what is the win here? Why have we collectively decided javascript is a good tool for making applications for the desktop?
I love Haskell and lisp, but you have to face the facts.
* TypeScript is actually a good language, and gives pretty darn good correctness guarantees.
* Your benchmark does not test against VSCode, which is much faster than Atom.
TypeScript's main focus is IDE tooling, not correctness. Here is an example on how generics are unsound in TypeScript: http://djcordhose.github.io/flow-vs-typescript/2016_hhjs.htm...
If you want to write JavaScript with a type system focused on soundness, you should give [flow](https://flowtype.org/) a try.
There is unexplored area sitting just right there.
Imagine having easy access to ncurses replacement, jupyter kernels like output from any of your "console" tools - that would be awesome.
exactly, I don't understand the downvotes. The parts I saw however, didn't show what you wish for.
The video doesn't seem to have a slider, but click to skip or some. A visual indicator would be nice.
http://www.hilgraeve.com/hyperterminal/
Edit: I'm surprised more people in the HN crowd aren't familiar with HyperTerm (Yes that is the name and what everyone called it for many many years) It was bundled with Windows up to 7, and is still used heavily in industrial control areas.
If someone created a new project called Steem to deliver video games to end users[, would you] be surprised if Valve took issue with their choice of name?
EDIT: Left out part of a sentence.
isn't it true that companies have to take issue, otherwise they lose their trademark? I used to be angry when large corporations would sue a little guy or nonprofit over name squabbles, but then I heard that the big company can lose their trademark if they dont.
The free version was bundled with Windows for 10+ years, and although it wasn't a particularly great terminal, its ubiquity came in handy when trying to bring new people into the bulletin board system world.
> On February 20, 2004, the developers of wxWindows announced that the project was changing its name to wxWidgets, as a result of Microsoft requesting Julian Smart to respect Microsoft's United Kingdom trademark of the term Windows. [1]
That being said, I think if MS doesn't ask them to change it, there isn't much to worry about. "wxWindows" was originally started in 1992.
[1]: https://en.wikipedia.org/wiki/WxWidgets
Regardless of who owns/owned the trademarks in whatever countries, it's not appropriate to reuse the name. It will lead to unnecessary confusion. Bad call, even if no lawyers get involved.
HyperTerm is what I called it (because I'm old).
But yeah, like yourself, the first thing I thought of when I saw this title was that old Windows terminal.
A rename is in order.
A downmod is not an explanation. You could post a snippet of law, for example.
The argument here is that this use is non-commercial (we are also apparently arguing about a non-respondent trademark), so the financial stability of entrepreneurs is irrelevant.
This is what I found on the front page of that Google search:
> At the same time, the statute characterizes certain activities as non-actionable “exclusions,” including “any noncommercial use of a mark.”
any any
any
That was from the beginning text of a link on the first page of Google results for the search that you told me to make. Did you read any of the pages? Or is your comment just trolling?
For context, I was responded with:
> That's not how trademarks work.
Care to retract?
Edit: Multiple links on the front page of that search appear to validate my thesis. You have provided no corroborative evidence.
Edit2: Wow, my previous comment was flagged. Brutal. And not even a valid response could be generated.
Edit3: Another choice quote from the front page: "Non-commercial use cannot be prevented, except if that use harms the distinctiveness of the trademark."
Edit4: "The good news is that courts have consistently protected the public's right to use the trademarks of others in order to engage in criticism, commentary, news reporting and other forms of noncommercial expression." First link.
Edit5: "Many companies claim trademark infringement or dilution when pursuing unauthorized uses of their names or logos on the Web - but it's not entirely clear how these laws apply to noncommercial activity on the Net." Contradicts the "definitely" claim that I first responded to.
Edit6: Good thing my post was censored. Might not want to get these claims widely visible.
Edit7: Who is trolling now?
Edit8: Maybe you could give a court citation?
That is clearly the case here.
a large trunk or suitcase, typically made of stiff leather and opening into two equal parts.
>consisting of or combining two or more separable aspects or qualities.
I recommend the Wikipedia article [0] as well. Here is a snippet:
>A portmanteau (Listeni/pɔːrtˈmæntoʊ/, /ˌpɔːrtmænˈtoʊ/; plural portmanteaus or portmanteaux /-ˈtoʊz/) or portmanteau word is a linguistic blend of words,[1] in which parts of multiple words, or their phones (sounds), and their meanings are combined into a new word.[1][2][3] The word "portmanteau" comes from the French for overcoat stand (porte manteau), where many coats may be placed on top of coats that are already on the stand, which continues to function as a coat stand.
>A portmanteau word fuses both the sounds and the meanings of its components, as in smog, coined by blending smoke and fog,[2][4] or motel, from motor and hotel.[5] In linguistics, a portmanteau is defined as a single morph that represents two or more morphemes.[6][7][8][9]
[0] https://en.wikipedia.org/wiki/Portmanteau
HyperTerm appears to be a Hypertext Markup Language Terminal.
[0] https://www.law.cornell.edu/uscode/text/15/1127
PS - You linked to 15 U.S.C. § 1127, but quoted 1125.
PPS - An overview of the difference between dilution and infringement: http://www.nolo.com/legal-encyclopedia/what-trademark-diluti...
Here is 1125(a):
As such, it does not apply in this situation.Further, 1125(c)(3)(C) is an exclusion across the entire 1125 subsection (and yes, for dilution, which is what has been argued here).
https://www.law.cornell.edu/uscode/text/15/1125
Your link says that infringement is a type of dilution. Therefore, no dilution means no infringement.
Also note my other response to this comment: 1125(a) explicitly only includes commercial use.
Again, the US government has only the authority to regulate interstate commerce (ie. trade [hence, trademark]).
Today it's so easy to run a small UNIX kernel on a PC.
Why would "industrial control areas" still be using Windows, if what they need is terminal emulation? Tradition? Windows-only software?
Windows on a networked computer sounds like a potential security hazard in such places.
Maybe they can get the domain name through UDRP.
https://msdn.microsoft.com/en-us/library/ms838350(v=winembed...
"Is Windows XP Embedded a real-time OS? Windows XP Embedded satisfies the vast majority of performance requirements. However, if you require a more powerful real-time support for your Windows XP Embedded OS, you can utilize one of the real-time extensions that are available through third-party vendors."
There are apparently third-party real-time extensions available, but if that counts then the existence of CONFIG_PREEMPT_RT makes Linux a RTOS and I think that'd be a pretty silly claim too.
The moral of the story is that I hated having a terminal in JavaScript for a remote server, so I have no idea why I would want one for my local computer.
It was just the lack of full terminal support, and how if I wanted to add even the most basic of features, it would take thousands of lines of code (this was before things really took off and there were libraries for everything, not that it makes it too much better).
Instead I can make a terminal that's significantly more efficient and responsive, with a fraction of the amount of code, and without having to write any JavaScript, which is its own achievement.
...and that runs on exactly one OS, and doesn't support the 250k+ Node modules, and that doesn't support standardized plugins, and that can't open web pages locally...
JavaScript hate is so 2010.
Meanwhile, plenty of other languages run on many operating systems, have standardized library behaviour, and can trivially ask the operating system to open a file:// uri.
In practice this means that you can often find a module that does exactly what you want.
I find that most modules have great test coverage, and I've found it easy to contribute to several high profile projects in the Node ecosystem. The concept of trying to contribute to, say, Boost, makes me cringe. I would just assume that anything I suggested would be killed or mangled in committee discussion, and this despite the fact that I have a friend on the committee. [1]
95% of the modules I'm using are either relatively high profile build tools or they have TypeScript definitions in DefinitelyTyped, which has a much more modest ~1800 modules. Still I've occasionally needed obscure functionality and have been able to find appropriate libraries for it.
[1] Actually, don't know if he still is, but when I was in closer touch with him it seemed like an unapproachable task.
At some point you reach a maximum load and the structure becomes too brittle; the materials and process chosen dictate what that maximum load is. Corollary, they dictate how difficult it is to quickly throw together a simple walk path.
Firstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator. 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.
I would first like to point out that the HyperTerm OSX zip is 43mb, and the unzipped HyperTerm.app is 123mb.
Supporting exactly one OS: again, the OS specific bits aren't the hard part. Blitting characters to the screen is easy, and platform independence certainly isn't worth 123mb of overhead.
250k+ 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. 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. In my opinion, it doesn't, and this circles back around to the fact that a terminal needs to be secure. I sure as hell don't want random unaudited code running in the same application that I use to administer systems.
Standardised plugins: what standardised plugins? npm modules? Not sure what you mean here.
Can'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.
Javascript hate: It's not hate when people bring up salient points. Just because the web platform is open and everybody is using it right now doesn't mean that it's perfect or above criticism.
How do you feel about the 'eshell' mode in emacs? I think it's neat because it's basically a normal shell plus an elisp REPL.
I imagine a terminal emulator with access to a large library of functions (such as a trusted subset of npm modules) could be useful.
So you prefer one written in ... C? Because C is secure by design? <rim shot>
Coding a terminal in Rust or even Go would be awesome, I admit...
>Standardised plugins: what standardised plugins? npm modules? Not sure what you mean here.
See the demo animation for a (silly yet awesome) example.
>250k+ Node modules
Point is to use them to do other cool things client-side. It's a Really Big Toolbox. The CSS/HTML part can potentially provide interesting options as well.
>It's not hate when people bring up salient points.
>>>without having to write any JavaScript, which is its own achievement.
The latter quote is from the comment I was replying to. It is not a "salient point," but simple JavaScript hate. 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. What salient points do you actually refer to?
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. But I love to see people innovating; providing extendable architecture is the way we get great new features.
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.
You missed the point. A program that is 2,500,000 lines of code of interpreted JavaScript, and was written by some guy in a few weeks who pulled in hundreds of unaudited third party libraries, is definitely less secure than a 100,500 line C application that has been slowly developed, improved, and audited for some 25 years or more.
>See the demo animation for a (silly yet awesome) example.
A plugin is inherently not "standard" if it does not work on terminals other than the one it's designed for. Zsh has many plugins, albeit not "standard", and almost definitely fulfills all of the functionality you could want out of this project.
>Point is to use them to do other cool things client-side. It's a Really Big Toolbox. The CSS/HTML part can potentially provide interesting options as well.
As said before, I don't want to do really cool things with CSS and HTML _in my terminal_. That's what I use a proper browser, IDE, or other functional-specific application for. And even if I did want a program that did absolutely everything, I'd rather use Emacs than some random NodeJS terminal emulator somebody wrote.
> The latter quote is from the comment I was replying to. It is not a "salient point," but simple JavaScript hate.
JavaScript is objectively a bad language, and to simply say "JavaScript hate is so 2010" is a cheap redirect of actual criticisms of the language. (And no, I don't think ES6 makes it that much better, although at the very least it becomes bearable that way.)
JavaScript is not objectively bad. I have 30 years experience programming in probably 15 languages and both formal and informal education in language theory to back that assertion up.
It's objectively not perfect, but then most languages have problems. There are a few regretful mistakes in the design, but they can be worked around by using programming style decisions enforced by a linter.
JavaScript has some of the most advanced features of languages available today, including lambdas, closures, and asynchronous coding patterns that make it faster at dealing with IO than naive C implementations.
Most of what sucks about using JavaScript is dealing with the DOM and browser differences in DOM implementations, but that's not JavaScript, that's just dealing with multiple browser platforms. Which you don't have to do in Node or Electron.
>"JavaScript hate is so 2010" is a cheap redirect of actual criticisms
No, it was a cheap comeback at substance-free hate directed at the language. If you want to argue details, read JavaScript, The Good Parts (or watch the YouTube video of the same name), and get back to me with what parts of JavaScript are actually, objectively bad. And in order to meet the "objectively" threshold, be sure to cite studies, because otherwise it's just your opinion.
> I have 30 years experience programming in probably 15 languages and both formal and informal education in language theory to back that assertion up.
Although please come back when this becomes a true statement.
That sir is uncalled for.
Let me be clear here: JS is not really any better or any worse than any other interpreted languages. Yeah, I can name a few language-level problems (whoever decided that Promises should silently eat exceptions was wrong), but the big problems are not unique. Things like awful numeric performance (I've done crypto in JS), horrible multithreading support (Python and Ruby have GILs so it's roughly the same thing), etc etc.
The difference is that JS/web programmers seem to be the only ones saying that things written in their language and platform of choice (JS/HTML/CSS webapps, inside or outside of Electron) are the future everybody wants. Like the ego-stroking whenever somebody posts a new Node or Electron tool that had no reason to be written in JS except that the developer just didn't want to use another language isn't weird. Like 123mb for a terminal emulator isn't ridiculous.
Javascript brings nothing to the table except that it's the only language you can use for web programming. Nothing.
The execution model is awful as well, since apparently in order to get any sort of decent performance in a webapp these days you need to maintain a shadow copy of the DOM just so you can hack around the browser's layout engine.
> JavaScript has some of the most advanced features of languages available today, including lambdas, closures, and asynchronous coding patterns that make it faster at dealing with IO than naive C implementations.
30 years programming experience and you want to compare an interpreted language to a naïve C implementation? Come on. Did you see the Python libuv asyncio implementation that is 2x faster than the equivalent code running in Node [0]? Python, using Node's own supporting libraries (http-parser also) is better than Node at Node's own game.
[0]: http://magic.io/blog/uvloop-blazing-fast-python-networking/
So, if Javascript hate is "so 2010," is C hate all the fashion now? If you're going to get on somebody's case for trashing a programming language than you might as well practice what you preach.
C certainly isn't secure by design, but there are plenty of demonstrably secure projects developed in C and C++ (and it's not like Node is self-bootstrapped, either). To answer your question, yes, I would prefer one written in C. Any day of the week.
> Point is to use them to do other cool things client-side. It's a Really Big Toolbox. The CSS/HTML part can potentially provide interesting options as well.
Dragging along such a massive runtime environment is such a heavy cost for that, though. And, again...in a terminal? I'm not judging every since Electron app, right now, I'm just judging HyperTerm.
> The latter quote is from the comment I was replying to. It is not a "salient point," but simple JavaScript hate. 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. What salient points do you actually refer to?
Honestly? Parent didn't make any. I'm just tired of people defending programming languages like they're more than just tools. It's fine to hate tools. Obviously this person's JS hate is coming from an informed place, because they've written a fair chunk of it.
If you don't know, when you typed an ellipsis after a command in AUX or MPW a dialog box would be displayed showing the most popular toggles and options for the command (and allowing graphical file-picking). When you clicked "ok" it would type the command for you, so it made the command line both easier to use and easier to learn.
(I just downloaded and tried it out and lost my enthusiasm. There's no attempt to provide a proper GUI.)
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).
Below that have a set of autocomplete hints. 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).
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.
EDIT: Rough ascii art illustration:
`cat` first because of frequency of use (in general) and recent use. Others are showing other matches of the currently typed value + one letter, ... indicating more than one option.You'd want usage statistics on common commands, and you'd need to assemble a database of command line options. Might be able to grab these from man/info pages, but formatting is likely inconsistent. Could at least get started that way. And you'd want to collect the users history to customize it. This'd be equivalent to the hints on many mobile OS keyboards.
I could see this being pulled into the terminal, rather than the shell itself. But it'd still need information about the underlying environment (easy if local, hard if remote).
How do terminal emulators on tablets handle keyboard input? Do any of them offer guided hints?
I was thinking a different approach on how it'd work. Since the goal is teaching, I'd prepopulate it with support for really basic stuff like cat, ls, echo etc. And the bottom portion would be focused on teaching how these commands work and guiding through most common use cases. Then as the user advances, they could install new modules. Maybe they now want to start text processing so could recommend they install the grep, awk or sed modules and then begin taking those tools on.
Link: https://opam.ocaml.org/blog/about-utop/
That was always my take on Commando. In theory, there's an idea there. In practice, it's not clear who it was supposed to appeal to. If one has to mouse around, just provide a proper GUI wrapper for the tool.
Here you go: https://en.wikipedia.org/wiki/Acme_(text_editor)
It also runs on Macos, Linux, Windows, and BSD.
Alas, too little too late, it seems.
I'd love to see the concept revisited with present-day technologies and platforms.
[0]: https://acko.net/blog/on-termkit/
There was also a mozilla XUL based terminal many years ago - can't remember the name though.
The only article about is that I've ever found or read is this one:
http://www.xml.com/pub/a/2000/06/07/xmlterm/
[0] https://blog.codinghorror.com/the-principle-of-least-power/
https://www.reddit.com/r/programming/comments/137kd9/18_mont...
The biggest is Black Screen, but I've also got one and seen some others.
- https://github.com/shockone/black-screen - https://github.com/CGamesPlay/hterminal - https://github.com/sedwards2009/extraterm
Sure, there's still a lot of old code out there to read, but I would guess this project is using mostly modern patterns. Most Node projects do.
I can't wait. Anyone knows how I could build this on windows?
[1] https://github.com/zeit/hyperterm#contribute
Also, the node package `child_pty` is part of the dependency tree - which doesn't support Windows. This is all totally fine but now I'm genuinely curious about how this builds on Windows.
Which problems does this solve that the regular Terminal didn't solve? I'm kind of lost here, "I need some fireworks while I type in my terminal" is not a problem that I have often to be honest.
I must say, using basically a css stylesheet to control how your terminal looks and behaves does feel a lot more user friendly than a PS variable.
Also, it seems really fast. Liking it so far. Especially after iTerm versioning jumped the shark.
Looks super cool though. Seems like a no-brainer with Electron.
Edit: I take that back, since it largely leverages hterm by the Chromium team, looks like the real first commit was in 2011 or so.