Lots of negativity and one-uppery in these comments. I just wanted to say great job, keep up the good work. You're making everybody's lives easier, either directly or indirectly, by pushing the envelope here :)
I see like 90% of positive comments...
10% of criticism is too much? without it, its easy to get lost into the "everything's great" and 6 month later everyone complains about their new kde4/gnome3/unity etc fiasco.
For example, personally, I believe the completion belongs to the shell not the terminal, and i'd rather not use the mouse on a terminal's displayed text except for copy/paste.
Doesn't mean its not cool.
It shouldn't be forced, but some of us do use the mouse on a terminal window. I have more of a keyboard 'nipple' but it's conveniently right there when I'm typing and I don't have to move out of a standard typing position to use it.
I agree, this looks really cool! These are the kinds of articles I really like seeing on here, but I feel like people may be discouraged to post these types of things because the top comments are always "Well this sucks because I use X" or "This will never work because Y", or "Didn't Z already do this!?"
Lots of people here are making really cool stuff, and I love hearing about it! Keep it up!
Really great work, I'm all for it. I've been wanting terminals / shells to move forward with usability for decades now, but have never had time to do it myself. I'm 100% behind any effort in this regard at all. I'll be happy to contribute time an money to a project like this. Thanks for picking up the ball!
Terminal emulators should be expected to deal with a lot of untrusted data, such as when you ssh to another machine. With all the context parsing in this, there is a large attack surface. I hope thought has been put into how to handle this.
Untrusted data in a terminal emulator??? I don't believe that I've ever used a terminal to connect to an untrusted system. Ie. local login, or ssh to a system that I trust enough to compile my programs or run my servers.
If the terminal receives untrusted data back then I've got bigger problems than a security hole in my terminal emulator.
The entire concept of exploiting a terminal by supplying hostile input has been around for over 10 years now. Unix veterans and BBS users have been exposed to this type of problem since the very beginning, a newsgroup search can turn up all sorts of exploits, from the ever-popular "flash" program to the abuse of logging features in xterm which were disabled in R5
You've never displayed content in your terminal that you didn't generate yourself? Never ran curl against a URL to check out the headers? Never popped open an editor containing source code downloaded from the internet?
Untrusted data being sent to a terminal emulator does not imply you are logged into an untrusted system with it. Users should be able to view arbitrary files through their terminal emulator safely, should be able to use IRC safely, should be able to use finger safely, etc.
There are enough people here reporting errors (having it hang with certain output, crashing X.org, etc) to cause me to be very wary of this. I am not confident it would stand up to a security review.
Does anyone know why we can't have nice terminal emulators on Windows? I would kill for something that was a fraction as good as the default terms in OSX or Ubuntu.
Oh, and if the NSA is listening, I wouldn't actually kill, that's just an expression. Please don't arrest me.
I am working on package for windows that can do just that. Totally portable and extensible. Based on ConEmu. But I am looking for beta testers. if anybody is interested drop me an email.
I'm assuming by terminal you don't just mean CLI, which I think PowerShell has been a great step forward (but I wish I didn't have to keep dropping back to the default command prompt to get certain commands working.)
+1 for Console2, back when I had to use Windows at a previous job I used Console2 as it was the closest thing I could find to the linux terminal emulators I'm used to.
Yeah, good luck with that. I spent like a damn week trying to run gnome-terminal under Cygwin, and never did get it right. I'd love to hear any tips, though.
I've been using Console2 for a while and really like it. Last week a colleague pointed out an alternative called ConEmu. It's actively developed and has a bunch of extra features. I'm trying it out but haven't made up my mind which I prefer yet. The decision seems like it will largely be a tradeoff between configuartion complexity and flexibility. https://code.google.com/p/conemu-maximus5/.
I like the tabbed interface and the way it does select/copy/paste (close to the Windows way) in the CMD console. And, it has some pretty cool support for the FAR Manager.
PowerShell is ok until you actually have to use it for something non-trivial, at which point it's the usual "layers-of-pain" that you get with anything Microsoft these days.
Try mintty[1], comes default with Cygwin these days. Not perfect, but a lot better than the alternatives I've tried. It supports select-to-copy and middle-mouse-to-paste, which is something that's very deeply embedded in my muscle memory.
Yuck yuck yuck. And yuck to ctrl-Insert / shift-Insert too, though that's better. I very much like the fact that on OS X the default copy-paste keys are command-c / command-v which don't conflict with UNIX's use of ctrl. If I can bind Windows-C / Windows-V to copy/paste in a terminal emulator I'd be happier.
Select-to-copy is yuck for two reasons:
1: After you select, it copies and then deselects. This is annoying if you want to see that you selected the right thing, and it doesn't allow you to change your selection if you see you were off by a character.
2: I like to select to mark my place sometimes, but I don't want that to change what's on my system clipboard.
ctrl/shift Insert is yuck because it's a two-hand keystroke and doesn't have an easy way to remember whether shift or ctrl is the copy. (I don't often make mistakes between the two, but it leaves me unsure of myself which is a half second lost to hesitation each time.)
I have the same problem with ctrl/shift Insert, but I'm very happy with select-to-copy, which on Linux doesn't conflict with the ctrl-c/ctrl-v content (they're separate clipboards).
I miss middle-click to paste and select-to-copy where ever I can't use them.
From my past experience on HN, humor is not well received. I've been scolded numerous times for cracking a joke or two. Personally, I appreciate humor on HN, but I can understand how people don't want HN comments to turn into redit comment threads.
I have a theory as to why. Discourse on serious discussion on such topics, which are scientifically unsolvable (design, business, entrepreneurship) are often deferred to those who have 'been there, done that', which of course is a logical bias.
So to the humour. The issue is HN can't tell the difference between satire of itself and real advice. Each of which is probably equally valuable. Nobody wants to hear this. They all want to feel good. And get rich! And have authority!
The short answer: CSRSS isn't very good. Compare and contrast with the *nix model of how the terminal works and you'll have a pretty good idea of why Windows terminal programs are as limited as they are.
Checkout cygwin [1]. I think the main problem with a good terminal on Windows is that terminals depend heavily on having programs to run on them, and Windows, because of its lack of good terminal, doesn't have the programs to run with it. From what I have heard, PowerShell looks promising.
Powershell (and cygwin as well IIRC) still have lousy terminal emulators. The issue isn't the lack of good programs nor the shell, it's the Windows GUI "wrapper" around the CLI shell. In Windows neither cmd.exe nor Powershell allow you to alter the width of the terminal in real time. Nor have sane copy/paste options, region highlighting and so on. There's no tabbed grouping, clickable URLs, etc. Sure, some of the aforementioned can be tweaking in the preferences. But on the whole, the Windows terminal emulators are pretty poor when compared to (for example) Konsole.
Cygwin is pretty awful as well. I hear a lot of people suggest it but I really couldn't get on with Cygwin. I found MinGW to be a much better solution (which also ships some pretty cool terminal emulators as well)
I've used Cygwin (with mintty and bash), and it's not terrible. Not as nice as on other platforms, but definitely better than the other things I've seen on Windows.
Before mintty, I used Putty and connected to a local SSH server. Putty is pretty nice too.
Have you tried setting Quick-Edit for your command line? The right-click copy/paste works well enough (though not nearly as good as a linux terminal). But the highlighting is still garbage.
If you have cygwin, you can install gnome-terminal. I use it daily and it is awesome. Way better than console2 or any other windows based emulator I've tried. You may need to install it using Cygwin Ports though.
To be honest, I wiped windows and installed Linux in the end. Since I was trying to make windows behave like Linux, it made more sense just to run Linux.
I always have Cygwin around on my Windows installs. I highly recommend changing the terminal for it to RXVT, though, which works a lot better than the various things they've had by default the past few years. It's just takes a minute or two of tweaking things to setup - usually I don't even edit the main start script anymore since I always launch from the folder context menu setup by the chere program in Cygwin.
I recently switched to MobaXterm [1] and liked it so much that I paid for the Pro edition. I also love how I can launch X apps on my Fedora dev VM and forward them to my Win7 desktop - I know should be able to do that with CygWin but I could never get it to work properly.
I too switched to Moba recently after trying just about everything else. Some of the things I really like about it over the competitors:
* single binary installer
* X server
* Tabs
* Automatic SFTP sidebar when connecting via SSH
* painless SSH-tunneling (I can never remember the order of arguments on the command line)
* dancing Tuxes
There's probably more things I haven't even discovered yet (which may be too much for some people, who just want a simple terminal emulator). It's not all roses, it has locked up a couple times on me, but thanks to tmux it doesn't bother me much.
I don't know if you could use Chrome's SSH extension -- it's actually a super good terminal emulator -- if you check out the source they wrote some code to run tricky sequences through xterm and figure out what it does.
I used this (I think) briefly for about a day on ChromeOS and was very unimpressed. Is there at least a way to turn off the weird character fade effect, or whatever it's called? I didn't look long but I couldn't find one.
I use ConEmu + Powershell/Mintty for Vim/Rails development. I don't notice a difference with it vs my OSX or Linux machines. I also use it for working on my linux VPS and have 0 problems
I use tera term when on Windows, it requires an install but I like it more than others. The installer does include some other weird programs that I don't like, but if you only choose to install tera term itself it is good.
Version 20050409-21. Ouch. Maybe rxvt-uncode and an X server would be a better option. 256 colour terms, unicode, proper bitmap font support, and not been dead for 8 years.
Does everything FinalTerm does, and probably more (and can be driver with the keyboard only).
Funny thing, I don't like e-shell. I rarely, if ever, have to interact with the output of the previous command.
For command re-editing, most shells (zsh, bash) offer very powerful completition/editing capabilities that probably FinalTerm cannot match.
Admittedly, I sometimes (but rarely) have to use the output of the previous command. The problem is, if it's an url, you probably just want to click it/copy it, and then pretty much all terminals can do this already.
If I want to process the output of the command, I just re-execute it in a pipeline. Just compare the number of keystrokes to go up ~10 lines and the time to type !! (or up-arrow) | grep 'something'. Heck, even copying the output to the clipboard is faster by using a pipe: cmd | xsel
Reflowing is also something many terminals do nowdays. I personally use urxvt because it's the fastest terminal I could test, and actually supports fallback fontsets. VTE-based terminals (even the ones that pretend to be small and fast) are 5-6 orders of magnitude slower at redrawing. e-shell, by comparison, is a dog due to the much more complex display.
Poor Steven. He took so much heat then, for a concept that was way ahead of its time.
These kinds of extra-helpful term emulators seem like the natural progression of auto-completion and all the other goodies people love about oh-my-zsh. Once someone gets this right, it will seem silly to use a 'dumb' terminal in a graphical environment.
There is a right way and a wrong way to add advanced features to the whole command line experience.
The separation between shells and terminals is a good thing and should not be ignored. New features should be added to shells, and only if necessary, we can add new features to terminal emulators to support those shell features. Many, if not most, of those supporting features are already in terminal emulators. For example, every single modern terminal emulator supports mouse input (pretty much by definition): this could be used by shells if they were so inclined. If you want to add some sort of menu-based completion that supports mouse selection, great! The shell is the correct place to do it. Want to display some images or vector graphics? Some terminal emulators will have your back even in those situations, though support for those things would need to be more widespread before that stuff could really be used properly.
I totally agree that in Computer Science there are established paradigms, but I think sometimes these paradigms keep people from exploring different ways of thinking.
Talking specifically about TermKit: If I'm on a Mac using Terminal to access the local shell, why would I care if the features are coming from the shell itself or the Terminal app?
Of course it would be 'better' or more 'proper' if all the functions were built into the shell, but like you say, it takes widespread adoption. I don't see what the problem is with starting to add features to your terminal and then let the good ones trickle back down into the shell as they become widely adopted.
Seems like a confusing nightmare, but I'm not fundamentally against it.
Great point. I wonder though if some of the more advanced UI features that people want as part of their terminal+shell are being held back by relatively ancient paradigms for how terminals do complex interactive stuff. In-band signalling, ReGIS, Sixel, and Tektronix 4014 all feel like old-fashioned tech that won't be getting more popular, even if they are technically capable of getting the job done.
Also of Hotwire Shell/Term and KliNG from a few years back.
This one look nicer. At least it doesn't make the error of the previously mentioned attempts like trying to create a custom shell instead of using regular ones. Nor it does screw up existing workflow. As for trying to understand the terminal content, it is a "challenge" and I don't think it is a good idea as it will remain command specific and it has been proven to be a problem in the past, and it still is.
Terminology: http://www.enlightenment.org/p.php?p=about/terminology looks a bit similar and it's build with e17 libraries... which means it will reach a 1.0 version in twenty years? Just joking, but as a terminal emulator it's worth taking a look at.
Terminology is certainly nice, but only does inline linking and display of inline media content; no smart interpretation of the terminal content as Final Term does.
Agreed. I have no way of being certain, but I have to believe the use of Vala for projects like this (and Shotwell, etc) have a negative affect on community contribution. Not saying that's a reason to use another language, but I'd bet the choice of python, C/C++, or something else would deepen the pool of potential contributors. I for one would rather not learn yet another language simply to contribute to Gnome projects, much in the same way I've never been a big fan of having to learn Obj-C for Apple-based projects; I simply don't think I'd use Vala or Obj-C outside of those contexts.
That said, there may be very valid reasons which are performance or convenience-related for choosing Vala. Would be interested in a discussion of those if so.
For reference, Vala looks like a bastardised C# which compiles down to C which then compiles to native. The whole thing is built on top of Glib and GObject, the latter being akin to gouging your eyes out with a fork.
But sometimes seeing what's possible is good. I believe there are hundreds of commands I would be interested in, but that I don't know exists or have thought about. Right click and get a context menu with the proper command will make me learn something new. And I'll probably end up using the command in the future now that I know it exists and what it does.
It's not just you. It is wrong. A terminal is the most keyboard-driven experience you can imagine. Whenever there's a context menu it should be driven by key combination so you can move through without having to change to the mouse. When you change to the mouse you hit a context switch in the way you interact, that's why it feels disorienting to some people.
If you look at the video you'll see the mouse being used. I haven't tried the software so I don't know if that's the only way it can be used (the site seems to imply otherwise), so I'd reserve judgement.
Terminal emulator is, in fact, a GUI application, it's just that it mostly consists of a single text matrix widget. I believe many people use mouse to select text, so I don't think there's anything wrong if the text is somehow more interactive, as long as this is non-obtrusive.
no it's not only you, but don't count me in.
You are conservative, sir. Now downvote, hate and burn me for saying this. Many Linux people hate GUIs, it's a reflex to hate GUI applications, I don't want to generalize, but you probably know quite a lot of experts in their field who simply hate GUI stuff and every single one has his "own" interpretation of why GUI is wrong.
The thing is, GUIs aren't wrong, it's just that the GUI applications have no uniform interoperability like their CLI counterparts. Whose fault is that? Certainly NOT the authors! The fault is much deeper in the OS.
"Now downvote, hate", etc.. always reminds me of young girls who would always post photos with captions like "Ugly" and "Gross" phishing for compliments.
P.S. It doesn't have to do with hating GUIs for most people, it has to do with using a terminal efficiently, which often times means avoiding the mouse when possible.
yes, but that's exactly the argument I expected. Not using the mouse on GUIs is entirely possible, but your argument let's GUIs look as if they are antiquated technology not able to handle hotkeys or vim motions or anything else you want to improve efficiency.
You refer to efficiency as driving point, which I'm a big fan of, although you probably know quite well that you wouldn't use an OS if it had no GUI. The cost of entry into the IT community isn't just time, but capability and intelligence. These are the reasons why still many people are digitally divided and can't use computers efficiently. The GUIs aren't easy enough for them, forget about the terminal efficiency.. You only reach efficiency when you have the possibility to collect enough routine. How will your Grandfather get that routine, when the "cost of entry" is too high for him to master in his age.
We're not on facebook, don't expect anyone to go phishing for upvotes. We care to improve the knowledge, efficiency, health and productivity of startup people on HN.
I couldn't see any GUI elements but drop down menus, which only seem to augment the textual interface by giving a contextual interpretation of certain elements. Oh yeah, and the progress bar, which seems nice!
the real crime here is that the gui elements don't have the same style as the cli elements - they stand out like a sore thumb
but it would be sweet (more for my folks than for me, but still) if you could click on a filename in a terminal to open it, or drag from one directory listing to another to move it
The point is if the "gui" can be keyboard operated, then it can be displayed as text, by the shell, with no need to augment/modify the terminal emulator to do it. In fact, even if it is only mouse operated, you can do that - most terminal emulators support mouse interaction. The only thing you achieve by adding this to terminal emulator is guarantee that it will be unavailable to you whenever you need to log into any of the systems you work on from someone elses machine.
>The point is if the "gui" can be keyboard operated, then it can be displayed as text, by the shell, with no need to augment/modify the terminal emulator to do it.
Maybe it's just me, but I care about functionality first, an beauty second for my terminals. I do like a pretty terminal, but I care more about being able to get things done.
The current version will reflow. When I use it through byobu I sometimes have to initiate reflow with ctrl-a, shift-F.
It may not reflow as expected if you have more than one client connected to the same session - since it limits itself to the smallest attached client. If you leave your ssh session connected to the session and then connect again locally it is not obvious why reflow won't work, but you may need to just disconnect the other client.
Also, if this is free software, you should put Bitcoin donations address somewhere on the site. I would gladly donate a bit because I like the idea and I like that it's for Linux.
Please support panes, tabs and scripting for them. I tried tmux, worked in it for 6 months, but what annoyed me is the lack of support for properly styling what's on the screen. For instance, I wanted panes to be of various background colors and font sizes, which was not really possible at all in tmux.
I'm currently using Terminator, but it's rather ugly in terms of scripting for panes and tabs. If you could implement those two features out of the box, I'd pay for this software.
What are you calling a 'terminal emulator'? I think most support multiple fonts at different sizes. Apple's Terminal does, as do all the terminal emulators on my Centos systems.
In tmux, you can have multiple panes inside of the same terminal window. Apple's Terminal lets you change the font, but as far as I know, there isn't support for multiple font sizes inside of the same terminal window.
Really? I thought most terminal emulator only let you use one font at a time. If the one I use let's you have text in multiple fonts displayed at once, I certainly don't know how to do it. Or by "multiple fonts" did you just mean that you can change the font on the entire window (and that you have multiple options for doing so)?
rxvt-unicode allows you to have multiple fonts at the same time for falling back when a character is not present in the default font. For example my terminal uses a different korean font for hangul and a specific japanese font for kana and kanji in addition to my default font for european script.
xterm can support double-height characters, but that is largely academic. There isn't much it can be used for; I've never seen it used at all except to demonstrate that it can do it.
Is it just me (Linux Mint 14) or does a lot of this just not work? Dropdowns don't drop and they stay on the screen after `clear` or input scroll, right click is broken, scrolling doesn't always stick to the bottom, you can't select text or middle click to paste (my keyboard doesn't even have insert), ps aux, htop, and a few other things break it, arrow keys don't work over SSH. Then there are missing features like tabs, hiding the menu bar, spawning new terminals in the current directory, settings that do more than color scheme, etc.
About the only thing that does work is the autocomplete, which is certainly nice, but not nice enough that I'm going to give up on a ton of functionality I've gotten used to.
Don't get me wrong, I appreciate the work you're doing and don't want to discourage you, the terminal is certainly due for a rework, and this is a huge step in the right direction. If more of the features on your website were implemented/worked I would be very tempted to make a permanent switch, but I spend 8 hours a day in a terminal window, everything needs to just work.
This looks pretty awesome. It's also the first time I've heard of Vala, so I read through the tutorial of that too. It's also interesting.
I don't suppose there's a way to use this with Windows, either as the shell emulator for Cygwin or a shell emulator for an SSH connection? Then I could actually have nice shells when I have to work on a Windows box too.
Looks like no port to Mac yet...? That's cool. I''ll wait.
I'm a pretty basic user loving iTerm on Mac. One feature I really want is mouse positioning and selection of text (for the current command line). Arrow navigation is okay, but I'm a casual user not a power user.
If you're using bash and you're familiar with vim, you can use the command "set -o vi" and start using Vi bindings to jump around/cut/delete/modify text in your current prompt.
My first instinct is to suggest something that already works for what he wants to do. If he's using a Terminal window on a frequent enough basis that he's looking for a solution, it makes more sense to suggest one than to say "Gosh, yeah, that'd be useful, I hope this terminal emulator releases in the next year some time so that you can do what you want to do with that!"
Oh, I wasn't saying that. I was saying why vi key bindings and not the default emacs key bindings? I think they are a bit more intuitive for someone who hasn't used vim before.
Great f%*ing job. Couple of years from now everyone will take these features as granted on every linux distro's terminal. Next gen linux non-power users will probably think terminal has always been like this before. And yet some people here are giving negative feedback..
Same thoughts here. Autocomplete doesn't work for me and the input lag is noticeable. I'm on 13.04. An option to turn it off would be nice, other than that it looks great.
Love it. There are elements of this that remind me of Plan 9's Acme and the Plan 9 shell. Contrary to many people's opinion, using the mouse in concert with the terminal is a really powerful paradigm.
I was thinking the same thing. But while I've always loved some things about Plan 9 (its security model and it going all-in on the everything-is-a-file model), I never was able to adjust to acme.
Acme is the part that I use even under OS X. The regexes are cool (they are recursive), it is easy to process a selection through a shell command, and the compiler integration is both simple but really useful.
I think what I like so much is that it is a rare example of an expert ui, designed for when you are really proficient rather than for learning or discoverability.
Neat. I like seeing people try new things with terminal emulators, even if a certain cluster of boo-birds shows up every time.
I noticed that the terminal does not work well with my zsh right-prompt (ends up printing on the left and getting overwritten by what I type), and has some issues with my prompt when my little Git status line appears when browsing inside a repo. But I will be keeping an eye on this project.
I am following the instructions for installing, as noted in the README on GitHub Source page, can anyone tell me how to fix? http://pastebin.com/K2e2ePW4
If it's not added yet, please consider adding a quick menu to change character encoding (like in Gnome Terminal). It's my only main requirement for a terminal editor, and most editors seem to lack it.
I really like this, although a lot of features (not GUI) are already supported by ZSH. But why is this missing configuration documentation? Or at least I couldn't find it. Keep up the awesome work!
Definitely interesting. Hate all the mousing around in the video and hope they'll be a way to go 100% keyboard (like God intended it), but all in all I think this looks pretty cool.
I think this looks great, but it does strike me a bit of re-inventing the wheel, i.e. if we take this to its logical conclusion, we'll have just reinvented the GUI ;)
Check that you have all the required packages installed on your system. Your terminal output indicates it cannot find pkg_config. There could be other missing requirements, as well. Once you have all the reqs installed, try again. Then, if issues persist, file an issue on the project's Github page. :)
I can see myself using a regular terminal emulator for vim on one half of my screen, and something like Final Term for running tests and doing other stuff on the other half.
Since one uses terminals for several different things, it kind of makes sense the idea to use ones specialized for each purpose. I think it's an interesting idea.
Because viral licenses get real terrible when you want to get features from two that are mutually incompatible. When two projects have different ideas on imposing "freedom" on users, it makes it harder to cooperate and make a better end product for the users. As such, I much prefer free as in free licenses like BSD over restrictive licenses like the GPL.
because GPL tries to reinvent the definition of "free" (I recommend consulting a dictionary, and than reading what GPL considers free/freedom, you are in for a mean suprise).
